A Framework For Integration of Services Offered

A FRAMEWORK FOR INTEGRATION OF SERVICES OFFERED BY
GOVERNMENT AGENCIES
By
Juddy A. Gómez Gutiérrez
A project submitted in partial fulfillment of the requirements for the degree of
MASTER OF ENGINEERING
in
COMPUTER ENGINEERING
University of Puerto Rico
Mayagüez Campus
2007
Approved by:
Manuel Rodríguez Martínez, Ph.D. Date

Member, Graduate Committee
Bienvenido Vélez, Ph.D. Date

Member, Graduate Committee
Pedro I. Rivera Vega, Ph.D. Date

President, Graduate Committee
Loida Rivera Betancourt, Ph.D. Date

Representative of Graduate Studies
Isidoro Couvertier, Ph.D. Date

Chairperson of the Department
ABSTRACT
The main objective of this work has been the development I-eGS, a framework
for the integration of e-government services, and with the ultimate goal of making them
ubiquitously accessible to citizens. The system is a Web-based application, hence
allowing any interaction with users through the Web. Users of the system will be the
government agencies that register and maintain services, and the citizens that request
services. Government agencies themselves will easily register new services (by providing
the corresponding WSDL file) and combine any number of existing services to create
new ones. Each single government service is assumed to be realizable through a
specialized web service. Such web service is assumed to be maintained by the particular
agency that is primarily responsible for that particular government service. The citizen is
then able to smoothly access the services through a Web-portal without having to be
concerned as of which agencies need to submit particular approvals or certifications that
may also be required prior to the final completion of the one being requested. It also
simplifies the effort to request a service by requiring only minimum personal data, and
avoiding replication of the data entry effort whenever the same data is needed by several
of the agencies that may be involved in granting the service. The current version of the
system, and hence this project, has focused in services to grant government certifications
to citizens and which may involve several agencies.
ii
RESUMEN
El objetivo principal de este trabajo ha sido el desarrollo de un sistema que facilite
la integración de servicios de gobierno para que puedan ser accedidos por los ciudadanos
a través de la Web. Se asume que los servicios son accesibles mediante “Web services”
que proveen las agencias de gobierno. La especificación de cada “Web service” se provee
a través de su archivo WSDL, el cual puede ser registrado en el sistema como un servicio
básico. Dicha especificación es configurada de manera apropiada para que pueda ser
accesible como un servicio por parte de los ciudadanos. Además, una agencia de
gobierno podrá utilizarla en la creación de un nuevo servicio. El sistema permite que un
ciudadano acceda a los servicios que proveen las agencias sin tener que preocuparse por
posibles dependencias que puedan ser necesarias entre ellos para proveer las
certificaciones pertinentes.
Por otra parte, el sistema persigue minimizar el esfuerzo que el ciudadano tiene
que invertir en el momento de solicitar el servicio. Esto se logra de dos maneras:
minimizando la información personal que cada ciudadano tiene que proveer,
independientemente de cuántas agencias se vean involucradas en proveer el servicio, y
recuperando información personal que el ciudadano pueda haber provisto en visitas
previas al sistema. Esto es posible debido a que el sistema almacena la información que el
ciudadano provee cuando utiliza un servicio, y que puede ser requerida en el futuro por
otro servicio. La versión actual del sistema, y por lo tanto este proyecto, se ha enfocado
en servicios de otorgar certificaciones que cada agencia es responsable de expedir a los
ciudadanos.
iii
Copyright © 2007
By
Juddy A. Gómez-Gutiérrez
iv
To my great family
v
ACKNOWLEDGMENTS
First, I would like to thank God for giving me his love and for expressing it to me
in the way that He has done.
I would also like to thank my advisor and committee chair Dr. Pedro I. Rivera
Vega for his guidance and support during this project as well as for his kindness in many
of my difficult moments. I would like to equally express my gratitude to the members of
my graduate committee, Dr. Manuel Rodriguez-Rodriguez and Dr. Bienvenido Velez for
their help and advice throughout this project.
Thanks to my family for their support and prayers, especially to my mom for
teaching me that God never puts in your way any obstacle that you cannot overcome.
Thanks to Hugo Andres Macias Ferro for sharing nice and difficult moments with
me during this time, and for giving me the opportunity to share good moments with his
family as it were my own.
Thanks to CheTaz Corporation: my Friends from Argentina, Brazil, Colombia,
Lebanon, Peru, and Puerto Rico for their time, friendship and the experiences we have
shared during this time. Thanks to my other partners at the ADMG Laboratory for their
support and friendship. Finally, I would also like to thank all other people not mentioned
here who have also helped me throughout the years.
vi
TABLE OF CONTENTS
ABSTRACT........................................................................................................................II
RESUMEN ....................................................................................................................... III
ACKNOWLEDGMENTS ................................................................................................ VI
TABLE OF CONTENTS.................................................................................................VII
LIST OF TABLES............................................................................................................ IX
LIST OF FIGURES ........................................................................................................... X
LIST OF ABREVIATIONS ............................................................................................XII
1. INTRODUCTION ...................................................................................................... 1
1.1 Problem Statement .............................................................................................. 2
1.2 Contributions....................................................................................................... 4
1.3 Outline................................................................................................................. 5
2. LITERATURE REVIEW ........................................................................................... 6

2.1 Theoretical Background...................................................................................... 6
2.1.1 Integration of distributed services............................................................... 6
2.1.2 Web Services .............................................................................................. 7
2.1.3 Web Services Description Language .......................................................... 9
2.1.4 Services-Oriented Architecture................................................................. 12
2.1.5 Web Service Interoperability - WSI ......................................................... 13
2.1.6 XML Schemas .......................................................................................... 15
2.1.7 Relational databases.................................................................................. 15
2.1.8 Model View Controller ............................................................................. 16
2.2 Related work ..................................................................................................... 18
2.2.1 Current solutions for the Integration of Government Services................. 18
2.2.2 Current solutions to Service Integration using Web service technology.. 21
3. INTEGRATION OF E-GOVERNMENT SERVICES FRAMEWORK.................. 23

3.1 General System Architecture ............................................................................ 23
3.2 I-eGS Database ................................................................................................. 25
3.3 Service Manager ............................................................................................... 32
3.3.1 Basic services............................................................................................ 32
3.3.2 Composite services ................................................................................... 39
vii
3.4 Web Portal ........................................................................................................ 47
3.4.1 Administrator Users .................................................................................. 48
3.4.2 Citizen User .............................................................................................. 50
3.5 Services Engine................................................................................................. 53
4. FUNCTIONALITY TESTS...................................................................................... 57
4.1 Test enrollment ................................................................................................. 58
4.2 Tests Procedure................................................................................................. 59
4.3 Test Results....................................................................................................... 60
5. SUMMARY AND FUTURE WORK ...................................................................... 62
REFERENCES LIST ........................................................................................................ 65
APPENDIX A: WS-I REPORT........................................................................................ 67
APPENDIX B: TEST PLANS.......................................................................................... 68
viii
LIST OF TABLES
Table Page
Table 3-1: Symbols used in the E-R notation ................................................................... 26
Table 3-2: Service C, composed by service D and service H........................................... 44
Table 3-3: Input attributes of composed service C ........................................................... 45
Table 4-1: Basic services and agency providers ............................................................... 58
ix
LIST OF FIGURES
Figure Page
Figure 2-1: Web Service Invocation ................................................................................... 8
Figure 2-2: Syntactic structure of a WSDL document........................................................ 9
Figure 2-3: Service-Oriented Architecture ....................................................................... 12
Figure 2-4: Model-View-Controller Pattern ..................................................................... 17
Figure 3-1: Framework Architecture ................................................................................ 24
Figure 3-2: Entity-Relationship Diagram for I-eGS Database ......................................... 27
Figure 3-3: Registration process of a basic service .......................................................... 33
Figure 3-4: XML Schema for an Output Service.............................................................. 35
Figure 3-5: Establishment of a correspondence relationship among inputs service and
citizen attributes ................................................................................................................ 37
Figure 3-6: Order of input parameters .............................................................................. 38
Figure 3-7: Integration services process ........................................................................... 40
Figure 3-8: List of composite services.............................................................................. 41
Figure 3-9: Composition Wizard ...................................................................................... 42
Figure 3-10: Step 1: Selection of Services........................................................................ 43
Figure 3-11: Step 2: Configure Attributes ........................................................................ 46
Figure 3-12: Configured service ....................................................................................... 47
Figure 3-13: User manager ............................................................................................... 49
x
Figure 3-14: Citizen Attributes Configuration.................................................................. 50
Figure 3-15: History of services ....................................................................................... 51
Figure 3-18: Service Engine ............................................................................................. 54
xi
LIST OF ABREVIATIONS
ACID Atomicity, Consistency, Isolation, Durability

AJAX Asynchronous Java And XML
DBMS Data Base Management System
E-R Entity Relationship
HTTP Hyper Text Transfer Protocol
I-eGS Integration of e-Government Services
JDBC Java Database Connectivity
JSP Java Serve Page
MIME Multipurpose Internet Mail Extensions
MVC Model View Controller
SAX Simple API for XML
SOA Service Oriented-Architecture
SMTP Simple Mail Transfer Protocol
SOAP Simple Object Access Protocol
ODBC Object Database Connectivity
RDBMS Relational database management system
RPC Remote Procedure Call
UDDI Universal Description, Discovery and Integration
WSDL Web Service Description Language
XML Extensible Markup Language
XSD XML Schema Definition
xii
1
CHAPTER 1
1. Introduction
The Web has become an extremely popular tool for most service oriented
organizations to support their day-to-day interaction with customers. Some noteworthy
factors are the pervasive access to better communication infrastructures and the advent of
modern software technologies that support the development of systems aimed to carry the
hidden distributed collaboration that is typically needed in the Web-based service
oriented process. With the use of these technologies, sophisticated Web-based systems
have become affordable to typical businesses, allowing them to complement their
services by smoothly accessing specialized services from, as well as making theirs
accessible to, other businesses. This interoperability has significantly contributed to
increase customers’ satisfaction, and has played a critical role in the success being
experienced by most of those businesses that have incorporated modern e-Commerce and
e-Business processes in their day-to-day activities. Typical examples of service oriented
organizations can be found in government agencies whose services can be offered
through the Web. It is a common trend for them to incorporate similar processes with the
final goal of providing better and more efficient services to their citizens, and hence
achieving high satisfaction from both parts.
An important new technology that has had a remarkable impact in all this
technological revolution is that of Web services. In short terms, a Web service provides a
convenient mechanism to allow the implementation of distributed applications by hiding

