a service oriented design approach for e-governance systems

International Journal of Information Technology Convergence and Services (IJITCS) Vol.3, No.3, June 2013

DOI:10.5121/ijitcs.2013.3301 1

A SERVICE ORIENTED DESIGN APPROACH FORE-GOVERNANCE SYSTEMS

Rama Krushna Das 1 and Manas Ranjan Patra2

1National Informatics Centre, Berhampur, [email protected]

2 Department of Computer Science, Berhampur University, [email protected]

ABSTRACT

Today electronic Governance (E-governance) is no more a buzzword but a reality as countries all over theworldwide have shown interest in harnessing governance with state-of-the-art information andcommunication technology(ICT), in order to foster better governance. However, the inherent complexitiesof E-governance systems remain as a challenge for the architects to develop large scale, distributed, andinteroperable E-governance applications. Besides this the dynamic nature of such applications furthercomplicates the system design. In this paper, we present a design approach based on the service orientedparadigm for building E-governance systems. We also formalize concepts like service environment, servicecomposition, and service collaboration which are some of the important ingredients of our designapproach. In the sequel we highlight the suitability of our approach through some E-governance serviceprovisioning scenarios.

KEYWORDS

E-governance, Service oriented design, service window, service provisioning

1. INTRODUCTION

Electronic Governance is an application of Information and Communication Technology (ICT)for delivering government services, facilitating information exchange among variousstakeholders, and integrating different stand-alone systems with a view to foster bettergovernance. It is an approach in which the Government and its citizens, businesses, and otherarms of government can transact certain activities using different ICT tools and techniques. Theobjective of e-Governance is to make government services available anywhere, anytime to thecitizens, employees, businesses, and other nongovernmental agencies in a convenient, efficientand transparent manner. It attempts to reach out to the stakeholders, even in remote areas, toprovide information in real time. It tries to enhance operational efficiency and productivity byoperating seamlessly among government departments and concerned agencies. The majority of e-government initiatives are aiming at improving government processes by cutting process costs,managing process performance, making strategic connections in government and creatingempowerment within the government architecture. Accordingly, connection betweengovernments and citizens (and other stakeholders) can be improved [6]. In addition, theinteractions associated with the use of such rich pool of organizational and technologicalplatforms in e-governance, creates a “task-oriented” forum of engagement between governmentsand other stakeholders [3][7][8]. Successful implementation of e-government initiatives dependsnot only on the availability of “resources” but most importantly on the adoption of appropriateimplementation-oriented paradigms that describe the growth and evolution of e-governments

mailto:[email protected]

mailto:[email protected]


2

[11]. The following sections of the paper explains about independent servicers and interdependentservices in Government departments and the approach to achieve interoperability, the ability tohandle heterogeneity and scalability.

1.1. Design challenges in E-governance systems

E-governance can be viewed as a digital means of public administration which essentiallyfacilitates the process of delivery of information and services to the public. Such systems keepevolving as governments at different levels strive to adopt new governance style for achievinghigher degree of effectiveness. In practice E-governance systems are inherently incremental innature and it is hard to foresee all future requirements at a much early stage of development.Therefore, one really finds it difficult to integrate applications developed by different partiesusing varieties of technologies. Typical characteristics of E-governance systems includes, they arehighly interoperable, large-scale, distributed, and heterogeneous systems cutting acrossgeographical boundaries and administrative domains. Therefore, achieving interoperabilityamong E-governance applications towards seamless integration and information exchange is ofparamount importance.

The above characteristics of E-governance systems necessitate the choice of a suitable designapproach to build different applications to realize a pragmatic system. Some of the requirementsof the design approach are:

I. the ability to handle heterogeneity so that independently developed systems can beintegrated

II. the ability to achieve interoperability so that applications exchange information seamlesslyIII. the ability to handle scalability so that new applications can be added and the system can

support growing number of usersIV. the ability to provide transparency so that complex processing details can be hidden from

the users thereby achieving a higher level of abstraction

2. SERVICE ORIENTED DESIGN PARADIGM

In recent years, Service Oriented Architecture (SOA) has emerged as an architectural style thatadvocates reuse and integration of software components irrespective of their location andimplementation. It has been advocated as a suitable paradigm for crafting next-generation largescale applications. While the SOA approach strongly reinforces well-established, generalsoftware architecture principles such as information hiding, modularization, and separation ofconcerns, it also adds additional themes such as service orchestration, service choreography,service repositories, and concepts like service bus.

