A Framework for an E-government Based on Service Oriented Architecture for Jordan

Published Online September 2013 in MECS

During the last few years, several projects under the E-government initiative have emerged, such as developing secure government network and egovernment contact center projects. One of the main challenges of these e-government initiatives relies on efficiently integrating all heterogeneous public information systems and business processes of government organizations by providing a unified environment. Thus, the ambitions of governments are to facilitate and encourage development of homogenous web platforms and provide their citizens with just one single authentication to access several public services such as taxation, social and health services [2].

In this paper, we are proposing a framework for an Egovernment based on Service Oriented Architecture (SOA) using Jordan as a case study. The paper is organized as follows: Section II provides an overview of the related work, and covers a brief description of Egovernment in Jordan. In addition, an overview of the Service Oriented Architecture is provided in this section. The methodology and a summary of the case study are explained in Section III. Section IV addresses the requirements for E-government applications based on SOA, and illustrates the stage model for E-government interoperability based on SOA and applies this to the case study. The proposed framework for E-government based on SOA is also covered in this section. Finally, the conclusions and recommendations for future work are covered in section V.

• II.    Literature Review2.1    Related Work

• 2.2    E-government in Jordan

According to Rothenberg [3], interoperability has long been recognized as one of the major enablers for providing ‘one stop’ government services to citizens. Gottschalk [4] stated that interoperability refers to a property of diverse systems and organizations enabling them to work together. Thus, improved interoperability between government organizations is of critical importance to make e-government initiatives more successful.

In a narrow sense, the term interoperability is often used to describe a technical system; this means that interoperability has to be conducted in two aspects: technological interoperability and semantic interoperability. Technical interoperability concerns the ability of integrating a variety of services and information resources into a common virtual system. Semantic interoperability refers to semantic categorization and exchanging of services in a consistent and flexible manner by service composition [5].

According to Nanping and Yuan [6], the traditional peer to peer e-government integration results in a tightly coupled e-government system which reduces agility, expansibility and interoperability. Traditional egovernment systems suffer from several inefficiencies as follows: Firstly, tightly coupled applications, which means that any small change may result in the loss of system control. Secondly, in-agility and in-expansibility of the systems; the systems were developed by different developers using different programming languages in different platforms. Thirdly is unreliability in communication between government entities and agencies. Service Oriented Architecture (SOA) is considered one of the promising technologies that provide interoperability and integration between various ranges of services, implemented by different software applications, running on a variety of platforms in government organizations.

The E-government program in Jordan aims at improving government performance and efficiency, ensuring public sector transparency and accountability, enhancing interoperability between government agencies, and delivering high quality services to all endeavors.

The Ministry of Information and Communication Technology (MOICT) is responsible for building and supporting the preparation of the e-government program in coordination with various stakeholders.

Jordan has an official portal of e-government that provides comprehensive information and an entrance gate to all information and services provided by government ministries to citizens, businesses and government agencies. Each government ministry has taken the responsibility to develop and maintain its own official websites to deliver information and services. Therefore, all government agencies’ websites are operating as separate islands with minimum communication and system integration [7].

E-service project is designed to enable citizens to process transactions online in a timely and efficient fashion [8]. In terms of e-services in Jordan, the egovernment program has been involved in developing income tax e-service, driver’s and vehicle’s licensing eservice, real state registry and borders e-service, a secure government network and an e-government contact center. However, it is concluded that most of the public e-services in Jordan are still in an early stage, and with the exception of a very few e-services, most of them have not obtained many of the expected outcomes that the rhetoric of national strategies has promised [9].

There are challenges and limitations that are hindering the full implementation of the e-government program such as low Information Technology (IT) literacy among Jordanian citizens, lack of legislations and regulations that need to be streamlined and lack of uniform technology platforms between government departments and agencies. So, the delivery of egovernment services in Jordan is currently planned to be service oriented and customer centric based on modular and interoperable IT components and accessed via multiple channels [10].

• 2.3    Service Oriented Architecture (SOA)

Service Oriented Architecture (SOA) is a current and interdisciplinary field of research. SOA is defined as an architectural approach that utilizes services such as the basic constructs to support the development of rapid, low-cost and easy composition of distributed applications even in heterogeneous environments. [11]. The main idea of SOA is to provide the functionality of applications as a service and to allow a simple mechanism to access this service via a web infrastructure.