2
complicated programming details that correspond to typical operations under these
environments. They support the fast development and deployment of systems that would
otherwise require a vast detailed knowledge about distributed computation and about
proprietary business logic of other partner entities with which collaboration may be
essential. Through this technology an organization can make available a particular service
operation which might be of use to other organizations in assembling new business
services. That other organization just needs to invoke the publicized Web service as
needed by its own operations or services.
The work in this project has focused on the development of a system to support
the process that government agencies need to go through in assembling Web-based
systems to offer services to citizens in an integrated fashion. We refer to our system as
Integration of e-Government Services (I-eGS) framework. The system is aimed to
facilitate the registration and composition of services that particular agencies are able to
offer through Web services. In the following subsections, we will present a general
overview of the problems related to the availability of e-services provided by government
agencies, and how I-eGS attempts to remediate these problems.
1.1 Problem Statement

The Web has become an essential tool for government agencies to support public
services that are offered directly to individual citizens. A typical example of these
services is the granting of certifications or approvals that are required from citizens on
several public or private transactions, or simply the submission of an application for a
more complex service. Often, a service of this kind, even when it is finally granted by
one specific agency, depends on the prior completion of other services. Moreover, some
3
of those other services may be provided by other agencies. Some typical examples of
such services are: applying for driving license, requesting certification of no debt from
the IRS, applying for a construction permit, applying for public housing services, and so
on.
Nowadays, these services may be offered through Web servers; allowing the
citizen to exercise his/her requests without having to physically visit the government
agencies. Unfortunately, it is common for these servers to lack the appropriate integration
of services; therefore the citizen may be required to visit several Web sites and to
replicate the forms filling effort, being asked to supply the same data in the different
forms that need to be filled throughout the requesting process. An attractive alternative is
to have those services integrated through Web portals. For the citizen is then easier to get
access to those services since the number of web sites that need to be accessed, as well as
the forms filling effort, are minimized.
However, the configuration of integrated services in a Web portal is usually not a
simple task. In general, it is necessary to know particular details of each basic service that
is to be part of the composition. In many cases these services are managed by remote
sites and may follow local standards that might not be generally known and therefore
hard to manage for outsiders. In addition, appropriate Web-components need to be
programmed to produce the final integrated service, usually requiring high programming
skills and sophisticated knowledge about Web technologies and distributed applications.
Moreover, the final product is likely to be highly monolithic, making difficult the
adjustment of the system to new requirements that may arise in the future.
4
One modern alternative is for such agencies to advertise Web services that
interact with the local applications that implement the particular services they are
responsible for. Other agencies will then be able to program their particular services, by
properly invoking those remote services through the corresponding Web service. We
therefore consider that it is an attractive alternative to automate this process in a manner
that agencies are able to smoothly access publicized services from other agencies and use
them to create and make available new services to the public. Citizens can access these
services without worrying about other agencies that may need to get involved in the
process of providing the service and hence make easier the process of requesting the
services and comply with all the requirements.
1.2 Contributions
The main objective of this work has been to build a framework to facilitate the
integration of services offered by government agencies through the Web. We are focused
in services that provide a certain kind of certification and assume that each agency is
capable of generating Web services components to access the particular services at their
own facilities. We refer to this framework as I-eGS - Framework for the Integration of e-
Government Services. The framework offers the government agencies the capacity to
smoothly register their services and to create new ones formed from the integration of
others previously registered. It also brings the citizens an easy and pervasive way to
conveniently access government services. The following are the main activities that the
system will be able to support:
• A government agency is able to register services that are ready to offer.

5
• A government agency is able to integrate previously registered services to
create new services in a smooth way.
• A citizen is able to request services in a smooth and integrated fashion.
Moreover, the framework provides a mechanism to allow re-use of the data that is
provided by a citizen whenever services are requested by him/her. These data can be
shared among agencies, and is ready to be used, without the need for the citizen to
reproduce his/her personal data in every agency or for every service request that he/she
initiates.
1.3 Outline
The remainder of this report is organized as follows. Chapter 2 provides a
literature review and related work in around the integration of web services. Then,
Chapter 3 presents a complete description of the Framework for the Smooth Integration
of Government Services. In Chapter 4 is described the functionality tests conducted by
five testers to a previous version of the Framework. Finally, Chapter 5 presents the
conclusions of this research work.

6
CHAPTER 2
2. Literature Review
This chapter provides a literature review of the theoretical background along with
the related works in the area of integration of web services and areas related with the
developed of this work.
2.1 Theoretical Background

This section provides theoretical background about the topics necessary to
understand the system developed and presented in this document.
2.1.1 Integration of distributed services
The most common technologies to allow the integration of distributed services are
CORBA [1], DCOM [2], RMI [3] and Web services [4]. These technologies support
interoperable systems over the Web. The first three require a marshalling and
unmarshalling process, which is a non-trivial task due to the fact that distributed services
are deployed in different platforms. CORBA (Common Object Request Broker
Architecture) can be used on a range of operating systems platforms. It requires services
and clients to use the same Object Request Broker, a central bus over which CORBA
objects (instances of services) interact transparently. Java RMI (Java Remote Method
Invocation) is functional only if both client and servers are running the Java Virtual
Machine. RMI is not suitable for integrating heterogeneous applications since the RMI’s
7
native-transport protocol can only communicate with other Java RMI objects. DCOM
(Distributed Component Object Model) works best in Microsoft environments, despite
DCOM versions have been developed to provide support to others operative systems.
Finally we have the Web Services alternative, technology that has had wide acceptance.
I-eGS is based on web service technology; we will describe the main features of
this technology in the next section.
2.1.2 Web Services

A Web service is a software system designed to support interoperable machine-to-
machine interaction over a network [5]. It is described using a standard, formal data-
centric XML notation, called its service description. It covers all the details necessary to
interact with the service, including message formats (that detail the operations), transport
protocols and locations. The most common service descriptions are:
• The Simple Object Access Protocol (SOAP) [6] that is the fundamental messaging
framework of web services. This protocol provides extendable XML-based
messaging allowing data exchange between distributed applications and may be used
with different network transport protocols (e.g., Hyper Text Transfer Protocol
(HTTP), Simple Mail Transfer Protocol (SMTP)).
• Web Service Description Language (WSDL) [7] is an XML-based service description
on how to communicate and make a request to a Web service. WSDL is often used in
combination with SOAP and XML Schema to provide web services over the internet.
We will describe with more details WSDL specification in the next section.
• Universal Description Discovery and Integration (UDDI) [8] is the protocol used for
the publishing of the Web services information in order to find available Web
8
services on the Internet or an intranet. It is designed to be interrogated by SOAP
messages and to provide access to WSDL documents describing the protocol bindings
and message formats required to interact with the Web services listed in its directory.
In the I-eGS’ context, WSDL description is used to get the syntactic information
about the definition of each service provided by a government agency. Each service must
have a WSDL document containing an XML description of the functional aspects of the
service, as well as the input and output parameters for its operations. Communication
between service requester (citizen interface) and service provider (agency) is carried
through SOAP messages as it is showed in Figure 2-1.
Figure 2-1: Web Service Invocation
A web service provides an access interface to a service offer by government
agencies. This interface hides the implementation details of the service, allowing it to be
used independently of the hardware or software platform on which this is implemented
and of the programming language in which this is written.

9
2.1.3 Web Services Description Language

Each web service has associated a WSDL document which contains information
about what messages go in and come out from a service. This information is only
syntactic or structural but not semantic information.
From the point of view of a client a WSDL document describes a public service
for it, and from service implementer side, the document can be viewed as the
documentation of a standard service to be used.
A WSDL document has two parts: an abstract part and a concert part [9]. The fist
one, describes what Web service does in terms of messages it consumes and produces,
and the other one, defines how and where the service is offered.
Figure 2-2: Syntactic structure of a WSDL document
Figure 2-2 shows the syntactic structure of a WSDL document sticking out the
abstract part and concrete part. As we mentioned in section 2.1.2, documentation

