A Service Oriented Product Line Architecture for E- Government

Transcription

1 A Service Oriented Product Line Architecture for E- Government Ines Achour 1, Lamia Labed 2, Rim Helali 2 and Henda Ben Ghazela 1 1 Computer Science Department, Manouba University/ ENSI/ Lab. RIADI-GDL, Manouba, Tunisia 2 Computer Science Department, Tunis University/ ISG/ Lab. SOIE and RIADI-GDL, Tunis, Tunisia Abstract - The success of an e-government initiative depends on different factors such as economic strategies, countries political and decisions initiatives, etc. Also the siloed nature and technical aspects can hamper progress. We concentrate in this paper on architectural design of e/m-government systems according to a software engineering point of view which among all other considerations promises the success of the final e/m-government operational platform. We propose an architecture based on a systematic, large scale reuse which seems to be appropriate for the so many applications proposed as services to citizens in the context of e/mgovernment. We specifically adopt the Service Oriented Product Line approach. Existing e-government software architectures consider reuse but not large scale reuse as in Product Line Engineering which promises improvements in productivity, time-to-market, quality, and cost. The Service Oriented Architecture is adopted by a lot of e-government systems and SOPL takes the advantages of both SOA and PLE. Keywords: e/m-government architectures, large scale reuse, Service Oriented Product Line (SOPL), high level design. 1 Introduction E-Government is much more than one simple Web site or portal providing E-Government services. It is a complex system providing an innumerable number of services which are addressed to millions of citizens and handle sensitive data. The establishment of an E-Government system requires, in addition to the adequate infrastructure and governmental strategies according to the countries (developed and/or developing), a software architecture which presents the necessary support for such system. A good design of this architecture guarantees the success of the system to be implemented. We concentrate in this paper on architectural design of e-government systems according to a software engineering point of view and we particularly propose an architecture model for E-Government systems with the focus on the production of services by applying a systematic, large scale reuse approach considering that the domain of E- Government is, in fact, a rich domain of administrative processes which share several common points. In fact, as mentioned in SAGA [1], the reusability is an essential characteristic in the development of governmental applications. However, this reusability, although recommended by the standards, can be more profitable by the adoption of a systematic, large scale reuse approach. Planning for the reuse must begin at the stage of construction of the software architecture of the system itself. We focus in this work on the application of the SOPL (Service Oriented Product Line) approach which promises improvements in productivity, time-to-market, quality, and cost. In section 2, we present our adopted architectural model for E- Government. In section 3, we develop the SOPL reuse based approach. Then, in section 4, we detail the back-end services layer of our architecture. The conclusion summarizes our work and presents our prospects for future work. 2 Architecture model for E-Government With the aim of proposing an architecture model of E- Government systems, we studied a representative sample of E-Government architectures [2]. This study enabled us to better characterize these architectures and to propose, as shown in Figure 1, our architecture model for E-Government. This architecture is articulated in layers and particularly: the Front-end services layer, the Back-end services layer and the legacy systems layer. We denote EGL the E-Government layer which encapsulates the front-end service layer and the back-end layer. 2.1 The Front-end services layer The Front-end represents the user interface of the E- Government system. This layer represents a portal including all the governmental services. This portal constitutes a single access point via the Web to the services intended for the users of this system. This portal offers, thus, public services available 24 /24 and being able to be reached of any place by supporting the criterion of mobility. The importance of this portal lies in its capacity to quickly integrate a new application managed by the administration.