Web services are currently the most popular technology for implementing a SOA. The basic web services standards are Simple Object Access Protocol (SOAP) for messaging, Web Service Description

Language (WSDL) for describing web service interface, and Universal Description, Discovery, and Integration (UDDI) as an optional technology for implementing the service broker [12]. The SOA architecture is illustrated in Figure 1.

Fig. 1: SOA Architecture (Adapted from Shah and Patel [13])

The following are the key aspects of SOA principles, [14]:

• (1)    Louse coupling: relationship that minimizes dependency and only requires that services retain an awareness of each other.

• (2)    Service contract: communications agreement, as described in service description.

• (3)    Autonomy: local control over the logic a service encapsulates.

• (4)    Abstraction: hides logic from outside world.

• (5)    Reusability: logic divided into different compassable services.

• (6)    Composability: services can be coordinated and assembled to form composite services.

• (7)    Interoperability: open standard-based interfaces and protocols for the plug-and-play architectural components.

• III.    Proposed Methodology3.1    Framework for E-government based on SOA

• 3.2    An Overview of the Case Study

Considering the advantages that the service-oriented approach can offer to the e-government applications; such as interoperability between governmental agencies, sharing of information and high transparency, the proposed framework architecture is divided into four layers, namely: client layer, presentation layer, application layer, and data layer. This framework illustrates the proposed integration and composition between applications through SOA components; web services, Enterprise Service Bus (ESB) and Business Process Execution Language (BPEL).

Throughout this study, and to evaluate the performance of the proposed methodology, we used the following case study. First, we contacted the head of the Information Technology (IT) department, who is responsible for identifying needed web services, in the Ministry of Environment (MOENV). MOENV is planning to transform their services into web services by integrating these services with the Enterprise Services Bus (ESB). MOENV is planning to implement the following two web services: (1) Issuing environmental license (2) Registrations for running projects to follow up their environmental impact.

In this case study, we chose to apply the service of issuing environmental license in the proposed framework architecture, because it requires the invocation and composition of web services from multiple governmental agencies and entities. In addition, we will use this service to compare between the current workflow of the processes and the proposed workflow of the MOENV application processes using Business Process Execution Language (BPEL).

• IV.    E-Government Based On SOA

• 4.1    Requirements of E-Government Applications

The driving forces for using SOA approach in egovernment can be summarized as follows: (1) The dynamic change in e-government system requirements. (2) The need for a highly autonomous approach for government agencies. (3) The necessity for security, inter-operability and communication within and among the government agencies. (4) The distribution and heterogeneity of e-government systems due to different software entities running on different platforms that need to cooperate via communication protocols [15] [6].

There are several generic requirements to the majority of the e-government applications of various countries (e.g., on-line services, and multiple access channels) [16]. In addition to these generic requirements, there are the specific ones to each country.

The dynamic change in e-government application requirements defines what a citizen and business wish to obtain through an e-government application, as well as, constraints relating to the government agencies. The generic requirements can be summarized as follows [16]:

• (1)    Multiple access channels: The citizens and businesses wish to have many ways of obtaining a service. So they can use the service that is more appropriate to their needs. This requirement is solved through SOA by the separation of the access of interface to the services and their business processesSuch a separation enables interface to have several forms (Web server, WAP server), without having to carry out any modifications to the business processes.

• (2)    On-line information and services: with the development of information and communication technologies, the citizens and businesses wish to benefit from on-line e-services, without having to move. Nevertheless, some citizens wish to get them manually. Therefore, the e-government applications should provide on-line information concerning the ways of acquiring those services.

• (3)    To provide citizens, businesses and the various government agencies with e-services, web services are used. These web services present the needed information. Moreover, in order to offer good quality eservices in replacement of the complicated government services, an ESB or middleware (also called orchestrator) is necessary. Indeed, by adding an ESB to the e-government application, e-services implying more than one government agency can be offered. This composition, collaboration and orchestration are possible whenever e-government uses service-oriented architecture.

• (4)    Interoperability. In Jordan, each governmental agency is responsible for the development of its own information system. Therefore, it is noticed that there is heterogeneity in the technologies and the platforms used [17]. This heterogeneity can be overcome by using the service oriented approach which makes it possible to exceed this kind of obstacle. Indeed, this approach allows the co-operation between heterogeneous systems since it is independent of the platform and the implementation language.