10
provided by a WSDL file is XML-based. It is formed by a set of definitions contained
into a <definitions> element. This element contains a targetname attribute who is the
ownership of the set of definitions inside the document, all the XML namespace needed
(xmlns attributes) and an optional name attribute related with the name of the Web
Service. A <definitions> element is composed by the following elements:
• <type> element: It is used to indicate the data definitions that web service will
use later in the definition of the messages that it will exchange. WSDL does not
declare data structures per se. It allows languages that can define XML data to be
used.
• <message> element: It allows to describe the messages that web service will
exchange. One <message> element must be defined by each message that the web
service exchanges. A message is composed by one or more parts where a part is
associated conceptually with a parameter; its structure depends on how the
binding area of the WSDL is written. Each part has two attributes, its name and
the kind (element or type) which is associated with the messaging style. If a part
defines type, it means it is using the RPC-style messaging and it can be associated
with any data item of the specified type, otherwise, if the part defines element, it
means the document-style messaging is used and the part must be the value of a
specified element.
• <portType> element: It contains one attribute, the portType name, it is only an
identifier. This element is probably the most important part of a WSDL document
essentially because it structures the set of <operation>s that a Web service
provides and the group of inputs, outputs and faults message that it will be
11
required or produce. Generally, there is only one <portType> element by WSDL
document but it is not restrictive.
The message exchange defined by a <operation> can be:
o One-way: Service receives one message but it has not to produce anything
message in response.
o Request-response: Service receives one message and it has to produce a
o Solicit-response: Service sends a message and gets a response back.
o Notification: Service sends a message and it does not receive anything
• <binding> element: While <portType> specify what <operation>s can be carried
out and the <messages>s define the parameters types for the operations, the
<binding> elements describe how to format those messages to interact in a
protocol-depended manner. WSDL does not assume one standard way to format
messages; it can exchange messages using SOAP, HTTP or MIME, but the most
common is SOAP binding.
• <service> element: It is the final part of a web service description which contains
one attribute, its name, and a child element <port> which has two attributes, name
and a reference to a binging. A service can have several <port> elements. Each
<port> element describes where a single portType is offered via a given binding.
Into the I-eGS a WSDL file provides a description of a service that a government
agency offers. It is used to create the required classes by in order to be able to invoke the
12
service. These classes are called stub classes which by definition are Java classes with a
Java-friendly API that closely matches the Web service interface defined in a given
WSDL document [5]. I-eGS uses emitter tooling that Axis provides that allow the
generation of Java classes from WSDL.
2.1.4 Services-Oriented Architecture

Software architecture describes the system’s components and the way they
interact at a high level. A Service-Oriented Architecture (SOA) is a special kind of
software architecture that has several unique characteristics. The SOA presents a
particular approach for building distributed systems that deliver application functionality
as services to either end-user applications or other services [10]. A service is defined as a
behavior that can be implemented and provided by an entity to be used by another entity.
For example, a bank provides the service “pay bill” which could be used for another
entity so that its clients can pay theirs bills.
The most important aspect of the SOA is that it separates the service’s
implementation from its interface. In other words, it separates the “what” from the
“how”. Service consumers view a service simply as an endpoint that supports a particular
request format or contract. Service consumers are not concerned with how the service
goes about executing their requests; they expect only that it will [11].
Figure 2-3: Service-Oriented Architecture

13
Figure 2-3 shows the main components of Service-Oriented Architecture [12]. A
brief description of each follows:
Service register. It is a network-based directory which contains available services.
It is the entity that accepts and stores contracts from service providers and provides those
contracts to interested service consumers.
Service requestor. It is an application, service, or some other type of software
module that requires and consumes a service. It is the entity that initiates the locating of
the service in the registry, binding to the service over a transport, and executing the
service function. The service requestor executes the service by sending it a request
formatted according to a defined contract.
Service provider. It provides the actual service, the network-addressable entity
that accepts and executes requests from consumers. It can be a mainframe system, a
component, or some other type of software system that executes the service request. The
service provider publishes its contract in the registry for access by service consumers.
SOA provides stresses interoperability related to the ability of systems using
different platforms and languages to communicate with each other. Each service provides
an interface that can be invoked through a connector type. This is the reason to adopt
SOA as architecture to support the developed system.
2.1.5 Web Service Interoperability - WSI

Even when web service technology provides interoperability between services
which are running in different platforms and implemented in different languages, some
interoperability problems might happen; the most are related with the web service design.
14
Web Service design process can be done in two ways: contract-first or code-first
[13], each one differs in how its development is performed and mainly how the WSDL
file is generated. In contract-first, WSDL document is defined before to code the
implementation of the service. Once the WSDL file is ready, the stub classes are
generated automatically with a web service code generator (e.g. WSDL2Java). In code-
first, Service implementation is done before to generate the WSDL document. Once a
web service interface is done the WSDL document is generated from the web service
code.
Several mistakes can be introduced in the of web service design phase or in the
creation of the application client:
Stubs code could not be generated from a WSDL file
The generated code does not work
SOAP messages are not understand them by the requester or received, and so
on.
Among the main causes that originate these problems can be mentioned [14]:
The WSDL is not valid, some required elements or attributes are not defined.
The WSDL works only with a specific platform and no other platform can
understand it. For example it could contain proprietary extensions/bindings or
contains/references XML schemas that use features of a specific platform.
The XML serialization fails due to the fact that the XML data in the SOAP
messages is not compatible with the XML schema in the WSDL or a bug in
the serializer/deserializer can occur.

15
These and other interoperability problems have been the focus of the Web
Services Interoperability Organization (WS-I), which in order to provide a solution has
developed a set of interoperability tests and supporting testing resources.
To perform the web service interoperability verification, WS-I organization has
established basic profiles which involve interoperability guidelines and related industry
guidelines. Tools provided by the organization allow to verify if a web service
specification is interoperability with the established guidelines. I-eGS has incorporated
WS-I tools version 1.1 (Basic Profile 1.1) to verify; If any basic service provided by
government agencies is WS-I compliant, hence it is interoperable.
2.1.6 XML Schemas

XML provides a set of structures that can represent many different types of
document and data-oriented information [5]. When there is a necessity of establish a
contract amount multiple parts which are working with the same type of XML, it is
essential to define specific rules that the XML document of each part must comply. After
a bigger effort the W3C produced a standard specification to established, XML Schemas.
An XML Schema Definition or XSD is an XML-based document that describes the
structure of an XML file.
I-eGS has defined an XML Schema - I-eGServiceInfo - that must be adopted by
government agencies who want to provide their services through the system. Each service
response must be compliant with I-eGServiceInfo schema.
2.1.7 Relational databases

A Database is a mechanism used to store information in an organized way. A
Database Management System or DBMS is software designed to assist in maintaining

16
and utilizing large collections of data. The alternative to using a DBMS is to store the
data in files and write application-specific code to manage it [15]. There are many kinds
of DBMS but the dominant types of DBMS today are the Relational Database Systems
(RDBMSs). The relational model was introduced by Edgar Codd in the 1970 [16] and it
is based in the fundamental assumption that all data are represented as mathematical
relations. RDBMs support transactions in a way that guarantee all of the ACID
(Atomicity, Consistency, Isolation, and Durability) properties for each transaction, which
must be either entirely completed or aborted.
In order for a computer program to access a database without concerning what
DBMS is used a database access middleware is used. Object DataBase Conectivity
(ODBC) and Java DataBase Conectivity (JDBC) are industry-standard database access
middleware.
I-eGS has adopted MySQL as Relational Data Base Management System, where
the information required to the system operation is stored. For instance: user information,
agencies information, services information and control access information.
2.1.8 Model View Controller

The Model View Controller (MVC) [17] is an architectural pattern which divides
computer applications into three layers and decouples their respective responsibilities.
Figure 2-4 shows the interactions amongst the layers defined in this pattern: Model
application, View and Controller.

17
Figure 2-4: Model-View-Controller Pattern
The model application represents business data and business logic or operations
that govern access and modification of this business data. This layer serves as a software
approximation to real-world functionality. The model notifies views when it changes and
provides the ability for the view to query the model about its state. It also provides the
ability for the controller to access application functionality encapsulated by the model.
The view renders the contents of a model. It accesses data from the model and
specifies how that data should be presented. It updates data presentation when the model
changes. A view also forwards user input to a controller.
The controller defines application behavior. It dispatches user requests and selects
views for presentation. It interprets user inputs and maps them into actions to be
performed by the model. In a stand-alone GUI client, user inputs include button clicks
and menu selections. In a Web application, they are HTTP GET and POST requests to
the Web tier. A controller selects the next view to display based on the user interactions
and the outcome of the model operations. An application typically has one controller for
each set of related functionality. Some applications use a separate controller for each
client type, because view interaction and selection often vary between client types.
18
I-eGS is implemented under three Java server-side technologies: Servlets, Java
Server Pages (JSPs) and JavaBeans. The Model architecture is a hybrid approach for
serving dynamic content, since it combines the use of both Servlets and JSP. It takes
advantage of the predominant strengths of both technologies, using JSP to generate the
presentation layer and Servlets to perform process-intensive tasks. Here, the Servlet acts
as the controller and is in charge of the request processing and the creation of any beans
or objects used by the JSP, as well as deciding, depending on the user's actions, which
JSP page to forward the request to. Note particularly that there is no processing logic
within the JSP page itself; it is simply responsible for retrieving any objects or beans that
may have been previously created by the Servlet, and extracting the dynamic content
from that Servlet for insertion within static templates.
2.2 Related work

We classified related works of this project in two groups. The first one presents
the current solutions offered by different governments in order to provide more
availability of their service to improve the citizen’s satisfaction level. The second one
exposes the current solutions that allow the service integration in order to improve the
performance of some specific process into an organization.
2.2.1 Current solutions for the Integration of Government Services

The German Company PC-WARE Information Technologies [18] has a tack
record in the implementation of several e-government projects around the European
Union. Among these we can mention “E-Gov Portal Solution” and “E-Government
Started Kit”. First one was developed specifically to facilitate the generation, filing and
publication of large volumes of information and integrate technical procedures developed