2 Figure 1: Architecture model for E-Government 2.2 The Back-end services layer This layer encapsulates various workflow applications responsible for the execution of the workflows materializing the different services offered by the organization. These workflow applications are essentially composed of business services and of transversal services. Business services are the services which offer functionalities relative to the activities of the organization s business processes while transversal services are services present in all the applications such as the services of authentication or notification. A workflow application, as defined in [3], is the application which specifies all the tasks executed by the participants of a process. It defines also the order of execution of the tasks and the exchange of information among the participants. We chose in this work the application of the concepts of SOA for Service Oriented Architecture owing to the fact that the latter guarantees the communication and interoperability between the three layers as well as the communication with other systems. In addition, the similarities characterizing the business processes of the governmental services encourage us to use a systematic, large scale reuse approach for the development of these services. Thus, the combination of these two approaches appears promising. This leads us to the adoption of the SOPL approach that we will detail in section 3. 3 The SOPL approach SOPL is a recent approach introduced in a workshop entitled Service Oriented Architectures and Product Lines - What is the Connection? which was held at the 11th edition of the International Conference SPLC ( Software Product Line Confence ) in 2007 [4], followed by a second workshop in 2008 entitled Service Oriented Architectures and Product Lines - Putting Both together? [5]. This approach is based on the concepts of SOA which offers an answer to the problems of heterogeneity and interoperability of systems. Nevertheless, this architecture does not take into account the changes which can occur for the services. Moreover, it does not have the necessary mechanisms for the identification of the services in the suitable level of granularity [6]. This led the research community in the area of software reuse to opt for the combination of SOA approach with PLE (Product Line Engineering) since the latter is essentially based on the analysis of variabilities and commonalities between a family of applications in a given domain. This promises improvements in productivity, time-to-market, quality, and cost [7]. This concern of integration of the two approaches has led to several studies of comparison [8, 9, 10, 11and 12] and of possibilities of combination of SOA and PLE [10, 13and 14]. To introduce the SOPL approach, we focus on the work of Medeiros & al [14] who presented the life cycle of a service line but they only detailed the domain engineering phase. Note also that even in the domain engineering phase, the steps were presented in a superfluous manner without going through some details such the step of the variability analysis of composite services. We tried in this work to deepen the steps of the domain engineering phase and to establish the steps of the application engineering phase and in the sequel our vision of the SOPL life cycle. We then apply the SOPL approach in the context of E-Government. As we already mentioned, this cycle is based on two phases: - Phase1: The domain engineering phase that represents the development for reuse. As shown in Figure 2, this phase allows, first, identifying components, services and composite services candidates for reuse. Then there is a variability analysis step to identify and document the architectural decisions in terms of variability. Finally, the reference architecture is specified and assets base is constructed [14]. 2.3 The legacy systems layer The legacy systems layer represents the various information systems already implanted within the governmental organizations connected with Intranet networks. This layer is preceded by an integration layer including techniques allowing detection, extraction and integration of the functionalities of the old systems in order to be used in the workflow applications if needed. Figure 2: Steps of the domain engineering phase

3 - Phase2: The application engineering phase that represents the development by reuse. As shown in Figure 3, this phase selects the components, services and composite services specific to a product. These are then subject to a step of configuration and specialization in order to specify and build the product architecture. Note that the term product refers to a software product (or a specific E-Government service in our context). Figure 3: Steps of the application engineering phase 4 SOPL application in the Back-end services layer Based on the SOA principles [15] and applying the SOPL life cycle steps, we propose, as shown in Figure 4, a reference architecture consisting of orchestrators, services and business components. This architecture is derived to result in workflow applications. Model [14], resulting from the application of the FODA method (Feature Oriented Domain Analysis) which is based on a hierarchy of composition of characteristics (functional, non functional or parameters) where some branches are mandatory, some are optional, and others are mutually exclusive [16]. From Figure 5 illustrating our Feature Model, we could identify 11 components candidates of reuse namely: check identity, By , SMS, CIN Payment, Passport Payment, B3 Payment, passport loss, CIN loss, Passport Creation, CIN Creation and B3 Creation. Identification of reuse candidates services: to identify the services candidates of reuse, we used the business processes materializing the studied governmental services [14]. This step enabled us to dress a list of services as Creation, Demand for birth certificate, Demand for proof of residence, Demand for work certificate, Authentication, Notification and Payment. Identification of reuse candidates composite services: composite services are the orchestrators through which a business process is realized. We identify composite services to meet the architectural concept of separation between orchestration treatments and business treatments and especially to guarantee loose coupling between the basic services which is a fundamental principle in SOA. Composite services can represent business processes or sub-business processes [14]. For our example, we could identify composite services including: Demand for the first time, Demand for loss, Demand for modifications. Figure 4: Services line components 4.1 Domain engineering We chose to study a range of governmental services offered by the Tunisian Ministry of the interior and local development as the demand of National Identity Card (CIN), Passport and Bulletin n 3. As we already mentioned, this phase proceeds in three steps: Candidates Identification Identification of reuse candidates components: to identify the reuse candidates components, we used the Feature Variability analysis In what follows, we carry out an analysis of variability by analyzing the communalities and variabilities between the services and the components identified with the aim of reducing the list. The analysis of the communalities consists in comparing the functionalities of the services and components in order to gather those with a low variability [14]. Variability in this case can be managed according to one of the mechanisms of variability management. In fact, variability is the capacity to change or to adapt the software systems and several mechanisms of variability management are present in the literature such as parameterization, the heritage, the information dissimulation, conditional compilation, the aspect oriented programming, etc. Components Variability analysis: when analyzed, the list of the already identified components enabled us to detect similarities between some of the components. For example, the two components SMS and By present many similarities and can be gathered to form only one component Notification with an internal variability managed with conditional compilation by declaring a constant SendMail which takes the value true or false according to the requirements of the product.