• (5)    Government agencies authentication. A government agency will have to be able to authenticate another government agency that requires a service and to authenticate itself near the other government agencies. By using a SOA based on web services, different government agencies will be able to communicate using SOAP. Therefore, their authentication can be assured through a digital signature contained in the exchanged SOAP messages. The signature will be carried out in accordance to the WS-security standard in the aim of not interfering with the interoperability constraint of the architecture. Indeed, while following this standard, the blocks of SOAP messages are signed in a standardized way and they remain comprehensible by the manifold implied partners [18].

• (6)    Filtered services access. Some government agencies may have the right to invoke a service while others do not, that is due to the security feature for the web services in SOA. To invoke a service, the consumer must provide its authentication as an input.

• (7)    Data confidentiality. The data contained in the e-government application and exchanged between the different government agencies must remain confidential.

The exchanged SOAP messages shall be encrypted by WS-security specifications in order to ensure their confidentiality.

In addition to the generic requirements, Jordan has specific requirements that could be achieved by SOA; they are summarized as follows [17]:

• (1)    Reduce the cost of ownership for :

Integration: the standardization feature of web services in SOA leads to easily knowing how to work together based on the predefined BPEL.

Maintenance: because SOA consists of reusable web services, these reusable web services reduce the number and internal complexity of services.

Development: SOA services can be created by wrapping the existing application and also are easily reused and can be rapidly assembled into new, composite application.

Higher quality services: the e-government in Jordan strives to provide higher quality e-services. This requirement could be achieved by the SOA principle of web services reusability; increased web services reusability creates higher quality services through multiple testing cycles from different service consumers.

• (2)    Support for change in government rules, regulation and policies: e-government program in Jordan requires a dynamic system that responds in a short time and at low cost of adaptation to change in rules and regulation. This could be achieved by the SOA based on business rules module that allows government agencies to administrate and manage their rules and regulations in the repository.

• (3)    Integrating Government to Government (G2G), Government to Business (G2B), Government to Employees (G2E) and Government to Citizen (G2C) services through a central platform, (See Figure 2). This requirement could be obtained through ESB which can be illustrated as the e-government central platform in the context of e-government. The e-government central platform, as one important module of the SOA, can provide the integration between these government entities services regardless of their heterogeneity in applications and software packages.

• (4)    Allow shared e-services such as online payment, notification channels and authentication for the different e-services that are requested by service consumers. By implementing SOA, these shared services will be available all the time in the ESB or the egovernmentcentral platform to be invoked and routed to different web services.

• 4.2    Interoperability in E-Government based on SOA

Interoperability is referring to a property of diverse systems and organizations enabling them to interoperate together by providing standardized information and services [4]. There are three interoperability aspects that need to be considered [19]:

Fig. 2: Integrating E-Government entities services

• 1)    Semantic Interoperability: this is concerned with ensuring that the precise meaning of exchanged information and services is understandable by any other applications. Also, it enables systems to combine received information with other information resources and to process it in a meaningful manner.

• 2)    Technical Interoperability: this covers the technical issues of linking computer systems and services. It includes key aspects such as interfaces, data integration and middleware, data presentation and exchange, accessibility and security services.

• 3)    Organizational Interoperability: this is concerned with defining business goals, modeling business processes and bringing about the collaboration of administration units that wish to exchange information and may have different internal structures and processes.

• 4.3    Stage Model for E-government Interoperability Based on SOA

Gottschalk [4] identified the five maturity levels for interoperability in digital government as follows: (1) Computer interoperability in which technical and semantic issues is solved in government agencies. (2) Process interoperability in which work processes are linked. (3) Knowledge interoperability in which knowledge is shared across government agencies. (4) Value interoperability in which benefits are shared government agencies. (5) Goal interoperability in which goals are aligned across government agencies.

Gottschalk and Solli-Sæther [20] concluded that there are stages for e-government interoperability as follows: (1) work process which allows the government agency to inter-operate in work processes across government agencies. (2) knowledge sharing which allows the government agency to share knowledge across government agencies. (3) value creation which enables government agencies in creating value in interoperating government agencies. (4) strategic alignment which enables inter-operating government agencies sharing an aligned strategy.

According to the combination between SOA maturity model and web services maturity model, there are four maturity levels as follows: (1) Implementing individual web services in which services are created from tasks contained in a new or existing application. (2) Service-oriented integration of business functions in which services are integrated across multiple applications inside and outside the enterprise for a business objective. (3) Enterprise-wide IT transformation in which integration across business functions throughout an enterprise is enabled by the architected implementation; also web services are used across organizations. (4) Maturity level in which Federated services collaborate and create complex products with individual services provided from potentially many providers [21].