19
internally by local governments and administrations. It permits the integration of
technical procedures and provides a content management system that allows an easy
maintenance and updating of information relevant to a government such as requirements,
procedures, laws, and others. E-Government Started Kit was designed by PC-WARE
altogether with Microsoft as a modular and virtual agency. It supports specialist
applications, has a user database and enables the administration of all components from a
standard, browser-based interface. It can be used for sending, processing and dealing with
all sorts of enquiries from members of the public, companies and institutes. The system
can be operated in a centralized way providing services for several municipalities.
Citizens can access to government services whenever they want to. E-Government
Started Kit is the most common system adopted by the European Union governments.
The Belfast e-Science Centre of Queen's University of Belfast (UK) [19] has a
project called “Planning Grid Gateway”. It aims to build a platform to allow North
Ireland’s planning process to be integrated across multiple domains and enterprises. The
system will allow new applications and business processes to be developed based upon
such an adaptive on-demand infrastructure and provide innovative local services to
citizens. In the same way, this project pursues to provide an internet portal that allows
customers to submit, pay for and track the progress of planning applications online in a
secure environment.
Emergency Route Advisory System -ERAS- [20] is a system developed in Hong
Kong by University of Science and Technology and Dickson Computer Systems. ERAS
aims to integrate information systems from various governmental departments and public
service through Web services. The system allows to maintain information available from
20
databases of transportation and traffic condition when an emergency call is received. The
suitable access to this information will make possible to find an optimized path to access
the emergency place by considering the statistics of traffic condition and the location
information. Call centers are integrated to ERAS using Web service technologies. The
system keeps a register of each received call (traffic congestion, traffic accident) and the
selected route to attend the emergency. This helps to estimate the time of the route based
on past record.
Estado Libre Asociado Framework – ELAF [21] is the infrastructure created by
the Puerto Rico Government to provide support to government’s processes and services
available to citizens. ELAF is composed by a web portal www.gobierno.pr, tools to
publish electronic transactions, and the agency monitor tool that was created in order for
government agencies to manage their transactions. Web portal is the citizen access
interface to request services that a government agency can provide. When a citizen asks
for a service through the web portal she or he has to fill a form. Once the form is
submitted, the system sends a notification to the corresponding agency. The agency
processes the request as soon as possible using the Agency Monitor. ELAF allows the
registration of requests but it does not incorporate a mechanism that allows to provide an
automatic response to citizens request. Each government agency is responsible to provide
an adequate response to the requested services; the most agencies provide a response
sending the required certifications by physical mail after 2 or more of receiving the
notification.
21
2.2.2 Current solutions to Service Integration using Web service technology

System Integration through Web services technologies is currently a huge
research topic hence there are several approaches around the Web service Integration
area.
COLOQUIDE [22] is a Web services integration system which allows the
subscription, selection and definition of services. The system executes the service
subscription storing in an Object-Oriented Data Base the information provided by
WSDL, a file of each service. COLOQUIDE provides an environment that allows to
specify the orchestrated invocation of Web services coding to application logic
requirements. The system generates dynamically a services portal composed by access
interfaces, a portal engine as middleware classes to call the services and invoke methods
from them. Finally when a user requests a service, he or she has to insert the input or
parameters through a generated form, and the portal engine invokes the Web service
methods required to provide a correct response to the user.
Chaoying Ma Bacon, L et al [23] are focused on the definition of requirements for
build a generic portal framework for easy integration of existing services of individual
institutions. They identify six main requirements: integration, security, personalization,
customization, content management and the definition of workflows. Integration provide
mechanisms that allow to interconnect databases, web services and applications based on
current standards. Security is defined as the user identification management with sign-on
facility. Personalization and customization are focused to provide a role-based access and
web page layout respectively. Content Management refers to the mechanism to update
the information related to an individual institution and shared with others. Finally, the
Workflow is defined to provide web-based processes automation with even triggers for
22
inter- and intra-domain collaboration and cooperation management. Chaoying Ma Bacon,
L et al [23] present an e-learning Case Study, where several Educational Institution work
together in order to share the courses available in each institution.
Acuña, Cesar J. et al [24] propose a SOA independent architecture for web data
and service integration. It presents a specific deployment of such architecture using
semantic web services implemented with the WSMO (Web Services Modeling
Ontology). This paper catalogs the services involve in the architecture in two groups:
core services group and access services group. The first one are the mandatory services
which provide all the tasks necessary to achieve integration, and the second one are the
services which give access to the data or service provider by another system. This work
has been implemented partially as a case study to develop an integration portal to
different local governments in jurisdictions just south of Madrid in Spain.

23
CHAPTER 3
3. Integration of e-Government Services Framework
This chapter describes the Integration of e-Government Service Framework (I-
eGS), its different components, and their functionalities.
3.1 General System Architecture

I-eGS allows government agencies to register Web-based services and to create
new ones based on others previously registered. The system requires that, in order for an
agency to be able to register a new service, it is able to provide such particular service by
a Web service. A new service is registered using the WSDL definition of the
corresponding Web service, after validating that is WS-I and I-eGS compliant. Once
validation is done, the system asks for descriptive information of the service and stores it
in the repository of services (system’s database). A composed service is one that results
from the integration of several existing services. To support the creation of composed
services, I-eGS includes a wizard that guides the user during the creation process; that is,
the system provides assistance for the selection of services that will integrate the new
service, the definition of attributes for the new service, and the publication of the service
whenever it is ready to be used.
I-eGS includes a Web Portal component through which citizens can request any
of the registered services. When a citizen requests a service, he or she must fill a form,
supplying the data that the service requires. Such data is then stored in the system’s
24
database, and hence is available whenever the same user asks for a service in the future.
If new data is required in future requests, it is added to the particular user’s data
accordingly. Likewise the information produced by the system in response to a service
request is stored in the system’s database and it is available to the citizen when he or she
needs to access the certification(s) provided in any previous request.
Users of the system are citizens that request services, and the government
agencies that register new services and integrate them. We refer to these users as: citizen
users and agency users, respectively. An administrator is a specialized user who can
manage any configuration processes in the system.
Citizen
user
Web Portal
Citizen
Access Point user
Service agency A
Services
Engine
Administrator
User
Access Point
Service agency B Web Portal
Database
Agency
Access Point User
Service Agency N RDBMS Repository
Of
Services
Service Manager Agency

User
Figure 3-1: Framework Architecture
I-eGS architecture (Figure 3-1 ) is SOA compliant since the service providers, the
repository of services (service register), and the service requester are clearly identified.
Each of these components is as follows:

25
• A Service provider is any access point in the network where a basic service provided
by a government agency is located.
• Service register is the repository of services or database where the information about
services is stored.
• Service requester is equivalent to the Service Engine. When a user asks for a service
through the web portal, the Service Engine processes the user request and request for
the respective service to service provider.
In the following sections we describe the components of the I-eGS architecture.
3.2 I-eGS Database

The system needs to manage relevant data about every service that has been
registered and about each one of the users. The data about a service is used whenever the
service is requested or is selected to be part of a composite service. The data about users
is used to keep a historical track about the interaction that each particular user has had
with the system and to minimize the effort that the user needs to invest whenever
requesting future services. Hence the system includes a major database component to
manage all these data. Such database is modeled by the Entity-Relationship (E-R)
Diagram shown in Figure 3-2.
Before continuing our discussion about I-eGS, and for the sake of completeness
of this report, we briefly describe what an E-R diagram is. Such diagram has been
established as a standard to model entities (objects or actors) and their relationships in a
database system. Entity sets are represented by rectangles, their attributes are represented
by ellipses, double ellipses represent multi-valued attributes, and diamonds represent the
relationship sets between entity sets. Underlined attributes correspond the primary key
26
(attributes that uniquely identify an entity) of the particular entity. Table 3-1 shows the
cardinality notation denoting the participation of an entity set in a relationship set. The
letter n represents any positive integer value.
Table 3-1: Symbols used in the E-R notation
Notation Meaning
many-to-many relationship
one-to-many relationship (including 0)
one-to-one relationship
27
Figure 3-2: Entity-Relationship Diagram for I-eGS Database

28
We now briefly describe each of the relevant entities in the database that I-eGS needs to
manage, and which are part of the previous E-R diagram. For each of the entities, we
only include the descriptions of those attributes that may need further description about
its purpose. As for the others, the name of the attribute itself must clearly suggest what its
intention or purpose is. All the relevant attributes about each entity have been included in
the diagram
• user: it corresponds to any user of the system, and acts as a generalization of the
following three entities: citizen, officer, and administrator. Attributes that are
common to the former three are included as part of the user entity. They include:
user’s name, password, and e-mail address. The user_id attribute is defined as the
primary key of the entity set.
• officer and administrator: these entities have the same attributes as user entity,
but their privileges are not the same. An officer user is able to manage services in
the system and register new ones, whereas the administrator user can only manage
information about offices and agencies, and the user accounts as well.
• citizen: this entity describes the citizens. It includes fundamental attributes for
which every citizen must submit a value whenever he/she is registered. However,
particular citizens, as a requirement of particular services, may need to provide
values for other attributes not listed here. For these, we have included the
attribute entity, which is described next.
• citizen_attribute: this entity allows the system to link other attributes to a citizen,
and which might not be required for every citizen in the system. The reason is that
some services to be registered into the system may use particular attributes that
29
are not necessarily required by other services. Notice that this represents a kind of
“virtual variable schema” for the citizen entity. The attributes of the
citizen_attribute entity are the name and description of the citizen attribute to be
stored in it. Its primary key, attribute_id, is generated by the system whenever a
new citizen attribute is added into it.
• agency: an agency entity represents a government agency. This entity contains the
following attributes: description, containing a brief description of the agency, and
name, which is the name of the agency. The primary key is generated by the
system.
• office: an office entity represents a government office which belong to a specific
government agency. This entity contains a description of the office, its name, and
the primary key generated by the system.
• parent_service: a parent service represents a basic or composed service registered
in the system. It contains the name of the service, the date and the time of its
creation. This entity is defined in order to allow the future implementation of a
control version system that allows the modification of a service registered in the
system.
• service: a service represents a version of a parent service registered in the system.
This is a weak entity from parent_service entity. A service version exits only
because there is a parent service that it belongs to. The discriminator for this weak
entity is the version attribute, since, for each parent service, a version number
uniquely identifies a specific version for that parent service. This entity also
contains the typeofservice attribute which indicates whether service is basic or