Service-orientation is a new way of thinking about software systems that require interoperability.It helps one to identify certain high-level functionalities that can be deployed as logical units. Onewho is interested in availing a specific functionality can possibly do so by requesting the logicalunit through the provided interfaces(s) without bothering about how the functionality is actuallyworked out. This feature enables one to provide common interfaces to applications, therebyenhancing the interoperability and reusability of already available functionalities of applicationsrunning on different platforms. Eventually, this would help in rapid integration of applicationsand automate most of the business processes of organizations.


3

2.1. The Notion of Service

The notion of service has been defined in different way in the literature. Service has beendescribed as an encapsulated unit of functionalities [10]. It has also been considered as a logicalmanifestation of some physical resources (like programs, databases, devices etc.) grouped as aprocess that an organization exposes to the network [9]. A pragmatic definition of service can befound in [4] wherein Service is defined as an externally observable behaviour of asoftware/hardware component which possibly hides the internal processing details that is requiredfor the realization of a requested service, and is accessible only through a set of well-definedinterfaces. In the context of web services, a service is viewed as an application or business logicthat can run on a web server by exposing its functional capabilities to clients [2]. One thing that isapparent in all these definitions is: service is a conceptual entity that facilitates certain actions inresponse to a set of stimuli from its environment. The stimuli can be in the form of messages orexplicit invocation programs that trigger some internal processing at the service provider, whichmay not be visible to the service requestor.

Based on the notion of service, software applications can be designed in an implementationindependent manner using the abstract concept of service as the fundamental design entity. Eachservice encapsulates certain clearly specified functions while hiding implementation details of theservice under reference. Such service entities can be reused and even combined to buildsystems/subsystems to implement higher level services. In this approach software developmentbegins by analysing an application domain and identifying a set of services to be provisioned.These services form the fundamental design objects upon which a complete system can be built.

2.2. Service-Oriented Software Engineering

The notion of service is undoubtedly going to play a very important role for organizations that tryto model their applications as a set of service entities providing certain services that can beconsumed by those who request for it. In order to take benefit of the service-oriented paradigm itis necessary to develop a precise understanding of the related concepts and use them consistentlyright from the requirements elicitation phase through the design phase up to implementation. Inother words, there is a need for developing a software engineering approach to specify whatservice is and systematically follow a methodology to implement applications based on theservice-oriented concepts. A typical service oriented architecture is presented in the Figure-1.

Figure 1. Service Oriented Architecture: Conceptual Model


4

This concept is based on an architectural style that defines an interaction model between threeprimary parties: the service provider, who publishes a service description and provides theimplementation for the service, a service consumer, who can either use the uniform resourceidentifier (URI) for the service description directly or can find the service description in a serviceregistry and bind and invoke the service [1].

2.3. Suitability of Service Oriented Design Approach for Developing E-governance Systems

There is a whole range of E-governance Systems which have been implemented by variousgovernments all over the world. The most prominent ones can be categorized as G2C, G2E, G2Gand G2B. While G2C refers to a set of services exchanged between government and the citizen,G2E is set of services exchanged between government and government employees, G2G is a setof services exchanged between government agencies, and G2B is set of services exchangedbetween government and the business community. The common aspect in all these applications isthe delivery of service. Thus, the notion of service is already inherent to the E-governanceSystems. This characteristic of E-governance Systems makes it suitable to be modelled usingservice oriented design approach. Moreover, one can extend or change the design objects ondemand. SOA based solutions are composed of reusable services, with well-defined, publishedinterfaces. It also provides a mechanism to integrate existing legacy applications which is animportant requirement of E-governance Systems.

3. PROPOSED SERVICE ORIENTED DESIGN APPROACH

Considering the nature of E-governance applications, here we have proposed a design approachthat is pragmatic and can address most of the requirements of the current E-governance systemdevelopment. Our focus is to develop an approach that is realistic and very closely correspondsto the manner government services are offered to a wide variety of user groups and accessed bythe citizens. It should also take into account services at different levels of abstraction, in the sensethat certain services can be provided straightway whereas certain other services may requireinvocation of other related services in order to provision the requested service. Some of the keyconcepts that we employ in our design approach are: the notion of service window, servicecomposition, service collaboration, and service enactment. Each of these concepts is formalizedin the following sections using the RAISE specification language. The benefit of having such aformal description in the form of abstract specifications is to provide a precise understanding ofthe design concepts which can be systematically concretised to an implementation model.