4 Figure 5: Feature Model of the online administration For the components CIN Payment, Passport Payment and B3 Payment, the same treatments are carried out by the same actors with only one difference which is the type of paper to be paid. Therefore, the gathering of these three components in only one component payment having for parameter the type of paper to pay, is a possible solution. The two components Loss of passport and Loss of CIN present the same treatments and are carried out by the same actors, it is thus better to gather them in the same component declaration of loss having for parameter the type of the lost paper. For the last three components CIN Creation, Passport Creation and B3 Creation, these three components present as much similarities as variabilities. The best mechanism to manage this variability is the heritage with a mother class Creation including all the similar treatments and three daughter classes with each one containing its specific treatments. Services variability analysis: Service variability is its capacity to be changed or configured for use in a particular context [17]. The services variability analysis consists in studying the functionalities of the services, their input and their output. If some services share similarities, we can consider the gathering by using for example the mechanism of dissimulation of information and this, by keeping the same interface for several versions of a service and variability will be present in the various versions which implement the service. This mechanism ensures compliance with the SOA architectural concept of construction of services with high level interfaces. By studying the list of the services candidates for reuse in our example, we notice that the entire services share neither functionality, neither input nor output. Thus, no gathering of services will be carried out. Composite services variability analysis: The variability of the composite services can be materialized in several forms. The variability can be present in the invocation of services which is focused, initially, on the selection of the service. This selection is carried out either during the development or during the execution [17]. The nature of the messages exchanged within the composite service, i.e. synchronous or asynchronous, can also lead to variability [17]. Variability for the composite services can also appear in the structure of the service. The structure of a composite service is, in fact, characterized by the tasks to be executed, the actors and the order of execution. All these elements are eligible candidates for variability [17]. The three composite services of our Services Line present many similarities, and this on the level of the tasks to be executed ( to fill form, request for document in proof of schooling and creation ) and on the level of the order of execution of these tasks. Thus, it is preferable to gather the three composite services in only one service named Demand_Orchestration Reference architecture specification and assets base construction Reference architecture specification: in this part, the reference architecture of the Services line is built while following the architectural decisions taken during the variability analysis step. Architecture can be modeled according to several views [14], and in order for this to be done, we chose to use a modeling language such as UML 2.0 according to the approach of Ziadi [18] where the dependences of the architecture, for example, could be modeled in the form of a class diagram, illustrated in Figure 6, extended by stereotypes modeling the variability of our Services line.

5 Assets base construction: the assets base of our line contains all the components, services and composite services identified and analyzed in the preceding steps. To build our base, we used J2E (Java 2 Entreprise), the Web services technology and the BPEL language (Business Process Language Execution) for the development of the composite service Demand_Orchestration. 4.2 Application Engineering For our case study, we have three products to derive namely the CIN, the Passport and the Bulletin n 3 workflow applications. For each one of these products, we applied the three steps of the domain engineering phase of the SOPL life cycle. We present in the sequel, the steps for the derivation of the Passport workflow application Selection of the candidates specific to the product From the assets base of our Services line, we select the components, services and composite services necessary for the construction of the product Passport : The selected composite service is: Demand_Orchestration. The selected components are: check Identity, Notification, Payment, loss Declaration and Passport Creation. The selected services are: Authentication, Demand of proof of schooling, Demand of loss declaration, Demand of birth certificate, Demand of residence certificate, Figure 6: Dependences of the reference architecture Demand of work certificate, Notification, Creation and Payment Configuration and specialization of the selected candidates The configuration of the selected candidates is carried out at the time of the invocation for the components Payment, Loss declaration, for the service Demand of loss declaration and for the composite service Demand_Orchestration. Specialization is necessary if we use mechanisms of variability management as conditional compilation. For example for the component Notification, specialization is carried out by according the value true to the constant SendMail in conformity with the specifications of the product passport Architecture specification and product construction The specification of the architecture is carried out by instantiating the reference architecture and that by keeping only the components, services and composite services selected for a given product (software application). A checking of the coherence constraints stated in the domain engineering phase must be done to guarantee the conformity of the product architecture with the reference architecture. The specific architecture of the product Passport, illustrated by the Figure 7, is built in conformity with the preceding steps.