30
composed, the service’s wsdlfile and targetname attributes for basic services,
service description attribute which contains the description of the version service,
and finally status attribute which shows whether the service is available or not.
• operations: an operation represents a functionality defined by a service this is
associated to the <operation> elements defined in the WSDL file in the case of
basic services. It contains the operations’ name, description, and defines the
operation_id attribute as a unique identifier of the entity set.
• input: an input represents a <input> parameter related to a specific <operation>. It
contains the input name, input data type (String, Numeric, Boolean) and
description. Finally, input_id attribute is defined as the primary key of the entity
set involved in each service. For basic services this information is gotten from the
WSDL file.
• output: an output entity represents the <output> value that an <operation>
provides after its execution. This entity defines the datatype attribute which
contains the output data type of the operation. For basic services this information
is gotten from the WSDL file.
• resultusedservice: This entity identifies the results that a service provides when a
specific user requests a service. Each basic service response contains a
certification file and an explanation in the case the agency has a comment about
the service. System also stores the technical information to display when a service
is not available for any reason and cannot provide the expected results to the user.
31
The following relationships among entities were also identified:
• citizen_has_attribute_value: an attribute from the citizen_atribute entity can be
associated to zero or more citizens. A citizen can have many attributes. For each
common attribute, if a particular citizen has supplied a value for such attribute,
then the last value supplied is stored in this relationship.
• office_agency: an office belongs to only one agency. An agency supports several
offices. For example: Housing Government Agency has several offices in
different cities of the country.
• officer_service: an officer can register and create several services, but a service
can belong to only one officer.
• citizen_service: a service can be used by several citizens. System allows citizens
request one service many times.
• is_version_of: a parent service could have several versions, but a service version
only will belong to one parent service.
• is_composed_by: a service could be composed by other services.
• serv_operation: a service could provide several operations but a specific
operation only belongs to just one service.
• op_input: an operation can be defined by several input parameters, but a specific
input parameter only is associated with one operation.
• op_output: an operation can be provided by just one output parameter which will
be associated to just one operation.
• is_similar_to: an input parameter can be associated to other input parameter.

32
The actual implementation of the database component in I-eGS consists of several
tables that were derived from the E-R diagram shown. To do so, we have followed
standard strategies known to generate the corresponding tables [25].
3.3 Service Manager

Service Manager Component provides all the functionalities needed for the
government agencies to be able to register services, to create composite services, and to
update services in the system. This component is accessible only to administrators of the
system. I-eGS classifies services into one of the following two categories: basic services
and composed services.
3.3.1 Basic services

A basic service is any service that, at least from the point of view of the system1,
is not composite. These are services that are directly registered by government agencies,
and are not based on the integration of other services already registered in the system. It
is assumed that any government agency registering a basic service is responsible of
providing the service upon valid requests and that the service can be accessed by
invocation of the particular web service, which needs to be described during the
registration process.
Figure 3-3 shows the workflow for the registration process of a basic service
defined by the framework.
1
It may be composite inside the particular agency that supplies it, but from the point of view of I-eGS it
is a single service.
33
Figure 3-3: Registration process of a basic service
To register a service, the agency user accesses the system and begins selecting the
“repository of services” option. The system’s response is the list of registered services.
The user then selects the “Register Service” option, which generates a registration form
34
for a basic service and presents it as a web page. Such registration for requests
information about the new service such as: service name, service description, and the
WSDL file. Using the specified WSDL file, the system verifies if the provided service is
WS-I compliant and I-eGS compliant.
To execute the WS-I verification, we incorporated a WS-I test tool [26] into the
system. It reads the WSDL file for the service and verifies the interoperability of the
service by processing this file. The tool generates a report (see appendix A) that contains
information about the verification process. If the report produces a false response for the
interoperability of service, the report generated by the WS-I test tool is then made
accessible to the user for the proper analysis. If compliant, the system continues with the
execution of the I-eGS verification.
The I-eGS further includes another important customized verification to assure
that any basic service being registered complies with the expected scheme. During this
verification process the WSDL file is parsed using SAX (Simple API XML) parser in
order to extract crucial structural information about the particular service. Such
information includes: port type, operations, Input/Action, and Output/Action. Using this
information the system checks:
• Service name: The system does not allow the registration of two or more web services
with the same name.
• Service operations: A web service must have at least one operation of type request-
response. This restriction was imposed since the system is implemented to support
message exchange in the way request-response pattern; however, other patterns could
be considered in the future.

35
• Output operation: The data type of the output of the service must be Base64Binary,
which is considered as a standard to represent binary data to be included as part of an
XML file. Each service must provide as response an XML document compliant with
the I-eGServiceInfo Schema depicted in Figure 3-4 and further described afterward.
Figure 3-4: XML Schema for an Output Service
The I-eGServiceInfo schema, as shown in Figure 3-4, contains different attributes as
follows:
• name element - corresponds to the service name
• explanation element - describes the reason for the final result
• serviceresp element - the service response. We assume that any basic service
returns a binary file generated by the particular web service in charge.
• typefile element - provides information about the certification file format: pdf, gif,
jpeg, etc.
Once the system has validated the WSDL file, the data about the service that is provided
by the user and that was extracted from the WSDL file, are stored in the system database.
Then, the system generates the stub classes and the client class for the basic service.
36
Stub classes are generated using the emitter tooling that Axis provides which
allows the generation of Java classes from WSDL and the client class is created from
scratch as a .java file in the system. All those new files are stored in a folder that is
owned by the particular agency registering the service. Stubs classes and the client class
are then compiled using javac. The .class files generated are stored in the same folder.
Once the .java files are compiled and stored in the server machine, the system asks for
more illustrative information about the service, for example: the description of the
meaning of each operation and inputs of the service. This information is requested in
order to facilitate the data re-using during the integration of services.
Another important step in the registration process is to inform the system how to
treat each particular input attribute that the service requires from the citizen. Some
attributes are considered as attributes for which the value supplied may be used in future
requests, whilst others are treated as important only for the particular service. As a result
of examining several types of common government certifications, we have identified a
list of attributes about citizens that emerge on most of them, and hence we have
considered these as attributes whose values must be kept handy to be used in future
requests that may need them too. Whenever a future request is made, the system will
know if a particular attribute has a value for the particular citizen. If so, that value will be
used as the default value for the new request. The citizen will always have the
opportunity to change the corresponding values when filing the new request.
37
Figure 3-5: Establishment of a correspondence relationship among inputs service

and citizen attributes
Those most common attributes have already been included as part of the I-eGS
database, in particular, as tuples in the citizen_attribute entity. When the new service is
being registered, the agency user has to inform the system whether each particular input
corresponds to any of those citizen attributes already stored in the system. Figure 3-5
38
shows the actual interface that I-eGS provides for this purpose. Those new attributes that
are not matched with attributes already existing in the citizen_attribute entity are treated
as important only for the particular service being registered and the values supplied are
stored elsewhere in the database as part of the service request.
After the relationships among service inputs and citizen attributes is established,
the agency user needs to set up in what order the corresponding input parameters will
appear in the input form corresponding to the service. Figure 3-6 shows the user
interface that is used to establish such order.
Figure 3-6: Order of input parameters
Finally, after a basic service has been completely configured by passing through
the previous process, the service must be activated. The system will then have the service
ready to be requested by citizens or to be selected as part of a new composed service by
an agency user.
39
3.3.2 Composite services

I-eGS supports the creation of composite services, which are services
encapsulating other services previously registered in the system. These types of services
offer the citizen users an efficient way to get all certifications required by a particular
government process without having to request the underlying services individually.
We now describe the process established by I-eGS for the composition of new
services. Figure 3-7 depicts the workflow.

40
Figure 3-7: Integration services process

41
After the agency user enters the system, he or she selects the “Composition of
services” option, and a list of the composite services created by his/her particular agency
will be listed as shown in Figure 3-8.
Figure 3-8: List of composite services
The user then selects the “new composite service” button and the system responds
by requesting information about the new service, such as service name and service
description. After a valid service name is supplied, the service is created. At this moment
the system allows the user to access composition wizard by choosing “composition”
option . The main window for the composition wizard is displayed (Figure 3-9).
42
Figure 3-9: Composition Wizard
Now the user must fulfill the requirements of each step defined by the wizard. In
the following subsections we describe each step:
3.3.2.1 Step 1: selection of services
The goal of this step is that the user selects the services that will be part of the
new service. In order to support the service selection, the system provides a mechanism
to perform service searches by service name or service agency provider over the service
repository. When a user selects a service to be part of the composition, the system
verifies if the selected service is part of a recursive circle in the composition. If it is so,
the selected service cannot be part of the new service.
Figure 3-10 shows the screen shot for the selection of services. User interaction
with the system, during the service selection process, was developed keeping in mind the
usability guidelines for a shopping cart. Hence, the user can add and remove services
until she or he decides to finish the selection process.

43
Figure 3-10: Step 1: Selection of Services
The conclusion of this step 1 is only possible when two or more services have
been selected to be part of the new service. If it is then the user can finish step 1 and
continue building the service in the next step.
3.3.2.2 Step 2: Relationships among attributes
Since many of the services provided by government agencies require as input
parameters with similar information, we provide a mechanism that allows the user to
establish relationships amongst input parameters of the services that are part of the
44
composition. For example, let’s assume the existence of a composed Service C which is
formed by service D and service H (Table 3-2).
Table 3-2: Service C, composed by service D and service H
Service C
Services Input Parameter Meaning
d1 Social Security Number
d2 First Name
Service D d3 Second Name
d4 Last Name
d5 Second Last Name
h1 Num of receipt
h2 Social security Number
h3 First Name
Service H h4 Last Name
h5 Second Last Name
h6 Home Phone Number
h7 Mobile Phone Number
As it is shown in Table 3-2, service D and H have input parameters whose
meanings are similar, for instance the meaning of the input parameter d1, Social Security
Number, is similar to the meaning of input of the parameter h2 for service H. Then the
service C must define a new input parameter composed by d1 and h2, in order to ask to
the citizen user for the social security number only once when the user requests service C.
The possible relationships established amongst input parameters of services D and
H that allow to determine the new attributes for the service C could be defined as it is
exposed in the Table 3-3.