Based on the available literature on e-government interoperability and service oriented architecture maturity models, this paper proposes a new model that integrates all interoperability aspects and e-government interoperability stages with SOA maturity, as illustrated in Figure 3.

This proposed model works as follows: In stage 1, a government agency identifies web services within the government agency; in other words, it is called vertical web services in which they are provided end-to-end by one government agency but their integration pattern may use some of the shared services such as authentication, notification and online payment. In Stage 2, cross organizational web services need to be integrated to the e-government central platform as it requires the sharing and involvement of the other government agencies’ web services to be delivered. Also redesign and mapping of the existing workflows and processes within and between government departments will be done in this stage.

In stage 3, a web service flows across multiple government agencies based on the defined business process of interoperating government agencies. Then composite web services will be orchestrated together to create a measured value in cost reduction and task performance because there is a high interoperability in higher stages as indicated in Gottschalk, and Solli-Sæther [20]. Finally, in Stage 4, an e-governance portal will be enabled to allow citizens, businesses and government agencies to access government information and services in a single consolidated browser view to enjoy one stop government services. In addition, there will be automated business processes and aligned strategy, goals, policies, rules and standards across the whole government agencies.

Fig. 3: Stage Model for E-Government Interoperability based on SOA

• 4.4    Framework for E-government based on SOA

Based on the advantages that the service-oriented approach can offer to the e-government applications such as security, inter-operability and highly autonomous communication within and among the government agencies, we propose to use SOA for the Jordanian e-government project. Moreover, in view of general and specific requirements, we need to separate the presentation from the application in an e-government application. Figure 4 presents the proposed architecture for the e-government applications. It is divided into four layers, namely: the client layer, the presentation layer, the application layer, the data layer. The proposed architecture is supported by a secured government network that provides connectivity to government entities, inter-application communication and file sharing or exchange between governments' entities. Finally, the whole architecture will lead to egovernance. In what follows, we detail the diverse levels of the proposed architecture.

Client layer represents the various e-government application access channels such as computer (PC), Mobile, PDA or cellular, kiosks that have access to the e-government portal through the application interface.

The presentation layer manages the interface proposed for the clients interacting with the egovernment application. For example, it contains a web server for the users connected via a web browser, a WAP server for the users connected via Mobile phones or PDAs. Separating this layer from the application layer makes the application accessible via various channels such as web browsers and even cellular phones, without having to change the application's implementation. Finally, the communications with the application layer will be done using the SOAP protocol over HTTP.

Components: Service consumers, central egovernment platform and service providers. As illustrated in the Figure 4, the application in government entity “A” as a consumer starts a business process that includes executing tasks at government entities “C” and “E” as service providers. In addition to the notification service provided by the e-government central platform, the application at “A” will communicate with the Business Process (BPEL) at its premises to execute the complete process. The BPEL component invokes the entity “C” Web service (WS-C), entity “E” Web service (WB-E) and the

Notification WS web service through SOAP messages and according to the rules that had been set earlier in its rule engine.

The data layer ensures proper storage and persistence of the governmental administration data. The management of the access rights to the data is ensured by the Database Management System (DBMS). This layer must also be protected from possible external intrusions by using a firewall. The latter, will filter the exchanged data and will block all the communications except those with the presentation, application and administration layer pertaining to the governmental administration.

Client Lava

Presentation Lava

PC, Mobile, PDA, Kiosk, Others

One Stop E-government Portal

Application Interface