3.1. Service Types

Services requested by users may require different levels of processing. Depending on thecomplexity of processing requirement we categorize services into three different types, namely,readily available services, composable services, and collaborative services.

Let us consider the following services of different Government departments for the province ofOdisha in India, for explaining service types.

S0: Below Poverty Line(BPL) service, provided by Panchayat Raj Department.S1: Antyodaya Anna Yojana (AAY) service, provided by Panchayat Raj DepartmentS2: National Rural Employment Guarantee Act (NREGA) service, provided by Panchayat RajDepartment


5

S3: Rashtriya Sawasthya Bima Yojna(RSBY) service, provided by Finance DepartmentS4: Indira Awaas Yojana(IAY) service, provided by Panchayat Raj DepartmentS5: Kutir Jyoti Yojna(KJY) service, provided by Energy DepartmentS6: Mamta Service, provided by Health Department

The use case diagram in Figure-2 below describes the interaction between the user and thevarious services described above. The RSBY Service is interdependent on NREGS Service andBPL Service, whereas KutirJ Service is interdependent on IAY Service and BPL Service. Whenthe user invokes AAY and Mamata Service they are dependent only on BPL Service.

3.1.1. Readily available services

These are services that do not require complex processing. For instance, a citizen applies for aresidence certificate. Such a request can be serviced after verifying some standard documents andcan be made available to the citizen. The other similar services form Revenue Department areNativity Certificate, Income Certificate, Social Status(caste) certificate etc.; from HealthDepartment Birth Certificate , Death Certificate, Disability Certificate etc.; from AgricultureDepartment identification of small farmer and marginal farmer; from Social welfare DepartmentOld Age Pension, Widow Pension etc.; from Welfare Department Student Scholarship, Freestudy books etc.; from Panchayat Raj Department NREGA Job card, BPL card etc.; Thefollowing class diagram in Figure-3 explains the attributes and operations of BPL service.

Figure 3. BPL Service Class Diagram

Figure 2. Use case diagram of the referred services


6

3.1.2. Composable Services

These services are not readily available but require further processing, possibly invoking a set ofrelated services in the same department. For instance, permission for a building constructioncannot be given immediately. This would require verifying the ownership of land, checkconstruction regulation policies, approval of the design, etc. All such related activities/servicescan be invoked to facilitate the requested service. Other similar examples are: for enrolling inSwasthya Bikas Yojona, it is necessary to verify that the citizen has got NREGA job card andBPL card. In order to provide 35Kg of one Rupee per Kilo rice every month under AAY schemeit is necessary to verify that he/she has BPL card. The following diagram in Figure 4 explains theoperation FindBPL() invoked for using AddAAY() operation from another service.

The sequence diagram in Figure 5 illustrates different interactions to add a Citizen name in AAY.

3.1.3. Collaborative Services

These are services which are neither available readily nor can be composed using the servicesavailable at a service window. In such a case, a service window needs to explore whether therequested service can be provided using the services of other service windows. For instance, toavail free electricity of one point household connection under Kutir Jyoti Yojona(KJY), one must

Figure 4. Class diagram of BPL and AAY Services

Figure 5. Sequence diagram to add a member under AAY


7

have a house constructed under Indira Awas Yojona(IAY). To have a house under IAY one mustbe a BPL card holder. The BPL and IAY services are provided at the service window ofPanchayat Raj Department whereas the Kutir Jyoti service is provided at service window ofEnergy Department. The request needs to come from Energy Department service window toPanchyat Raj Dept. service window to add a new member in Kutir Jyoti Yojona. The followingsequence diagram illustrates different interactions to add a new member in Kutir Jyoti Yojona.

3.2. Service Window

We introduce the notion of a service window, which can refer to a physical location or a webportal where users can submit their requests for service. Typically, a service window provisions aset of well-defined services which can be accessed by interested users through appropriate servicerequests. Next, we conceptualize the notion of service environment which is a loosely coupleddistributed environment consisting of a group of service windows. Each service window isidentified by a unique identification.