45
Table 3-3: Input attributes of composed service C
Input
Meaning and association
Parameters
Social Security Number
c1 This attribute is associated with input d1 and h2 of their respective
services.
First name
services
Second name
c3
This attribute is associated with input d3 of service D.
Last name
services
Second Last name
services
Home Phone Number
c6
This attribute is associated with input h6 of service H.
Mobile Phone Number
c7
This attribute is associated with input h7 of service H.
I-eGS allows the user to establish the service new attributes by selecting the
related attributes and creating a new one using the selection (see Figure 3-11). For this
purpose, the user must provide the name for the new attribute and a short description for
it. When an attribute does not have a relation with any other service’s attribute, the
system creates automatically a new attribute exactly alike for the new service. Once the
agency user has established the relationship among input parameters, the system allows
to define the order in which the parameters will be asked to the user through a web form.
46
Figure 3-11: Step 2: Configure Attributes
Finally, once this step is finished the user has to continue with the following step
“Verification of Service”.
47
3.3.2.3 Step 3: Verification of Service
The verification of a service is defined in order that a user can check that the
service was properly performed before releasing it. The user can modify only the
descriptive information that is associated with the input parameters of the new service.
When the user finishes step 3, the system enables the access to configure the service.
However an option is available if the user decides to make additional changes in the
service (see Figure 3-12).
Figure 3-12: Configured service
The user can perform changes in the processes involved into step 1 and 2 only if
the service has not been used by an agency or a citizen. To modify the descriptive
information, with step 3 will always be possible.
3.4 Web Portal

From the users’ perspective, the I-eGS is a portal where they can have access to
system operations that are available under the own user rights. In section 3.3 we
described the main functionalities available for agency’s users. In this section we will
48
expose the main functionalities that the system provides for administrator and citizen
users.
3.4.1 Administrator Users

A user administrator is able to manage information related with agencies, offices
and users. She or he is also responsible for maintaining and managing the basic
information that system needs to operate. The system allows the user administrator to
execute the operations described in the following subsections.
3.4.1.1 Manage Agencies and Offices information
The user administrator is able to register an agency or/and office. This registration
process implies the creation of a folder into the system exclusively for the agency and/or
office. The folder created for an agency, stores all folders belonging to offices associated
with that agency. The stub classes and client classes of the services are stored into the
offices folders.
3.4.1.2 Manage Users
The system allows administrator user to perform the registration, modification
and inactivation of users (citizen users and agency users). Main window of user
management is shown in Figure 3-13.

49
Figure 3-13: User manager
Registration information related with users can be modified by user
administrators. All users can modify their personal information such as name, last name,
username and password.
3.4.1.3 Manage Citizens Attributes
As we mentioned previously, the information associated with a citizen that is
handled by most of governmental agencies is often the same. Many services provided by
different agencies could request the same information.
In the registration process described in the section 3.3.1 is mentioned that the
system allows to associate the service input parameters to a specified citizen attribute.
Due to this the system enables this functionality to create, update or inactive citizen
attributes to be used for the system (see Figure 3-14).

50
Figure 3-14: Citizen Attributes Configuration
Administrator user is able to do the registration, update and to inactivate the
citizen attributes that can be associated to a service input parameter.
Features described are the main functionalities that the system provides for a user
administrator. In the next section we will describe the main functions that the system
provides to a citizen user.
3.4.2 Citizen User

The citizen can access the system providing the correct username and password.
Once the citizen user is inside the system, she or he can access the information of the
services that he or she had used, or can request a new service. It is shown in Figure 3-15.
51
Figure 3-15: History of services
System can execute the search of a service using the service name or the name of
government agencies that provide the service. Once the user selects a service from the
search result list, the system shows the form associated to the service (see Figure 3-16).
The form contain fields associated with the input parameters defined for the selected
service. The user must fulfill the form in the correct way in order to allow the system to
process the request, sending to the pertinent services the data provided by the user.
The system verifies the data type of the user inputs. These must be valid based on
the service inputs data type defined by the service

52
Once the verification is done, the service engine (described in section 3.5)
processes the user request and provides the answer to the user (see Figure 3-17). The
answer that system provides to a user request is composed by a certification or a list of
certifications. Each certification provides the following information:
Name of certification
Description of certification
Meaning of the certification
PDF file with the certification

53
When the service that provides a certification is not available the system warns
the citizen with a warning signal and stores the failed request in the system.
The system stores the results of the execution of each service to dispose this
information for history of the system or when the user wants to request the same service
again. Users can access services results when they have the necessity.
3.5 Services Engine
This component has the responsibility to process the request to a service. Figure
3-18 provides a general perspective of the interactions established into the service engine.
54
Figure 3-18: Service Engine
In the following lines we describe how the system handles a service request.
When the user selects a service the ReqInfoServiceServlet handles the request by
invoking the DataInputAnalizer, which is in charge of discovering what citizen
information the system needs in order to process the service request. DataInputAnalizer
is a set of Java Beans that the system implements to get information about input
parameters of a service and the citizen’s information stored in the database system that
can be matched with the service’s input parameters.
Information recovered by the DataInputAnalizer is sent through the
ReqInfoServiceServlet to a Java Server Page. This disposes all the recovered information
in a form that is displayed in the web browser in order that it can be filled by the citizen
user by providing the required information. Once the user has submitted the form an
HTTP request is launched, it is handled by means of the RequestServiceServlet which
through DataInputAnalizer gets information about the service. When the requested
55
service is composed, DataInputAnalizer gets information of basic services that integrate
the service, input parameters defined for each one of services involved in the composition
and the relationships established amongst their attributes. System uses a
Hashtable<String,Service> structure to store the information about basic services
involved in the request and other Hashtable<String,InputWSDL> structure to store
information about the input parameters of each service involved in the request. Once this
information is stored, the Controller instances a Worker Thread by each basic service
involved in the request, than means an instance for each service stored in the
Hashtable<String,Service> structure. In order to dispose the system to invoke the
required service, each Worked Thread performs the following tasks:
• With the information that DataInputAnalizer provides to the controller, Worked
Thread rearranges input parameters in the required order and creates an object array
with the values for each parameter. These values are equivalents to the information
provided by citizen user. An object array with the data type of input parameters is
created, as well.
• The service’s information is used to get the path where the service’s Stub classes and
Client class are stored. These classes are loaded into the Servlet container using a
class loader.
Once each Worked Thread executes the above tasks, it sends a SOAP request to
its service by instancing the service’s Client class using Java Reflection to sent a request
to the service and wait for the its response. Once the response is received by the
Controller, it waits until each invoked services had ended. The Controller know that is
56
ready to send a response to the user, when the number of services that had sending a
response is equal to the number of Worked Thread that it had invoked. If an exception is
launched during a service request, the system takes on the message Exception as a
response and informs to the user that the service is not available. The Controller will
process the respective answer for the user and finally send the information to
RepondServiceServlet which sends an HTTP response to the web portal so the citizen will
have the answer to the requested service. When a service is not available, system throws
an exception and stores this information to send a report to the agency provider.
57
CHAPTER 4
4. Functionality tests
Development of a software system implies the execution of different activities
that involve the possibility that several errors could be introduced during the development
process.
Due to this, the execution of a series of tests is a critical element that provides a
guarant regarding the software quality. Tests provide a way to determine the state of a
software product in terms of accuracy by means of a revision of the requirements, design
and codification.
Any engineering product can be tested in two ways [27]:
1. Executing tests that allow to verify functionalities of the product. These tests are
called “black box tests” and it is imperative to know the specific functionalities the
product was designed for. Black Box Test cases aim to demonstrate the correct
working of the functionalities provided by the system.
2. Executing tests that allow to verify that each component of the product performs its
internal processes in an appropriate way. These tests are known as “white box tests”
and their test cases are oriented to perform specific sets of conditions and/or loops.
In the context of the present project a set of black box tests were carried out.
These aimed to verify behavioral aspects of the I-eGS system, by focusing on the
58
functional requirements that the system provides. In the following sections we describe
the design, development, and results of the tests performed.
4.1 Test enrollment

In order to execute the functionality tests, a test environment was configured. It
was constituted by seven machines that worked as government agency servers, where
agency services were located. Fifteen dummy Web services were prepared and
distributed in these machines. Table 4-1 lists the services with the corresponding agency
provider.
Table 4-1: Basic services and agency providers
Service Name Agency provider

Certification of Education University of Puerto Rico
Certification of Final Exam - Bachelor Engineering Examination Services
Certification of Incorporation Department of State
Permission to perform commercial
Department of Treasury
activities
Certification of criminal record Police Department
Marriage Certification Demographic Register Office
Birth Certificate Demographic Register Office
Certification of no debt with children or
Department of Treasury
spouse from any previous marriage
Permission to perform activities in the
Office of Mayor
municipality
Certification of payment Department of Treasury
Certification of Internal Rents payments Department of Treasury
Certification of no tax debt Department of Treasury
Membership Certification Professional Engineers Society
Certification of transit Department of Transportation
Certification of Valid Driver license Department of Transportation
Certification of a medical plan Department of Health
Certification of a valid Social Security
Social Security Federal Department
Number
59
A desktop computer with an Intel Pentium processor at 2.66 GHz with 1024KB of
Level 2 cache, 1 GB of RAM, and an IDE ATA/100 Linux Operating System as
minimum requirements was used for simulate each government agency server.
I-eGS system was placed in a desktop computer with an Intel Pentium processor
at 2.80 GHz with 1024KB of Level 2 cache, 2 GB of RAM, and an IDE ATA/100 with
Linux Operating System.
Machines used during the tests execution were located in the same network
segment.
4.2 Tests Procedure