(Web browser,/-\ WAP server.^

Government Entitv A

Government Entitv В

Application В

Application A---

Data Laver

Application C

Application D

Application E

Governmen t Entity C

Governme it Entity D Service Providers

Government EntityE

DBMS DB1

DBMS DB2

DBMS DB3

• Fig. 4: Proposed Framework for E-government based on SOA

• 4.5 Case Study

Here, we present a case study from the Jordanian Ministry of Environment (MOENV) to evaluate the performance of the proposed framework.

The MOENV is planning to implement two web services as follows: (1) Issuing Environmental license (2) Registrations for running projects to follow up their environmental impact. In this case study, we chose to discuss the service of issuing environmental license because it requires the invocation and composition of web services from multiple governmental agencies and entities. In addition, we will use this service to compare between the current workflow of the processes and the proposed workflow of the MOENV application processes using Business Process Execution Language (BPEL).

Fig. 5: Peer to Peer Connection for Issuing License at the Ministry

The current workflow to obtain an environmental license is described next. A customer (Investor) wishes to get environmental license for his project. First of all, the customer must go to the license department and request an application form. Then he will fill the application and attach the required documents and send them all back to the license department; the customer must go to the Civil Status and Passport Department (CSPD), Ministry of Industry and Trade (MIT) and the Company's Control Department (CCD) to obtain the required documents.

Next, the license department sends the application and the attached documents to MOENV specialized employee for auditing and verification. Then the license committee goes for field survey to decide if it needs environmental evaluation or not. If the file needs environmental evaluation, then this result goes to MOENV technical committee to study the case and it sends its recommendations to the customer. Finally, the customer forwards the study results to the license committee in order to make a classification of the project to issue the environmental license.

To implement an electronic service for this scenario, there is a vital need for cooperation between MOENV, CSPD, MIT and CCD, as each organization has its own information system. The MOENV application has to be in favor of interoperability. Moreover, the application should also be secured since most exchanged information is confidential, such as the project owner’s information.

This study takes into account all the requirements and describes the proposed e-government application process for MOENV based on the suggested Service Oriented Architecture (SOA) framework. The customer connects to the e-government portal via a personal computer, a mobile phone, or a PDA. Then, the customer login to the web service of issuing environmental license via the application interface; the customer will be authenticated by the system. After that, the customer (investor or the representative of any company) will fill the e-application form with the required information such as project name and type (industrial, Medical, etc.), owner information or any information requested by MOENV and then upload the required attached documents.

According to the customer or owner type, the system will automatically verify the owner information as follows: if the owner is any individual, a governmental entity or NGO, the system will be automatically verified with the CSPD for the company representative information. Also, if the owner is registered in the MIT, then the system will be automatically verified with the CSPD for the company representative information, and it will be verified with the MIT for the company information such as the national ID. If the owner is registered in the CCD, the system will be automatically verified with the CSPD for the company representative information, and it will be verified with the CCD for the company information such as the national ID.

Next, the customer pays the application fee through the e-payment gateway shared service. The customer will be notified, through SMS or e-mail via the notification shared service, about the date for field survey scheduled by the MOENV specialized employee, one day before the scheduled visit. After filling the survey data, the application is forwarded to the licensing committee to make a decision; if the project needs a study for environmental impact assessment then the study result is forwarded to the licensing committee to make a decision of approval or rejection.

Finally, if the application is approved then an environmental ID is issued, and a username and password is given to the customer (or investor) to benefit from the other services provided by the system in the future, or to edit any of the allowed information in his profile. Also, he will be informed via SMS gateway of the results of his application.

From this study, we can conclude that the development of e-government applications in Jordan using a service-oriented architecture offers several advantages while respecting the requirements which we identified:

• (1)    Making it possible for the citizen to profit from various services while saving time. In the scenario presented above, the citizen will be able to get environmental permission without having to present himself at the MOENV, CSPD, MIT, and CCD.

• (2)    Decreasing the load of the employees in various governmental units.

• (3)    Allowing interoperability between the different governmental administrations in spite of their

heterogeneity, thus facilitating the co-operation between them.

• V. Conclusion and Future Work

In this paper, we propose a stage model for EGovernment interoperability based on Service Oriented Architecture (SOA) that integrates all interoperability aspects and e-government interoperability stages with SOA maturity as well as a proposed framework for Egovernment based on SOA. We have described in details the proposed layers for the framework architecture; namely: the client layer, the presentation layer, the application layer, the data layer, and outlined their interactions. Then, we applied this architecture for a Jordanian Case Study, in the context of implementing environmental license web service in the MOENV.

In conclusion, SOA improves the quality of EGovernment application as follows: (1) Agility and expansibility in the service integration. (2) Higher quality services through web services reusability. (3) Allowing interoperability between the different governmental administrations in spite of their heterogeneity. (4) Providing secured architecture and infrastructure integration, also well-defined data standards. (5) Sharing of data between government agencies would be done in a controlled and proper way that protects sensitive information related to citizens. (6) Leads to common objectives, goals and strategies which eliminates confusion and conflicts among governmental agencies.

Future research would focus on the implementation of e-government web services based on the proposed framework of Service Oriented Architecture (SOA). In addition, it is worthwhile to measure the impact of these web services on the citizens, businesses and government agencies.