The Service Environment is formally specified as a RSL scheme which includes a set of abstracttypes and a record type called Service window. The record type specifies entries that contribute tothe service provisioning at a service window, namely, a set of readily available services, a set ofservice requests that it can handle, and other internal components that facilitate a requestedservice. It also contains information about other service windows whose services may have to beinvoked in situations when a requested service is not readily available at a service window wherethe service request has been made. Another important component of the service environment isthe service registry which is akin to a yellow page that contains information about all publiclyknown service windows. The service registry is described as a map type that maps each servicewindow unique Id to a service window designed to facilitate a set of services. The change typeassociated with each entry of the record type above indicates that new services can be added andsome existing services may be removed. Similarly, new service windows can be created and someservice windows may be withdrawn.

Figure 6. Sequence diagram to add a member under Kutir Jyoti


8

3.3. Service Composition

On receiving a service request a service window checks whether the service request can becomplied with using a set of readily available services without much processing. Thedeliver_service function takes care of such requests. However, if the request needs furtherprocessing then it invokes a service composition procedure which tries to facilitate the requestedservice making use of relevant services accessible within the service window. This involvesselecting the services and determining the order in which those are to be executed for realizingthe service under consideration. The following specification describes the service compositionprocess.

Scheme ServiceEnvironment =class

typeService,ServiceWindowId,ServiceRequest,ServiceWindow ::

readyServices : Service-set ↔ chg_services,serviceRequests : ServiceRequest-set ↔ chg_servReq,compserv : ServiceRequest ServiceComp-set ↔ chg_servcomp,colbserv : ServiceRequest ServiceWindowId-set ↔ chg_servwindow,

ServiceRegistry = ServiceWindowId ServiceWindowvaluedeliver_service: ServiceWindow × ServiceRequest Serviceaxiom∀ sw: ServiceWindow, sr: ServiceRequest ●

deliver_service (sw,sr) ≡ {s| s:Service ● s ϵ readyServices (sw)}presr ϵ serviceRequests (sw)

end

SchemeServiceComposition = extend ServiceEnvironment with

classvalue

compose_service: ServiceWindow × ServiceRequestServiceComp-set

axiom∀ sw: ServiceWindow, sr: ServiceRequest ●compose_service(sw,sr) ≡ rng compserv (sw)

presr ϵ serviceRequests (sw)

end


9

3.3. Service Collaboration

In some cases the requested service is neither a readily available service nor a composableservice, i.e., the service window cannot facilitate the requested service by using its own servicecapabilities. In the context of E-governance the effort is always to provide all requested servicesat a service window as far as possible using the concept of one-stop service. Thus, in our designapproach we incorporate a mechanism whereby a service window can collaborate with otherservice windows to facilitate the requested service. This is possible with the help of the serviceregistry which maintains a list of service window IDs along with the service requests they canhandle. This concept is geared towards realizing interoperability among service windows tofacilitate a whole range of services for the benefit of the users. The following specificationdescribes the service collaboration process.

4. Service Provisioning

In the previous sections we have introduced the basic design components around which an E-governance system can be developed. The proposed service window embodies all these designelements to handle different types of service requests submitted by the users time to time. Alogical structure of a service window is depicted in figure 7.

SchemeServiceCollaboration = extend ServiceEnvironment with

classvalue

collaborate_service: ServiceWindow × ServiceRequest ServiceWindowId -setaxiom∀ sw: ServiceWindow, sr: ServiceRequest ●

collaborate_service (sw,sr) ≡ rng colbserv (sw)presr ∉ serviceRequests (sw)

end

Service Window-2

RH

CollabS

CompS

RAS

Figure 7. Interaction between Service Windows

: Request-IN : Request-OUT

: Service Outlet: User Request : Services

Service Window-1

RAS

CompS

CollabS

RH


10

Each service window is associated with a Request Handler (RH) module which accepts servicerequests and analyses them and takes appropriate action to process it. On receiving a servicerequest, the RH module checks if the requested service is one of the readily available servicecategories; in that case it passes the control to the RAS module (Readily Available Service) to takeappropriate action to respond to the user’s request. However, if the requested service does not fallinto this category then it checks whether it requires further internal processing, in which case thecontrol is passed on to the CompS module (Composable Service) to perform necessary servicecomposition function. But, if the service request cannot be processed locally and requirescollaboration with other service windows, in that case the control is passed on to the CollabSmodule (Collaborative service). The CollabS module in turn refers to the service registry andselects the relevant service window(s) with which collaboration is necessary to realize therequested service. Each service window is augmented with four different types of channels: UserRequest, Service Outlet, Request-IN, and Request-OUT. Users make their service requests throughthe User Request channel. Service is delivered to users through the Service Outlet channel. Aservice window sends all its service collaboration requests through the Request-OUT channel andreceives such collaboration requests from other service windows through the Request-IN channel.Collaborative service requests are processed according to some service level agreements (SLAs)between the requesting and partner service windows. In a way, a service window acts as a one-stop service provisioning point which does necessary processing on the background to facilitateservices requested by users.