6 Figure 7: Specific architecture of the product Passport 5 Conclusion The successful establishment of an E-Government system is certainly the result of a good design of its software architecture. We argue that other considerations such as economic strategies, countries political and decisions initiatives, countries readiness to citizen connectivity, governance, etc. are also very important factors for success. Our point of interest in this work concerns the software architecture of an E-Government system. In this paper, we have presented our proposed architectural model detailing its layers while being particularly interested in the back-end services layer. There, we have opted for the application of a systematic, large scale reuse approach for the production of these services. This will enhance reuse with different granularities, permit a better time to market specifically when faced to frequent changes in government laws, hence the need for new or adaptable e-government services (software applications). We have chosen to adopt the SOPL approach which combines between SOA architecture and Product Line Architecture. We have tried to enrich the SOPL life cycle phase s activities. This choice is motivated by our need for reuse and interoperability additionally with other quality attributes for E-Government architecture such as usability, scalability, security, transparency, legality, symmetry and responsibility. We have applied the SOPL life cycle on a case study in the domain of E-Government, a domain characterized by business processes sharing similarities, in order to test its feasibility. The perspectives of our work are to add security activities in the life cycle of the SOPL approach and to extend the number of family of services. 6 Acknowledgment This work has been supported by the Tunisian project S2EG (Secured Systems for the E-Government) which presents the collaboration of three research structures: SOIE, CRISTAL and RIADI and financed by the ministry of communication technologies of Tunisia. 7 References [1] Pankowska M. National frameworks' survey on standardization of e-government documents and processes for interoperability, Journal of theoretical and applied electronic commerce research, Vol 3, No. 3, pp , [2] Helali R., Achour I., Labed L. and Ben Ghazela H. A Study of E-Government Architectures, MCETECH 2011, Les Diablerets, Switzerland, [3] Barthold J., Franke B., Schwanninger M. and Stal M. Combining Product Line Engineering and Service Oriented Architecture in Health Care Infrastructure Systems: Experience Report, 12th International Software Product Line conference, [4] Krut B. and Cohen S. Proceedings of the First Workshop on Service-Oriented Architectures and Software Product Lines, [5] Krut B. and Cohen S. Workshop on Service Oriented Architectures and Software Product Lines Putting Both Together, [6] Roberto V., Rowlatt M., Davies R., Gugliotta A., Cabral L. and Domingue J. A Semantic Web Service-based Architecture for the Interoperability of E-government

7 Services, Proceeding of the International Workshop on Web Information Systems Modeling, Sydney, Australia, [7] Northrop L. Software Product Lines essentials, Software Engineering Institute, Carnegie Mellon University, [8] Günther S. and Berger T. Service-oriented product lines: Towards a development process and feature management model for web services, 12th International Software Product Line Conference, pp , [9] Heferich A., Herzwurm G. and Jesse S. Software Product Lines and Service-Oriented Architecture: A Systematic Comparison of Two Concepts, Proceedings of the First Workshop on Service-Oriented Architectures and Software Product Lines, [10] Lee J., Kim M., Muthig D., Naab M. and Park S. Identifying and Specifying Reusable Services of Service Centric Systems Through Product Line Technology, Proceedings of the First Workshop on Service-Oriented Architectures and Software Product Lines, [11] Raatikainen M., Myllarniemi V. and Mannisto T. Comparison of service and Software Product Family Modeling, Proceedings of the First Workshop on Service- Oriented Architectures and Software Product Lines, [12] Wienands C. Synergies between Service-Oriented Architecture and Software Product Lines, Siemens Corporate Research, Princeton, NJ, 2006, [online], [10 Jan 2011]. [13] Trujillo S., Kastner C. and Apel S. Product Lines that Supply Other Product Lines : A Service-Oriented Approach, Proceedings of the First Workshop on Service-Oriented Architectures and Software Product Lines, [14] Medeiros F., Romero S. and Santana E., Towards an Approach for Service-Oriented Product Line Architectures, Proceedings of the Workshop on Service-oriented Architectures and Software Product Lines, [15] Krakowiak S., Coupaye T., Quema V., Seinturie, L., Stefani J.-B., Dumas M., Fauvet M.-C., Déchamboux, P., Riveill, M., Beugnard, A., Emsellem, D. and Donsez D. Intergiciel et Construction d Applications Réparties, 2007, [online], ftp://ftp-developpez.com/krakowiak/icar2006/livreicar2006.pdf [10 Jan 2011]. [16] Kang K., Cohen S., Hess J., Novak W. and Peterson S. Feature-Oriented Domain Analysis (FODA) Feasibility Study, Software Engineering Institute, Carnegie Mellon University, [17] Segura S., Benavides D., Ruiz-cortes A. and Trinidad P. A Taxonomy of Variability in Web Service Flows, Proceedings of the First Workshop on Service-Oriented Architectures and Software Product Lines, [18] Ziadi T. Manipulation de Lignes de Produits en UML, PhD thesis, IFSIC, University of Rennes1/IRISA, 2004.