A good test is not one that finds no errors, instead, is one that can detect the
greatest number of errors in a product, is not redundant, and is neither too simple or too
complex. [27].
In order to execute functionality tests to I-eGS, two test plans were defined. First
one checks the functionalities for government agencies’ users and the second one checks
the functionalities for citizen’ users. Both test plans were oriented to find errors such as
those listed below:
• Incorrect or missing functions
• Interface errors
• Errors in data structures or external data base access
• Behavior or performance errors
• Initialization and termination errors.

60
Test plans were constructed taking into account the guidelines provided by IEEE-
829 Standard for Software Test Documentation [28]. These plans define activities that
allow users to make use of the system while they are trying to detect features that do not
work properly. Appendix A contains test plan designed to execute the black box tests.
Each plan was executed by a set of subjects with knowledge in software
development process. They were intentionally selected since their background in
software development would allow them to introduce intentional mistakes to verify the
system response.
4.3 Test Results

During the test execution mistakes and errors were detected in the system. This
information was used to make improvements in order to obtain a more accurate system.
• Wizard lack of information that support the creation of a new service.
Actions: It is necessary to provide more information during the execution of each step.
Documentation of the wizard must be published in the system in order that user can know
how to execute the integration of services.
• System does not allow to go back in a step to perform changes.
Actions: More flexibility in the wizard must be introduced. When the modification in a
step can not be performed, system must provide information indicating the reasons.
• Some messages that the system produces as a user response have no meaning
Actions: Messages that system produces as a user response must be verified and
redefined to provide the correct feedback message to the executed actions.

61
• System does not indicate what information is required in a form. Sometimes, when
the user does not introduce required information into fields form, the system performs
the process without giving a warning message.
Actions: Add a mechanism that allow user to know what information is strictly required.
Set warning messages for all required fields.

62
CHAPTER 5
5. Summary and Future Work
We have implemented I-eGS, a system to support the registration and further
integration of government services into a Web-based portal. Registration of services, as
well as composition of new ones, is directly done by the government agencies, without
requiring human intervention at the portal site. The current version of the system is
capable of handling services that produce a final certification to the applicant after proper
evaluation of the data being submitted through the corresponding application.
Each agency is assumed to have a local system that is able to handle a service
request. To register that service into the portal, the agency needs to provide a Web
service that handles the interaction with their local implementation of the service. Web
services are registered into the system by submitting the corresponding WSDL files, from
where the necessary classes to invoke the service are automatically generated. The
system also supports the integration of existing services. This way, new services are
generated by combining other services and allowing transparent access to each of them,
regardless of the agencies involved. So, in the actual version, this means that a bunch of
certifications can be produced as a result of one application and with the applicant being
aware as to which agencies need to be contacted.
To support the service integration process, the system includes a composition
wizard, which is aimed to guide agency users during the composition of new services.
63
Through this component, the agency users are able to pick services that will be part of a
composition. It further supports the integration of the selected services by allowing the
agency user to combine attributes corresponding to the same data in the different services
being combined, Finally an integrated application form generated for each composite
service, significantly reducing the forms filling effort of future applicants.
From the point of view of citizens, the system acts as a Web portal from where
government services can be requested, the system hides details as to what agencies might
have to cooperate in complying with the requests. With the goal of supporting a more
agile process whenever an individual comes back to use the system in the future, the
system keeps a specialized database that stores relevant data about those citizens that
have used the system. These data will be ready to be used by the system , as default data,
whenever required on future requests.
Recently, the Government of Puerto Rico inaugurated a Web-portal which has
similar goals as ours, at least from the point of view of the citizens. It differs from ours
in several aspects. One is that the requests are forwarded to the particular agency in
charge of providing the particular certification being requested and such agency mails the
final certification to the requester through regular postal mail. Furthermore, the process to
register new services to be presented to the citizens needs the human intervention at the
central site, hence slowing down the registration process.
We feel that the I-eGS as it is now is a valuable tool upon which more relevant
work on integration of government services can be done. One important aspect that still
needs to be more rigorously explored is the security issue. The current version of I-eGS
implements its security at the application level, but other approaches need to be taken
64
into consideration in order to provide the necessary security robustness. This will be
crucial if we want citizens to be more willing to use the system and to provide his/her
data without being afraid of unauthorized access by others.
It would be also necessary to perform a Cost-Benefit Analysis (CBA) in order to
estimate and total up the equivalent money value of the benefits and costs a system like
I-eGS would yield to the government and to the society in general.

65
REFERENCES LIST
[1]. CORBA. Common Object Request Broker Architecture. http://www.omg.org.
[2]. DCOM. Distributed Component Object Model. http://www.microsoft.com
[3]. RMI. Remote Method Invocation. http://java.sun.com
[4]. Web Services. http://www.w3.org
[5]. Graham, Steve., Simeonov, Simeon., Boubez, Toufic., Daniels, Glen., Davis,
Doug., Nakamura, Yuichi., and Neyama, Ryo. Building Web Services with Java.
Second Edition, 2005. Sams publishing. 2005
[6]. Simon. W, Graham. M and Simon. P. Portal Replication for Web Application
Availability Via SOAP. The Eighth IEEE International Workshop on Object-
Oriented Real-Time Dependable Systems, 2003.
[7]. Christensen, E., Curbera, F., Meredith, G., and Weerawarana, S. Web Services
Description Language (WSDL) Version 1.1, W3C Note, March 2001;
www.w3.org/TR/wsdl.html.
[8]. UDDI Spec Technical Committee, UDDI Version 3.0.2, October 2004;
http://uddi.org/pubs/uddi-v3.0.2-20041019.htm
[9]. Weerawarana, S., Curbera, Francisco., Leymann, Frank., Storey, Tony., and
Ferguson, Donald F. Web Service Platform Architecture. Prentice Hall, 2005
[10]. Endrei, Mark., Ang, Jenny., Arsanjani, Ali., Chua, Sook., Comte,
Philippe., Krogdahl, PŒl., Luo, Dr Min and Newling, Tony. Patterns: Service-
Oriented Architecture and Web Services red book. First edition. International
Business Machines Corporation, 2004.
[11]. Ong M, Alkarouri M, Ren X, Allan G, Kadirkamanathan V, Thompson

HA and Fleming P. Grid-Based Decision Support with Pro-Active Mobile
Computing. International Conference on Services Computing (SCC’05), 2005.
[12]. McGovern,James., Tyagi, Sameer., Stevens,Michael., and Mathew,

Sunil. Java Web Services Architecture, Sun Microsystems. Ch 2.
[13]. Paulson,Viktor. Web Service Interoperability Issues. Master of Science

Thesis Stockhol, Sweden 2005.
[14]. Stephenson, David. Tips for solving web service interoperability

problems. Hewlett-Packard, 2004
66
[15]. Ramakrishnan, R., and Gehrke, J. Database Management Systems, 3rd.

Edition, International Edition, McGraw-Hill, Ch. 1, pp. 4, 2003.
[16]. Codd, E.F., A Relational Model of Data for Large Shared Data Banks,
Communications of the ACM, vol. 13, no. 6, pp. 377-387, June 1970.
[17]. Singh, Inderjeet., Stearns, Beth., Johnson, Mark., and The Enterprise
Team. Designing Enterprise Applications with the J2EE Platform, Second
Edition.
[18]. PC-WARE. E-Government Integration Kit. http://www.pc-

ware.com/pcw/com/en/services/solutions/e-government/egik/main.htm
[19]. Queens University Belfast, North Ireland, United Kindom.

http://www.qub.ac.uk/
[20]. Cherrie W.W. Ng and Dickson K.W. Chiu. e-Government Integration with
Web Services and Alerts: A Case Study on an Emergency Route Advisory System
in Hong Kong. Proceedings of the 39th Hawaii International Conference on
System Sciences, 2006
[21]. Oficina de Tecnologías de Información gubernamentales Unidad para la

administración de transacciones electrónicas. Agency Monitor. www.gobierno.pr
[22]. Vargas-Solar. G., Peñalva-Lozada, P. Building WEB services portals:

implementation experiences. IEEE International Conference on Services
Computing (SCC’05), 2005.
[23]. Chaoying Ma Bacon, L. Petridis, and M. Windall, G. Towards the Design

of a Portal Framework for Web Services Integration. Advanced International
Conference on Telecommunications and International Conference on Internet and
Web Applications and Services, 2006.
[24]. Acuña, Cesar J., Marcos, Esperanza., Gómez, Juan M., and Bussler,
Christoph. Towards Web Portal integration through Semantic Web Services.
International conference on next Generation Web services Practices, 2005.
[25]. Avi Silberschatz Henry F. Korth S. Sudarshan. Database System

Concepts, 5th Edition. McGraw-Hill ISBN 0-07-295886-3
[26]. Web Service Interoperability Organization, http://www.ws-i.org/
[27]. Pressman, Roger S. Software Engineering, a practitioner’s approach.

McGraw-Hill Series in Computer Science. 5th edition. Chapter 17.
[28]. IEEE Std 829-1998 IEEE Standard for Software Test Documentation.
67
APPENDIX A: WS-I REPORT

68
APPENDIX B: TEST PLANS
I-eGS: Framework for the integration of Government Services
Test plan for a Government Agency User