5. CONCLUSIONS

New ICT opportunities and achievements are constantly emerging, which needs to be adoptedrapidly for effective results in e-Governance. Service oriented architecture (SOA) is a designapproach to organize existing IT assets such that the heterogeneous and distributed e-Governanceapplications can be transformed into an integrated and simplified single window service centre forcommon citizens. A systematically executed SOA project using software engineering principlesas discussed will help organisations to build stronger connection with service consumers andprovider and provide accurate and readily available information for better governance. It will helpcommon citizens in sharing the available information in an easy and affordable manner. Thesesoftware engineering principles can further be improved to develop citizen centric e-GovernanceSOA models, so that the outputs of the business processes become visible to the end-customer,who will be able to select and combine different services to configure unique solutions that meethis/her personal needs.

REFERENCES

[1] Arsanjani, Ali, (2004), Service Oriented Modeling and Architecture, Web Service Centre ofExcellence, IBM

[2] D. Greenwood, M. Calisti, Engineering web services-Agent integration, IEEE proc. 2004.[3] Davies, T. R. (2002). Throw e-gov a lifeline. Governing, 15(9), 72[4] G. Lomow , E. Newcomer, Introduction to SOA with web services, Addison Wesley, 2005.[5 G.P. Kumari, B. Kandan, A.K. Mishra, “Experience sharing on SOA based Heterogeneous Systems

Integration.” 2008 IEEE Congress on Services 2008 Part-I.[6] Hussein Al-Omari and Ahmed Al-Omari “E-government readiness assessment model,” Journal of

Computer Science, (2006). Vol. 2, No. 11, pp. 841-845[7] John Carlo Bertot, Paul T. Jaeger, Charles R. McClure “Citizen-centered e-government services:

benefits, costs, and research needs.” DG.O 2008: 137-142.[8] Klaus Lenk, Roland Traunmüller (2002) Electronic Government: Where Are We Heading? EGOV

2002: 1-9


11

[9] Webber, J. & Parastatidis, S. (2004), “Demystifying service oriented architecture”, web servicesjournal.

[10] V. Talwar, Q. Wu et al, “Approaches for service deployment”, (2005) IEEE Internet computing,March-April, pp 70-80.

[11] Tagelsir Mohamed Gasmelseid: “A Multiagent Service-oriented Modeling of E-GovernmentInitiatives.” (2007) IJEGR 3(3): pp 87- 106

Authors

Rama Krushna Das is Technical Director (Scientist-E) working with NationalInformatics Centre (NIC), Department of Electronics and Information Technology,Government of India. His research and professional career spans over twenty fiveyears of coding, research and capacity building in computing, e-governance andrelated subjects. His expertise is primarily in the domains of Electronic Governance,Implementation Architectures and Strategy, and Software Technology. He is presentlyinvolved in development and implementation of different E-Governance projects ofNIC. He has published several peer-reviewed papers as journal articles, bookchapters, and contributions to conference proceedings. His research interests includee-governance, software engineering, Service Oriented Architecture and Cloud computing. He is a lifemember of Computer Society of India (CSI) and a professional member of the Association for ComputingMachinery (ACM).

Dr. Manas Ranjan Patra holds a Ph.D. Degree in Computer Science from theCentral University of Hyderabad, India. Currently he is an Associate Professor in thePost Graduate Department of Computer Science, Berhampur University, India. He hasabout 25 years of experience in teaching and research in different areas of ComputerScience. He had visiting assignment to International Institute for SoftwareTechnology, Macao as a United Nations Fellow and for some time worked as assistantprofessor in the Institute for Development and Research in Banking Technology,Hyderabad. He has about 90 publications to his credit. His research interests includeService Oriented Computing, Software Engineering, Applications of Data mining and e-Governance. Hehas presented papers, chaired technical sessions and served in technical committees of many Internationalconferences.