1 Objective
To verify functionalities that I-eGS system provides to a government agency, to identify
potential defects, mistakes or failures in the system.
2 Description
Test plan is composed by four main steps. It must be fulfilled following the specified
order.
This plan test will verify the correct operation for:
Register, update and delete information citizen attributes
Register of basic services
Integration of services
Update of information related to services
Links between pages.
Java Script code for HTML pages.
Response of the system for possible user errors.
3 Test environment
Hardware and software required to the execution of this test plan is listed below:
• Hardware: To execute this test is required a Server machine, two client computers.
Server has to be accessed by clients through a HTTP connection.
• Software
Server Machine
Linux System Operator
Apache Tomcat Web Server 5.1
MySQL 5.1
69
Axis 1.4
JDK 1.5
SAX Parser
Client Machines
Browser with HTML 4.01, CSS 3.0, AJAX.
4 Observations
The kind of mistakes detected during the test execution will be determinate if the test
must be restarted or suspended. Test will be suspended when an exception at the
application level occurs, database connection errors, HTTP connections errors or script
errors on the server side. Test will be restarted when the errors detected are related with
typos. In the case of a test suspension, please write the cause to continue:
5 Test Execution
The following information will be required to execute the test procedure. Files provided
contain definitions of services that an agency could provide
Server IP: http://136.145.116.95:8080/PortalEGov/

Client IP: _________________________________
Browse r: _________________________________
Date: _________________________________
Username: entity13
Password: entity13
Files: CertificationSSN.wsdl, CertificationHealth..wsdl
6 Test procedure
I-eGS provides to a government agency the necessary functionalities to register Basic
services and create new ones. In the following subsection you will found a set of
70
activities that you must perform. Please, try to introduce possible user mistakes or
execute operations that you think the system must avoid or permit.
A basic service is a service provided by a government agency. System must support the
registration of these services by means of the WSDL file of the respective service. A
composed service is a service that is composed by two or more services. I-eGS will
guide you during the creation of a composed service.
6.1 Registration and configuration of a basic service

In this phase of the test you must to use WSDL files provided. First, access the system
with information provided. Then go to the “repository of services” option and register the
basic services. Remember that you must provide information of the input parameters of
the service, and must select the citizen attributes that could be associated with the input
parameters.
Observations:____________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
6.2 Composition of a service

In this phase of the test you will compose a service. You can access to the
composition service window by clicking the “Composition of service” option. You
must create the new service by providing the service name and description. Then
select the Composition option so that you can access to the Composition Wizard
which has established three steps.
Step 1: In this step you must select the services that will part of the new service.
71
Observations:____________________________________________________________
________________________________________________________________________
________________________________________________________________________
Step 2: In this step you must define the input parameters for the new service.
Observations:____________________________________________________________
________________________________________________________________________
________________________________________________________________________
Step 3: In this step you can modify the registration information of the service.
Observations:____________________________________________________________
________________________________________________________________________
________________________________________________________________________
After finished the third step, try to modify the definition of your service, adding a new
service, modifying the attributes that you previously defined.
Observations:____________________________________________________________
________________________________________________________________________
________________________________________________________________________
6.3 Update account information

Try to modify your personal information, include you username and password.
Observations:____________________________________________________________
________________________________________________________________________
________________________________________________________________________
72
7 Report of results
Please fulfill the following table base on the actions that you executed previously
Test Approve Not approved Observations

1 Have you been able to
execute satisfactorily the
registration of basic services?
creation of a composed
service?
3 Have you been able to update
the information related to a
service?
4 Did you found break links?
5 During the test execution, did
you found any JavaScript
error?
6 When you introduced user
errors to the system, did it
response in a correct way?
Observations
If you have any suggestion that you consider will contribute to improvement of the system
please write them at the last page of this document.
73
I-eGS: Framework for the integration of Government Services
Test plan for a Citizen User

1 Objective
To verify functionalities that I-eGS system provides to a citizen user, to identify potential
defects, mistakes or failures in the system.
2 Description
Test plan is composed by four main steps. It must be fulfilled following the specified
order.
This plan test will verify the correct operation for:
Request of basic services
Request of composition services
Reuse of the information among services
Storing of history of services
3 Test environment
Hardware and software required to the execution of this test plan is listed below:
Hardware: To execute this test is required a Server machine, two client computers.
Server has to be access by clients through a HTTP connection.
Software
Server Machine
Linux System Operator
Apache Tomcat Web Server 5.1
MySQL 5.1
Axis 1.4
JDK 1.5
SAX Parser
Client Machines
Browser with HTML 4.01, CSS 3.0, AJAX support.
74
4 Observations
The kind of mistakes detected during the test execution will be determinate if the test
must be restarted or suspended. Test will be suspended when an exception at the
application level occurs, database connection errors, HTTP connections errors or script
errors on the server side. Test will be restarted when the errors detected are related with
typos. In the case of a test suspension, please write the cause to continue:
5 Test Execution
The following information will be required to execute the test procedure.
Server IP: http://136.145.116.95:8080/PortalEGov/

Client IP: _________________________________
Browse r: _________________________________
Date: _________________________________
Username: citizen1
Password: citizen1
6 Test procedure
I-eGS provides the citizen access to the services that government agency provide. Citizen
can execute searches in the system and requests the services by providing the required
information. System stores some selected information provided by the citizen in order to
be reused in other services that required the same information.
6.1 Request of services

First, access the system with information provided then goes to the “services” option,
execute the service search and request a service. Repeat this process for five services.
75
Observations:____________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
6.2 Query requested service History

In this phase of the test you will access to a service that you requested previously.
Requested services are listed in the “History of services box”. Verify if the information
provided is the same that service provided when you did the request to the agency by
providing your information.
Observations:____________________________________________________________
________________________________________________________________________
________________________________________________________________________
6.3 Update account information
Try to modify your personal information, include you username and password.
Observations:____________________________________________________________
________________________________________________________________________
________________________________________________________________________
7 Report of results
Please fulfill the following table base on the actions that you executed previously

execute satisfactorily search
of services?
request to services?
3 Did you realize of the reuse of
information among services?
4 Did you found break links?
5 During the test execution, did
you found any JavaScript
error?
76

6 When you introduced user
errors to the system, did it
response in a correct way?
Observations
If you have any suggestion that you consider will contribute to improvement of the system
please write them at the last page of this document.

A Framework For Integration of Services Offered

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

A Framework For Integration of Services Offered

Uploaded by

Copyright:

Available Formats

A FRAMEWORK FOR INTEGRATION OF SERVICES OFFERED BY

Manuel Rodríguez Martínez, Ph.D. Date

Bienvenido Vélez, Ph.D. Date

Pedro I. Rivera Vega, Ph.D. Date

Loida Rivera Betancourt, Ph.D. Date

Isidoro Couvertier, Ph.D. Date

ubiquitously accessible to citizens. The system is a Web-based application, hence

new ones. Each single government service is assumed to be realizable through a

concerned as of which agencies need to submit particular approvals or certifications that

to citizens and which may involve several agencies.

El objetivo principal de este trabajo ha sido el desarrollo de un sistema que facilite

gobierno podrá utilizarla en la creación de un nuevo servicio. El sistema permite que un

que invertir en el momento de solicitar el servicio. Esto se logra de dos maneras:

minimizando la información personal que cada ciudadano tiene que proveer,

independientemente de cuántas agencias se vean involucradas en proveer el servicio, y

recuperando información personal que el ciudadano pueda haber provisto en visitas

en servicios de otorgar certificaciones que cada agencia es responsable de expedir a los

in the way that He has done.

of my difficult moments. I would like to equally express my gratitude to the members of

their help and advice throughout this project.

family as it were my own.

Thanks to CheTaz Corporation: my Friends from Argentina, Brazil, Colombia,

here who have also helped me throughout the years.

RESUMEN ....................................................................................................................... III

LIST OF FIGURES ........................................................................................................... X

LIST OF ABREVIATIONS ............................................................................................XII

2. LITERATURE REVIEW ........................................................................................... 6

3. INTEGRATION OF E-GOVERNMENT SERVICES FRAMEWORK.................. 23

5. SUMMARY AND FUTURE WORK ...................................................................... 62

REFERENCES LIST ........................................................................................................ 65

APPENDIX A: WS-I REPORT........................................................................................ 67

APPENDIX B: TEST PLANS.......................................................................................... 68

Table 3-1: Symbols used in the E-R notation ................................................................... 26

Table 3-2: Service C, composed by service D and service H........................................... 44

Table 3-3: Input attributes of composed service C ........................................................... 45

Table 4-1: Basic services and agency providers ............................................................... 58

Figure 2-1: Web Service Invocation ................................................................................... 8

Figure 2-2: Syntactic structure of a WSDL document........................................................ 9

Figure 2-3: Service-Oriented Architecture ....................................................................... 12

Figure 2-4: Model-View-Controller Pattern ..................................................................... 17

Figure 3-1: Framework Architecture ................................................................................ 24

Figure 3-2: Entity-Relationship Diagram for I-eGS Database ......................................... 27

Figure 3-3: Registration process of a basic service .......................................................... 33

Figure 3-4: XML Schema for an Output Service.............................................................. 35

Figure 3-5: Establishment of a correspondence relationship among inputs service and

citizen attributes ................................................................................................................ 37

Figure 3-6: Order of input parameters .............................................................................. 38

Figure 3-7: Integration services process ........................................................................... 40

Figure 3-8: List of composite services.............................................................................. 41

Figure 3-9: Composition Wizard ...................................................................................... 42

Figure 3-10: Step 1: Selection of Services........................................................................ 43

Figure 3-11: Step 2: Configure Attributes ........................................................................ 46

Figure 3-12: Configured service ....................................................................................... 47

Figure 3-13: User manager ............................................................................................... 49

Figure 3-15: History of services ....................................................................................... 51

Figure 3-16: Citizen Attributes Configuration.................................................................. 52

Figure 3-17: Citizen Attributes Configuration.................................................................. 53

Figure 3-18: Service Engine ............................................................................................. 54

ACID Atomicity, Consistency, Isolation, Durability

organizations to support their day-to-day interaction with customers. Some noteworthy

hidden distributed collaboration that is typically needed in the Web-based service

have become affordable to typical businesses, allowing them to complement their