interoperability in e-government services

UNIVERSITA DEGLI STUDI DI CAMERINOSCHOOL OF ADVANCED STUDIES

DOTTORATO DI RICERCA IN SCIENZE DELL’INFORMAZIONE E

SISTEMI COMPLESSI - XXI CICLO

SETTORE SCIENTIFICO DISCIPLINARE INF/01 INFORMATICA

DIPARTIMENTO DI MATEMATICA E INFORMATICA

Interoperability ine-Government Services

Relatore Dottorando

Ing. Alberto Polzonetti Francesco De Angelis

Commissione

Prof. Rocco De Nicola

Prof.ssa Paola Inverardi

Prof. Enrico Nardelli

ANNO ACCADEMICO 2007-2008

UNIVERSITA DEGLI STUDI DI CAMERINOSCHOOL OF ADVANCED STUDIES

DOCTOR OF PHILOSOPHY IN INFORMATION SCIENCE AND

COMPLEX SYSTEMS - XXI CYCLE

DIPARTIMENTO DI MATEMATICA E INFORMATICA

Interoperability ine-Government Services

Advisor PhD Candidate

Ing. Alberto Polzonetti Francesco De Angelis

Advisory Board

Prof. Rocco De Nicola

Prof.ssa Paola Inverardi

Prof. Enrico Nardelli

ACADEMIC YEAR 2007-2008

Your time is limited, so don’t waste it living someone else’s life.Don’t be trapped by dogma which is living with the results ofother people’s thinking. Don’t let the noise of others’ opinionsdrown out your own inner voice. And most important, havethe courage to follow your heart and intuition. They somehowalready know what you truly want to become. Everything elseis secondary. [. . . ] Stay Hungry. Stay Foolish.

Steve Jobs

To my grandparents

Abstract of the Dissertation

Today, e-Government is an emergent multidisciplinary research field that has theaim to support the delivery of electronic information and services to citizens, busi-nesses, and other stakeholders. This vision should be based on an effective co-operation between Public Administrations (PAs) that need to be more and moreorganized to delivery value-added e-Government services. Such cooperative en-vironments should interconnect several PAs using interoperability architecturesexploiting the service-oriented paradigm.

Service-orientation provides a general framework to enable interoperabilityallowing different systems to exchange data, participate in business processes, andcooperate to reach a common goal. Furthermore, a strong relationship betweenthe e-Government high-level service concept and the more technological serviceconcept used in Service Oriented Architectures has been found analysing currentresearch.

In this thesis I propose some design guidelines for the engineering of service-oriented systems for the delivery of e-Government services. The role of metadatais discussed as a fundamental for the development of interoperability architecturesinside the domain and a central role has given on documents production and de-scription. Moreover, some approaches to testing and verification are showed toimprove the development of the service-oriented backend of Public Administra-tions.

Although these approaches has been studied and developed in e-Governmentdomain, some of them can be applied in generic service-oriented systems.

Acknowledgements

During these three years of PhD I have had the fortune to know a lot of interestingpeople whose value contribute to build an amazing working environment. Work-ing with them has improved me in a professional and personal way. I recall themoments of study, work, and fun with enthusiasm. Without their ideas and theirsupport, this thesis would never have happened.

I am sincerely grateful to my adviser, Ing. Alberto Polzonetti and I am verythankful to Prof. Flavio Corradini for their mentorship, encouragement, and ad-vice throughout these years, having a strong belief in my capabilities.

I am thankful to dott. Andrea Polini for the cooperation and the time andenergy spent to support me in the work on testing. Discussions with him helpedme to grow professionally. He is a precious colleague and is a pleasure workingwith him.

I have had the great pleasure of working with a wonderful set of people, ex-cellent collaborators and Friends in the research group I belong and in the staffof e-Lios s.r.l. the spin-off company I helped to found as a result of invaluablecollaboration of smart people. I thank all of them.

Finally, let me conclude by thanking my family for their help and support overthe last years. Their encouragement has been a great source of energy, that hashelped me become the person I am today.

List of Publications

[CDE+05] F. Corradini, F. De Angelis, C. Ercoli, A. Polzonetti, and B. Re. Infras-trutture per il miglioramento dei servizi di e-Government: considerazioni elinee di sviluppo. In Congresso Annuale AICA, Udine (Italy), 2005.

[CDNP05] F. Corradini, F. De Angelis, S. Nepi, and A. Polzonetti. Dynamic servicesmodeling for e-Government applications. In ITI 3rd International Confer-ence on Information & Communication Technology (ICICT), Cairo (Egypt),2005.

[CDPR05] F. Corradini, F. De Angelis, A. Polzonetti, and O. Riganelli. ServiceDiscovery in E-gov Environments. In IADIS International ConferenceWWW/Internet 2005, Lisbon (Portugal), 2005.

[CDPR06a] F. Corradini, F. De Angelis, A. Polzonetti, and B. Re. Quality Evaluationof e-Government Digital Services. In International Conference on DigitalGovernment Research (dg.o 2006), San Diego (California, USA), 2006.

[CDPR06b] F. Corradini, F. De Angelis, A. Polzonetti, and B. Re. Quality Model forDigital e-Government Services. In ICEG 2006: The 2nd InternationalConference on e-Government,, Pittsburgh, (Pennsylvania, USA), 2006.

[CDE+06] F. Corradini, F. De Angelis, C. Ercoli, A. Polzonetti, and B. Re. Consid-eration to improve e-Government infrastructure. In IADIS InternationalConference e-Society, Dublin (Ireland), 2006.

[CDPB06] F. Corradini, F. De Angelis, A. Polzonetti, and E. Brugnoni. Sviluppodi un’ontologia per l’e-Government: un caso di studio per un documentoitaliano. In Congresso Annuale AICA (AICA 2006), Cesena (Italy), 2006.

[CDP+06] F. Corradini, F. De Angelis, A. Polzonetti, B. Re, and E. Brugnoni. e-GovQoS: an Ontology for Quality of e-Government Services. In DEXAFifth International EGOV Conference, Krakow (Poland), 2006.

xii

[CDEP07] F. Corradini, F. De Angelis, C. Ercoli, and A. Polzonetti. A Services Man-agement System for Small and Disadvantaged Communities. In 29th Inter-national Conference Information Technologies Interfaces, Cavtat - Dubrovnik(Croatia), 2007.

[CDP07] F. Corradini, F. De Angelis, and A. Polzonetti. Verification of WS-CDLchoreographies. In The 2nd European Young Researchers Workshop onService Oriented Computing, Leicester (United Kingdom), 2007.

[CDPP07] F. Corradini, F. De Angelis, R. Pruno, and A. Polzonetti. Ontology-Drivendevelopment of Intelligent Documents. In TED Conference on e-Government(TCGOV07) (conjunction with the 10th Int. Conf. on Business InformationSystems), Poznan (Poland), 2007.

[CDPR07a] F. Corradini, F. De Angelis, A. Polzonetti, and B. Re. Interoperabilitae cooperazione nell’e-Government: il ruolo dei metadati. In CongressoAnnuale AICA Cittadinanza e Democrazia Digitale, Milano (Italia), 2007.

[CDPR07b] F. Corradini, F. De Angelis, A. Polzonetti, and O. Riganelli. An Automata-based Adaptation for Services Behavior. In eGov-INTEROP’07 Conference- eGovernment Interoperability Campus 2007, Paris (France), 2007.

[CDPP08a] F. Corradini, F. De Angelis, A. Polini, and A. Polzonetti. A ParticipantTesting Strategy for Service Orchestrations. In IEEE Third InternationalConference on Digital Information Management, London, (United King-dom), 2008.

[CDPP08b] Flavio Corradini, Francesco De Angelis, Andrea Polini, and Alberto Pol-zonetti. Improving Trust in Composite eServices Via Run-Time Partici-pants Testing. In DEXA Seventh International EGOV Conference, pages279–290, Torino (Italy), 2008.

Contents

Abstract of the Dissertation vii

Acknowledgements ix

List of Publications xi

List of Figures xvii

1 Introduction 1

I Background 7

2 e-Government Systems 92.1 Definitions and Scope . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Managing e-Government . . . . . . . . . . . . . . . . . . . . . . 12

2.2.1 Management of Systems . . . . . . . . . . . . . . . . . . 122.2.2 Management of Public Data . . . . . . . . . . . . . . . . 13

2.3 Implementing e-Government . . . . . . . . . . . . . . . . . . . . 152.3.1 Systems Life-cycle . . . . . . . . . . . . . . . . . . . . . 152.3.2 Design of e-Government Systems . . . . . . . . . . . . . 172.3.3 Risk Management . . . . . . . . . . . . . . . . . . . . . 182.3.4 Interoperability and Service Oriented Approach . . . . . . 19

2.4 Multi-disciplinary Research Themes . . . . . . . . . . . . . . . . 22

3 The Service Vision 273.1 Fundamentals of Service-Orientation . . . . . . . . . . . . . . . . 27

3.1.1 Goals and Benefits . . . . . . . . . . . . . . . . . . . . . 303.1.2 Problems Solved . . . . . . . . . . . . . . . . . . . . . . 31

xiv CONTENTS

3.1.3 Challenges Introduced . . . . . . . . . . . . . . . . . . . 323.1.4 Effects on the Enterprise . . . . . . . . . . . . . . . . . . 33

3.2 Design Principles of Service Orientation . . . . . . . . . . . . . . 343.2.1 Service Contracts . . . . . . . . . . . . . . . . . . . . . . 343.2.2 Service Coupling . . . . . . . . . . . . . . . . . . . . . . 363.2.3 Service Abstraction . . . . . . . . . . . . . . . . . . . . . 363.2.4 Service Reusability . . . . . . . . . . . . . . . . . . . . . 373.2.5 Service Autonomy . . . . . . . . . . . . . . . . . . . . . 373.2.6 Service Stateless . . . . . . . . . . . . . . . . . . . . . . 373.2.7 Service Discoverability . . . . . . . . . . . . . . . . . . . 383.2.8 Service Composability . . . . . . . . . . . . . . . . . . . 39

3.3 Building Service Oriented Architecture . . . . . . . . . . . . . . 403.3.1 Delivery Strategies . . . . . . . . . . . . . . . . . . . . . 403.3.2 Service Oriented Analysis . . . . . . . . . . . . . . . . . 433.3.3 Service Oriented Design . . . . . . . . . . . . . . . . . . 46

II Design Guidelines for Interoperability 53

4 Interoperability in e-Government 554.1 Metadata in Cooperative Environments . . . . . . . . . . . . . . . 55

4.1.1 Semantic Interoperability . . . . . . . . . . . . . . . . . . 584.1.2 Characteristics of the Interoperability Framework . . . . . 594.1.3 Interoperability Architecture . . . . . . . . . . . . . . . . 614.1.4 Considerations . . . . . . . . . . . . . . . . . . . . . . . 63

4.2 Ontology-Driven development of Intelligent Documents . . . . . 654.2.1 Administrative and Semantic Cooperation . . . . . . . . . 664.2.2 Intelligent Document Definition . . . . . . . . . . . . . . 674.2.3 Document-specific Ontology . . . . . . . . . . . . . . . . 694.2.4 Ontology-driven Intelligent Document Compilation . . . . 704.2.5 Considerations . . . . . . . . . . . . . . . . . . . . . . . 72

5 The Marche Region delivery system 735.1 Requirements for Web Portals and Services . . . . . . . . . . . . 735.2 Service delivery in the Marche Region . . . . . . . . . . . . . . . 75

III Testing and Verification of Service Systems 79

6 Interoperability Testing of Orchestrations 816.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

CONTENTS xv

6.2 Service Composition and Trust in e-Government . . . . . . . . . 836.3 Technical Background . . . . . . . . . . . . . . . . . . . . . . . 85

6.3.1 Web Service Composition with BPEL . . . . . . . . . . . 856.3.2 Model Checking . . . . . . . . . . . . . . . . . . . . . . 886.3.3 Genetic Algorithms . . . . . . . . . . . . . . . . . . . . . 89

6.4 The Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . 906.4.1 Defining BPEL Orchestration for Testing . . . . . . . . . 916.4.2 Model Checking BPEL Specifications . . . . . . . . . . . 926.4.3 Test Data Generation Criteria . . . . . . . . . . . . . . . 926.4.4 Genetic Algorithm Test Data Generation . . . . . . . . . 936.4.5 Test Suite Generation . . . . . . . . . . . . . . . . . . . . 96

6.5 Implementation Strategy . . . . . . . . . . . . . . . . . . . . . . 966.5.1 Orchestration Invocations Annotation . . . . . . . . . . . 966.5.2 From BPEL to Java . . . . . . . . . . . . . . . . . . . . . 976.5.3 Input Data Generation . . . . . . . . . . . . . . . . . . . 976.5.4 Counterexample Identification . . . . . . . . . . . . . . . 996.5.5 Trace Evaluation . . . . . . . . . . . . . . . . . . . . . . 996.5.6 From Traces to Test Cases Definition . . . . . . . . . . . 1006.5.7 Participant Test Suite Definition . . . . . . . . . . . . . . 100

6.6 Model implementation in JPF . . . . . . . . . . . . . . . . . . . . 1016.7 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

6.7.1 A Toy Example of Data Generation . . . . . . . . . . . . 1026.7.2 Exemplifying scenario . . . . . . . . . . . . . . . . . . . 104

6.8 Related Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1086.9 Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

7 Verification of Choreographies 1117.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1117.2 Web Service Choreography Description Language Overview . . . 1127.3 PROMELA and SPIN . . . . . . . . . . . . . . . . . . . . . . . . 1147.4 Related Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1157.5 A Simple Use Case . . . . . . . . . . . . . . . . . . . . . . . . . 1167.6 WS-CDL to PROMELA Translation . . . . . . . . . . . . . . . . 1177.7 Checking the model using SPIN . . . . . . . . . . . . . . . . . . 1217.8 Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

IV Conclusions 129

8 Conclusions 131

xvi CONTENTS

Bibliography 135

List of Figures

3.1 Design principles: specific characteristics and regulatory . . . . . 363.2 Original architectural representation of SOA . . . . . . . . . . . . 393.3 SOA development life cycle . . . . . . . . . . . . . . . . . . . . 403.4 Top-down delivery strategy . . . . . . . . . . . . . . . . . . . . . 413.5 Bottom-up delivery strategy . . . . . . . . . . . . . . . . . . . . 413.6 Agile delivery strategy . . . . . . . . . . . . . . . . . . . . . . . 423.7 Steps of service-oriented analysis and modeling . . . . . . . . . . 443.8 Steps of service-oriented design . . . . . . . . . . . . . . . . . . 463.9 Relations among WS-related technologies . . . . . . . . . . . . . 483.10 Overall delivery strategy for an SOA . . . . . . . . . . . . . . . . 51

4.1 Metadata stack . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.2 Hierarchy of integration levels . . . . . . . . . . . . . . . . . . . 594.3 Interoperability architecture . . . . . . . . . . . . . . . . . . . . . 624.4 Ontology propagation and element discovery . . . . . . . . . . . 644.5 Intelligent document ontology . . . . . . . . . . . . . . . . . . . 684.6 Document-specific ontology and document ontology . . . . . . . 704.7 Architecture for intelligent document delivery . . . . . . . . . . . 71

5.1 TECUT Home page . . . . . . . . . . . . . . . . . . . . . . . . . 76

6.1 System traces derived with the approach . . . . . . . . . . . . . . 976.2 From traces to test cases . . . . . . . . . . . . . . . . . . . . . . 986.3 Tool for the generation of the Java model for JPF . . . . . . . . . 1016.4 Sample BPEL Process . . . . . . . . . . . . . . . . . . . . . . . 105

7.1 Sequence diagram of the choreography example . . . . . . . . . . 1177.2 WS-CDL to PROMELA processes translation . . . . . . . . . . . 1187.3 WS-CDL to PROMELA variables translation . . . . . . . . . . . 118

xviii LIST OF FIGURES

7.4 WS-CDL to PROMELA activities translation . . . . . . . . . . . 1207.5 WS-CDL to PROMELA choice translation . . . . . . . . . . . . . 1207.6 WS-CDL to PROMELA parallel translation . . . . . . . . . . . . 1217.7 Parallel interactions in WS-CDL . . . . . . . . . . . . . . . . . . 1227.8 Constants and channels declared in the PROMELA model . . . . 1247.9 Shipper definition in the PROMELA model . . . . . . . . . . . . 1257.10 Buyer definition in the PROMELA model . . . . . . . . . . . . . 1257.11 Seller definition in the PROMELA model . . . . . . . . . . . . . 1267.12 CreditChecker and init definitions in the PROMELA model . . . . 1277.13 Output of the SPIN verification procedure . . . . . . . . . . . . . 1287.14 Message Sequence Chart of the simulation . . . . . . . . . . . . . 128

Chapter 1Introduction

This thesis focuses on service delivery and interoperability in e-Government. Inthis domain [54] [19], for Public Administrations (PAs) is very important to havereliable service-oriented systems centered on information with an high level oftrust and security to delivery high-value services to citizens, firms and other PAs.This thesis would to contribute to the design of such systems.

Today innovation in the government sector is a mandatory element for a clearachievement of the information society. Historically, innovation revolutions aresurrounded by a combination of technologies that create a fertile ground able toguide them. These enabling technologies are the result of scientific research andhave impact in technical development with the advent of new design and engineer-ing processes; in business with the development of new business models, productsand services; and - when technology reaches the mass - in social issues.

Understanding this rule, e-Government revolution follows the trend of currentinnovation [116] [55] exploiting the web potential and the “software as a service”paradigm to transform the governance of the public sector. Moreover, innova-tion can result in significant cost saving to government. This potential saving ishuge, but is dependent on a wide adoption of the new technologies. This is pos-sible making e-Government mandatory or creating incentives to move to onlineservices, but all this require a change on culture form the adopters.

In this sense, e-Government systems are “socio-technical” systems and bothsocial and technical issues should be considered dealing with them. While thislatter is more engineering inspired and tends to emphasize formal aspects, the firstis driven by social sciences and aims to point up to informal and human aspects ofthe organization that exists around the system. People in e-Government systemstries to create new situations in the public sector exploiting the capabilities oftechnologies.

To allow this vision, the Public Administration has the duty to provide both the

2 CHAPTER 1. INTRODUCTION

citizens and the firms all the services they need. The traditional services, usuallysupplied with the “front office” service, will soon be supported by totally newservices thanks to the Information and Communication Technologies. In this waythe public service and the democratic processes improve their quality and it ispossible to give more strength to the public policies [26].

From a technological point of view, the best model for e-Government serviceprovisioning is based on the abstraction of service orientation as a backend formanagement systems that supply the effective government service to the user.With the term “service” I refer in this thesis both to e-Government services as ahigh level applications directed to the final users and to services used in a ServiceOriented Architecture (SOA) [40] [39] in a wide - implementation agnostic - way.Nevertheless, in technological discussions I refer to its most used implementationthat is represented by the web service technology. In this vision web servicesare software components that can be used through the net and composed to allowdifferent applications to exchange data and participate in business processes. Inthis approach e-Government services are delivered using service-oriented systemsthat use services - web services - as backend for web portals that represent thefrontend for the users.

To be connected with SOA logic means to have the ability of keeping the In-formation Technology (IT) roles always conformed to the strategic requirementsof the PAs: having to face a new process or a change of a process, it will beenough to reorganize the interactions and the processes linked with the differentservices. The services will be composed in order to implement the PA businesslogic thanks to the reuse of already developed web services increasing efficiencyin terms of costs and productivity. Separation of concerns is the main feature ofthe service-orientation paradigm and a solution logic that can be state as service-oriented refers to principles as: standardized contracts, loose coupling, abstrac-tion, reusability, autonomy, statelessness, discoverability and composability. Allthese principles refer to the fundamental principle of interoperability that is inher-ent to the intrinsic nature of the service-orientation itself.

Service composition is needed to accomplish complex tasks and the compos-ite service needs the right interactions with its component services. Once made,a composite service works in the same way as a non composite service, but theuser is able to perceive a more complex administrative tasks inside the PAs do-main. As a drawback, this approach fails when a composite service cannot beaccomplished because a component service cannot work (because of temporarilytechnical problems, because of an overloaded server, . . . ). In this case the wholeprocess execution fails.

Service provisioning in e-Government involve complex management activi-ties that should be performed by a system engineered to allow the right levels ofsecurity, trust and, for what concern the front office, user friendliness and usabil-

CHAPTER 1. INTRODUCTION 3

ity. In this scenario, interoperability have an important role to involve togetherPAs with heterogeneous technical infrastructures. Interoperability at its base levelmeans using loosely coupled approaches to share or broker software resourceswhile preserving the integrity and the native state of each entity and data set. [94]

Interoperability refers to information adding semantics to data to allow a cor-rect integration on software components, processes and data. This address syntac-tic, structural and semantic issues in metadata that is a crucial enabling technol-ogy. Moreover, services may be the perfect candidates to enable interoperabilitysince this capability is one of their key requirement. The technology used todayto implement them heavily rely on metadata with a plethora of standard using forexchange information. These technologies are the backend for service deliveryand provide a means to build such system in a loosely coupled fashion, that isimportant to manage the change in the e-Government domain.

Service management systems are the enabling factors for an information soci-ety built starting from e-Government adoption. These system needs to be reliableto speed up the public sector and to make easy their adoption by the users. Inengineering such systems in this dissertation a particular focus has done to testingand analysis [93] on their service-oriented backend.

Software testing is the process of executing a program or system with theintent of finding errors. It involves many activities related to the production oftest cases to define the right inputs, the set of steps to execute, their executionconditions, and the expected results that are used to evaluate the system undertest. These activities are a trade-off between budget, time and quality, and are animportant choice for the public sector. Moreover, the design of test cases by handis a tedious, time-consuming and error-prone task. To overcome these drawbacksautomated testing frameworks are developed to produce, organize, and executetests on software.

Furthermore, verification is the process of evaluating a system or componentto determine whether the products satisfy the conditions imposed. To do this, for-mal verification is used to prove the correctness of a software system respect toformal specification or property using formal methods. A proper development ofsystems addressed to a wide adoption cannot leave aside from testing and verifi-cation activities to assess their reliability.

I claim that e-Government revolution has an high potential social impact on thedaily life of people. This is achievable with the introduction of new technologies,new knowledge, and new systems engineered and proposed to the users in the rightway. This thesis summarize my experience in the engineering of e-Governmentsystems during the three years of PhD. Most of the contents are published ininternational and national conferences on e-Government and related field to assurean effective dissemination. The thesis is divided into three parts.

The Part I supplies, in the Chapter 2, an overview of the e-Government sys-

4 CHAPTER 1. INTRODUCTION

tems and their implementation providing an agenda of the ongoing multidisci-plinary research on the field. The Chapter 3 completes the background showingsome fundamentals concepts of service orientation from a technical viewpoint andhighlighting common principles to design and build a service-oriented architec-ture.

Part II provides general guidelines for the implementation of the e-Governmentsystems for the delivery of services. I discuss in Chapter 4 the importance ofmetadata as a fundamental element for the achievement of a full interoperabilityamong heterogeneous PAs. Indeed, metadata utilization allow and effective rep-resentation of the domain reality carrying information between cooperating PAsthat work together.

Interoperability and applicative cooperation are key concepts when informa-tion systems compete towards a proper collaborative Public Administration. Ibelieve that a suitable solution to these concepts cannot leave aside by a formalconceptualization of the application domain of interest. To exploit the full poten-tial of metadata I concentrate on the concept of Intelligent Document and proposea model-driven document management for Public Administrations that is basedon ontologies to describe both the structure of the documents, type of data, infor-mation and process needed for their filling. The proposed infrastructure supportsthe entire document life-cycle.

Chapter 5 presents the e-Government service delivery in the “Marche Region”that include a service-oriented backend that integrates into a web portal for theprovisioning of services to Italian citizens and firms. In particular, “Marche Re-gion” provides an interesting benchmark in e-Government solution development.Several Italian Regions develop e-Government solutions with the aim to increaseinteractions between Public Administrations (PAs) and users through the use ofinfrastructures build for the citizens. In order to reach a flexible system I takeinto consideration basic functionalities to solve key questions in e-Governmentdomain. Aspects as authentication and authorization, service publishing and dis-covery as well as composition are fundamental to build efficient and effectivearchitectures. The system presented in the case study as the potential to achieveoperational integration into one-stop e-Government and tries to satisfy all the re-quirements to build e-Government around citizens needs.

Part III has the aim to develop new methodologies for testing and verifica-tion of Service-Oriented Architecture that are the basis for the service systemspresented previously.

The service paradigm promises to open and integrate Public Administrationoffices to provide high-value services to citizens. Nevertheless to foster real us-age of e-Government services by citizens, in majority still not fully acquaintedwith Internet technologies, it is necessary to put in place mechanisms to reduce asmuch as possible perceived system misbehavior. Services often handle personal

CHAPTER 1. INTRODUCTION 5

and sensible data, therefore trust on the behavior of the system becomes of pri-mary importance. Chapter 6 focuses on composition and provide an approach thatreduces the possibility that the system will fail as consequence of interoperabilityissues among discovered services, and after that sensible data have been providedby the citizen. This approach uses run-time testing to assess interoperability be-tween services, and model checking based techniques to reduce the number oftest-cases to be applied.

Chapter 7 reports an approach to formal verification of web service compo-sition expressed using the WS-CDL language by means of model checking. Ac-tually, WS-CDL is an emergent proposal for the description of web service com-positions that use a neutral viewpoint focused on the description of message ex-changed in a collection of services. I analyze the WS-CDL language source andisolate the necessary information to build a PROMELA model suitable for the ver-ification using the SPIN model checker. I show the translation and an examplesof verification using a simple use case that involve four participants. The aim isto show how a choreography of web services can be verified using existing tech-niques that can be extended or adapted to deal with new problems arising in theweb service world.

Finally, Chapter 8 contains some general conclusions about the guidelines andthe approaches presented in the thesis.

Part I

Background

Chapter 2e-Government Systems

The aim of this chapter is to show the e-Government domain particularly for whatconcern e-Government information systems and their development. Main of thischapter is influenced by the reading of [54] and [19].

2.1 Definitions and Scope

In the last years the use of Information and Communication Technology in thepublic sector has grown.

This has an high impact on the work of the Public Administrations, and wecan refer to this kind of ICT-related initiative as e-Government referring with thisterm to all the uses of ICT (that is not confined only to web applications, butrelated with many informative technology) in the public sector. In this sense,e-Government systems are information systems. They must be able to handledata and perform processes to support decision-making inside the public sector.Likewise, they must deliver services to end-users that can be citizens, firms, orother Public Administrations.

Nowadays there are several e-Government definitions in literature. In Europe,it is usual to refer to the “use of information and communication technologies inPublic Administrations combined with organizational change and new skills inorder to improve public services and democratic processes and strengthen supportto public policies” [26]. Moreover, e-Government is a large opportunity to [13][35]: (i) transform organizations of public sector reaching innovative and user-centered PAs; (ii) provide high quality services with low cost promoting economicdevelopment; (iii) improve governance allowing an effective access to informationthrough flexible and transparent institutions.

These objectives can be reached with successful e-Government initiatives that

10 CHAPTER 2. E-GOVERNMENT SYSTEMS

rely on the presence of working information systems. These one must considerseveral dimensions and not only the technical one. Information are the centralissue in an e-Government system, but people that give to the system the meaningand the purpose performs an important role in a successful e-Government project.

Indeed, e-Government plays a base role for a better delivery of governmentservices to citizens, business and organizations, and for a more efficient govern-ment management [101] [99]. For this administrations promote services to auto-mate their activities and to improve their cooperation.

In this sense, e-Government are “socio-technical” systems [5] and both socialand technical issues must be considered dealing with them [12]. Several factorscan be identified to describe a system of this type. Among of them several areidentified as central in an e-Government system:

• Information: the information used inside the system and by the people in-volved with the system;

• Technology: focus on web based information systems but also involve otherinformation-handling technologies;

• Processes: all the activities carried out to perform e-Government operation;

• Objectives and values: objectives of the system relies on organizationalstrategies while the value comprises what end-users think about the system;

• Staffing and skills: covers the staff involved in the realization of the system;

• Management systems and structures: covers the management required toorganize and use the e-Government system;

• Other resources: all the other stuff that are inherent the system life-cycle.Principally, time and money required to build, deploy and make operativethe system itself.

This list of dimensions to analyse e-Government systems is referred as “IT-POSMO checklist” and can be extended to an eighth dimension considering theoutside world of the system to include political, economical, socio-cultural andlegal factors that can affect the system.

Given this, it is clear that an approach to manage e-Government system shouldencompass both social and technical aspects. While this latter is more engineering-inspired and tends to emphasize formal aspects, the first is driven by social sci-ences and aims to point up to informal and human aspects of the organization thatexists around the system.

Moreover, we must argue that e-Government is not e-Business. Forcing gov-ernment managers into private sector thinking usually causes more problems than

CHAPTER 2. E-GOVERNMENT SYSTEMS 11

it solves. It is not a good idea to transfer concepts form private sector into thepublic one. The sectors differ starting from they objectives. e-Government con-cerns citizen satisfaction using services and the view of service customers is moreholistic. On the other side, private sector suffers only a little of politicization whilee-Government (for its nature) is more government centric.

Due to this, e-Government appear to be a difficult domain in which the successor the failure of initiatives and projects is related to managerial considerations, po-litical decision and to technological skills [102]. Moreover, information systemscontain data, technology, people and processes. All off them must be consideredand managed for a successful e-Government initiative.

e-Government is a way for governments to use innovative technologies to pro-vide citizens and businesses with more convenient access to government informa-tion and services, to improve the quality of the services and to provide opportu-nities to participate in democratic institutions and processes [42]. From GartnerGroup [47] white-papers, e-Government is the continuous optimization of servicesdelivery, constituency participation and governance by transforming internal andexternal relationships through technology, the Internet, and new media.

This include several typology of relationships that e-Government aims to makemore friendly, convenient, transparent and inexpensive:

• G2C: Government to Citizens (and its “reverse” C2G)

• G2B: Government to Business enterprises (and its “reverse” B2G)

• G2G: Government to Government

The aims is to enhance information sharing, service delivery, user participationand governance by transforming internal and external relationships.

G2C aims to put public services on-line for citizens and to share informationwith them. Services are related to taxes, administrative procedures, and so on.Service interaction with citizens can be categorized on four level: at first, ser-vices provide one-way communication for displaying information about a givenagency or aspect of government. At the second level services provide simple two-way communication capabilities while at the third level services facilitate com-plex transactions that may involve intergovernmental workflows. The fourth levelservices seek to integrate a wide range of services across a whole governmentadministration, as characterized by the many emerging government portals [37].

G2B is addressed to the development of electronic marketplaces for govern-ment purchases; platforms to exchange information and commodities, etc. Infor-mation and services are related to citizens (taxes, business licences, administrativeresponsibilities, . . . )


G2G provides agencies cooperation and communication to have an impact onefficiency and effectiveness. The focus is on exchange of information among dif-ferent authorities and agencies, regards administrative procedures and backgroundinformation to decisions, inter-organizational workflow and knowledge manage-ment [60].

This classification can be improved considering G2E namely, Government toEmployee. G2E has the aim to manage internal communication between em-ployees and to manage the civil service to make applications and processing sys-tems paperless. Inter-personal workflow, exchange of data about work, knowledgemanagement are usual topics of G2G initiatives.

2.2 Managing e-Government

2.2.1 Management of Systems

Focusing on an organizations it is possible to identify three different approachesto responsibilities: (i) centralized, (ii) decentralized, and (iii) hybrid.

Centralized systems imply decision-making from a central level of the orga-nization and technologies are build around to reflect this policy. A centralizedcomputing architecture will involve a large central computer with some dumbnetwork terminals. This kind of architecture can be realized by a team from theIT staff of the Public Administration or can be realized by an external contractor.An approach with an high centralization of administrative and technical control isattractive because supply a method to reduce costs. Indeed, it avoids duplicationof software and data and there is not wasted effort nor inconsistency of data. Con-sequently, having a well-planned system means that data can be accessed usingonly one place and a single database become the single authoritative source forthe digital information inside the Public Administration. About this, it is impor-tant to note that data privacy and security can benefit of a centralized approachthat promise much control on all outcomes of the system. On the other side, suchsystems are subjected to many challenges and barriers tied to the intangibility ofinformation and to the political constraint existing inside the organization.

Decentralized systems in terms of technology are represented by an archi-tecture that involves standalone computers working with a “peer-to-peer” infras-tructure. This solution is associated with the availability of an high number ofcomputer inside the organization. This means multiple data sources, multiple websites available for service delivery and so on.

A fully decentralized approach is guided by single local Public Administra-tions and some e-Government initiative usually take place to meet the target of aparticular end-user group focusing to their needs. Moreover, technology who is


the base of decentralization is cheaper and reliable then decentralization seems areal possibility. To the other side, some disadvantages arise in this approach. Sys-tem can suffer of interoperability problems when we must cooperate to a commonobjective due to the incompatibility of processes and data. Data can be are storedseveral times (for education, for health, for welfare, etc) and consistency problemmay appear when data should be putted together to produce a reliable record ofinformation.

Despite some differences, both approaches improve benefits for public orga-nizations. Hybrid approaches attempts to reconcile the two point of view. Twoactivities must be undertaken for this: integration of systems (allowing the coex-istence of the two approaches in an unique system) and division of competences(that try to find some demarcation lines between the two). These two activity havethe aim to take the best from the combination of the centralized and decentral-ized approach. If well-handled hybrid approach can be more flexible and providereal benefit in Public Administration for their work. A decentralized approach ismore economic while a centralized approach is more efficient. A right balancebetween the two is the recipe for a well-organized and efficient Public Adminis-tration. Moreover, hybrid is most effective because it provide at the same timethe necessary control to share resources avoiding duplications and the necessarydegrees of freedom to satisfy users needs.

2.2.2 Management of Public Datae-Government system works heavy with data. Data are fundamental for the func-tioning of the Public Administration because on data depends many of the admin-istrative procedures that are performed, and because a lot of decisions depend onthem.

Data in information systems suffer of a quality problem: it can be incompleteor can contain errors, and can have updating mismatches. For this, e-Governmentmust adopt some management technique to improve data quality. These containstechnical guidelines about technology for data input and data gathering, as wellpeople-oriented hints to improve data quality.

Five indicators can be used to state data quality:

• Completeness: the degree to which all the data is present in the system;

• Accuracy: the level of incorrect data in the system;

• Relevance: the importance of the data in order to complete a particular task;

• Timeliness: the level to which data can be delivered with a specific time-frame;


• Appropriateness of presentation: the level of accessibility and intelligibilityof the data.

More the data reflect these indicators (usually called “CARTA indicators”)more the data are of high quality. Data errors can make worse quality at any stagein the information cycle. Gathering of data, processing, storage, and output ofthem are all crucial steps for data management inside an e-Government system.

Moreover, a low quality can be introduced by garbage data in input that lead tobad data in the output of the information cycle. The output data are strong relatedto the input data because e-Government applications are information intensive andrely on data to perform their functions.

Causes of bad data can be of technical (hard) nature or human (soft) nature.The hard causes can be due to:

• environmental hazards that can corrupt data as well IT infrastructure like:humidity, static electricity, dust, fire, etc.

• electrical problems like power spikes and brownouts that can cause damage,or power cuts that can cause loss of data memory and outs of service;

• equipment breakdown that can affect a right working of the system is theyare not abounding;

Soft errors are caused by the presence of software errors that affect the systemin a broad sense because are programming errors in the code that constitute thesystem. This kind of problem can be seen as a human problem because rely on thedevelopment of the system made by an IT staff. Another soft problem that is rele-vant for the public sector, specially for data management, is computer crime. Thisterm includes alteration or destruction of existing data and unauthorized accessesto them.

Due to these considerations, both technical and human perspective must behandled to form again a hybrid approach to data management. Some generalcontrol mechanisms must be put on the field. Primarily an appropriate accesscontrol is needed to monitor users access to e-Government systems, then, controlson communications like firewalls and encryption should assure a right securityand privacy.

Applicative controls must be used to drive the gathering of data. The mostcommon and important thing is to control input fields in the system interface usedfor data entry. If the control is violated it is easy for the system to prompt acustomized message that shows the proper way to input data.

From another point of view, people can take different roles in relation to thee-Government system. A human can be the data source, the data capturer, the data


inputter, or all these roles at the same time. This is the human part of the inputdata to the system. Again, in the system maybe a data processor who manage thedata, and finally a data user. This is the most important figure because gives themeaning and the purpose to the data.

Data must be used to be useful to users. All human-related defects are given bya human perception of data irrelevance or non-use. If the human data inputter giveno importance to the data because think that them will not be used, data qualitywill tend to be poor. Many people are involved in the data cycle from source touse, if only a link in the chain is demotivated or motivated by factors different theinterest of the Public Organization (public employees are a significant source ofcomputer crimes) problems may arise.

Human component of an e-Government system can be well-prepared to useit. Then e-Government initiatives must consider the supply of some training tothe people involved to avoid human errors. This may be for guarantee a certainsystem accountability with a clear management of responsibility and separation ofduties. This latter is to avoid some deliberate data manipulation from employees.

Finally, an appropriate data management should embrace a data audit task tohandle potentially enormous databases (for instance containing millions of recordand historic data about people).

2.3 Implementing e-Government

2.3.1 Systems Life-cycle

e-Government system projects tries to create new situations in the public sectorexploiting the capabilities of IT technologies. An high degree of change is re-quired as much as the new situation is different from the current one.

Usually a four-stage life cycle characterizes an e-Government software project:

• assessment work: constitutes the evaluation phase to identify the feasibilityof a project idea. In this phase will be evaluated if proceed with the projector not;

• analysis: analyze the current situation to determine if a new e-Governmentsystem is needed. Several dimensions can be evaluated and the ITPOSMOmodel discussed before should be used;

• design: plan of the new system. Here will be set the objectives for thenew system and an hypothesis of the ITPOSMO evaluators should be madeconsidering the scenario after the realization of the project;


• implementation: build of the new system. This phase comprise the acqui-sition of the technology necessary for the system and its development anddocumentation.

• deploy: introduction the new system in the Public Administration scenarioand training for users and adopters.

This approach consist in the detection of the current situation realities, the designof a suitable proposal to reach a new opportune situation and then the assess ofthe differences between the two.

A new e-Government projects starts in one of two ways: or there is a prob-lem that needs to be solved or an opportunity which could be seized. Problemsand opportunities arise from many possible sources. Some example comprise:technological innovation, political needs, citizen demands, etc. from the outsidethe organization. While financial resources, responses to strategic plans or con-sultancy reports, individual desire of career, etc can arise from the inside of thePublic Administration.

Four factors need to be assessed to evaluate a project idea.

• Feasibility to establish if a project can be implemented or not;

• Priority to identify a project inside a set of competing one;

• Opportunity to make clear the motivation to invest resources, or if there is away to invest better;

• Impact to show what will be the effect if the project takes place.

Particular importance to assess the new potential project must be given to thegathering of information about the people involved on it. Stakeholders shouldbe identified as a group of people who potential can have financial involvement.First of all the project team and the suppliers of the technology are primarily in-volved in the development of the system and are clearly recognized as stakeholder.Moreover, clients (citizens, businesses or other administrations) are interested onthe system outcomes and are the direct users of the system. The project usuallyhave people that drive the decisions and justify its implementation while sponsorscontribute to expenses and efforts required for its development. The Public Ad-ministration that drives the project is usually the owner and the responsible aboutit having a great influence on project decisions. In substance two categories (thatmaybe overlap) can be identified: those involved with the development and thoseinvolved with the operation of the system.


2.3.2 Design of e-Government Systems

e-Government systems are designed from a technological perspective focusing ondata they handles and the processes they accomplish. This approach often end ina failure because human factor is underestimate and political factors may have acritical impact on the projects.

A successful approach must encompasses technical and human related ele-ments remarking the ITPOSMO dimension showed previously. Five design issuescan be considered: (i) objectives, (ii) information, (iii) technology, (iv) processes,and (v) humans.

A project statement may provide an initial guideline framework but it is clearthat a complex project will require a set of objective to work to. Often objec-tives are stated as a mirror image of identified problems and despite this can seemunsophisticated it is a clear base to start an analysis for the expected system de-velopment. Approaches that can be stated as rational recommend that objectivesshould be SMART, namely: Specific, Measurable, Agreed, Realistic and Time-Bound [97]. In some public organizational cultures, instead, managers may try tokeep objectives vague to reduce possibles failure consequences because a vagueobjective has more chance to be met.

Information is assumed to meets the needs of the system. This means howeverthat information required by the new system should be accurately planned usingsome analysis of requirements that include (i) output requirements (the informa-tion required to be the output of the system), (ii) input requirements (necessaryto produce the output) and (iii) process requirements used to classify, rearrange,select, aggregate, and in general convert them.

Technology must be chosen carefully. Several alternatives that meet the re-quired objectives should be considered. Software is typically the first focus be-cause it does the work inside the system. Three design choices can be made. Thefirst concerns the type of application the project would delivery: (i) a softwarewith a sophisticated data handling (like an ERP system), (ii) a software orientedto decision making for administration, or (iii) a software able to support interac-tions with the external world (like a web portal).

In every instance Public Administrations must decide the way to obtain thesoftware. A first choice is to purchase the software, this is a lower cost and easyimplementation of the project but the software may not fit all the project needsalso if customization is possible. The other way is to re-engineering some ofexistent. This implies the rewriting of existing software application, and this isa task that depends on the documentation and the structure of the product. Thedefinitive choice is to realize a custom application developed from scratch (thatmaybe cheaper than re-engineering). If well-done this choice can provide thebest fit to project needs, however this is exposed to design, implementation and


maintenance problems. Moreover, hardware should be chosen in the right way tofulfil every software needs.

The design of processes must handled carefully, a radical redesign of pro-cesses promoted by business process re-engineering can have an high impact andis an high risk task for Public Administration [16]. Re-engineering should be in-troduced gradually to optimize or improve existing public processes rather thenreshape all of them from scratch [98] [106].

Moreover, people are involved in the change and a new way to organize workis needed in every e-Government initiative from Public Administration employ-ees. They should meet stated objective starting to revisiting what should be doneand how this should be done in the new information system.

Such kind of dynamism relies also on the culture of adopter of the new system.A Public Administration that have a staff that is lazy, that lack of ambition and thatdislike responsibility will work hard to reach the objective of the adoption of thesystem. On the other side, there are agencies with consider work as a naturalactivity performed by motivated people who accept delegation of responsibilityand are incline to change.

2.3.3 Risk Management

Although there are several management techniques to build a sound e-Governmentinformation system, many projects fail in some way. Therefore some kind of riskassessment and mitigation should be performed in the project life-cycle.

The aim of risk management is to avoid project failure and it is performedduring a general project assessment and in more details during the analysis phase[34]. Risk mitigation activities could take place at any stage in the life-cycle.Clearly, the earlier the risk is assessed, the harder it to know the risk accurately,but the later the risk is assessed the harder is to perform mitigation activities. Abest way to assess risk is to organize a team of stakeholders that is able to discoverrisks associated with the project life-cycle.

Gaps can be viewed as risks to the implementation of a project and a firsttechnique to risk assessment is gap analysis. These has the aim to evaluate thegap between current reality and the design assumptions and requirements of aproposed new e-Government system. An approach should be to analyze the IT-POSMO dimensions to view the organization reality around them and about thee-Government applications. For each dimension a numeric rating could be as-signed to estimate the size of the gap in order to prioritize mitigation actions.Using this approach can be evaluated: the technology, the information used in thesystem respect to the information used without it, the work processes in the PublicAdministration agencies, etc.


Mitigation activities will focus on altering the project to overcome risks. Largegaps can be prevented and a gap can be reduced once it has been identified. In thiscase a change in the design of the system can bring it near the reality it representsreducing the gap. These risk mitigation alterations can be undertaken in variousways as a part of the change management process.

Moreover, another issues to keep into consideration is the cost associated withthe project. Usually, cost were underestimate in software projects. Cost estimationfocus on the initial investment costs rather than the operational costs, and manycosts are hidden when the project starts.

A Cost/Benefit Analysis is a technique used to assess costs and benefits ina project. It consider benefits expected from the project under a financial pointof view. This is a non trivial task considering the intangibility of benefits: any-where/anytime delivery of services, faster decision making from Public Adminis-tration, new way of organize work, etc. A financial value of these outcomes is notsimple and there is not a standard way to do this because e-Government systemdevelopment is an uncertain process that frequently ends with a project failure, acost overruns, or in a unexpected changes of direction due to political decisions.

2.3.4 Interoperability and Service Oriented ApproachInteroperability [94] has been identified as a major issue to face by all PublicAdministrations [67]. If an high interoperability level is reached different admin-istrations can cooperate and develop federate communities. In this way reuse ofservices is facilitated. Interoperability is not only a technical issues but a comprisesemantic and organizational skills.

The best model to achieve interoperability relies upon the abstraction of theidea of service in a Service-Oriented Architecture (SOA) [39]. To be connectedwith SOA logic means to have the ability of keeping the Information Technology(IT) roles always conformed to the strategic requirements of the PA [78]: havingto face a new process or a change of process, it will be enough to reorganize theinteractions and the workflows linked with the different services for the users. Theservices will be composed in order to implement the PA business logic thanks tothe reuse of already developed service. As the user can see, this means to increasein efficiency in terms of costs and productivity.

To accomplish a task, a composite service needs that component services willbe rightly orchestrated [90] in a process. The term “orchestration” refers to thecontrol of a process execution that can interact with other services [14] and the or-chestration determines the interactions between services on the level of messages,process logic and order of interactions. These interactions can involve many ap-plications and/or Public Administrations through a transactional process. From atechnical perspective of SOA, this can be accomplished thanks to the Web Service


technology providing a model for the interaction among agencies with messagesexchange among the various partners [82].

Once made, a composite service works in the same way as a non compositeservice and the user is able to perceive a more elaborate government service whichis able to accomplish complex administrative tasks. The problem rises whena composite service cannot be accomplished because a component service can-not work (because of temporarily technical problems, because of an overloadedserver, . . . ). In this case it is necessary to interrupt the whole transaction.

Thanks to SOA adoption in the public sector, it is possible to run the backoffice in the central administrations that have usually less close connections withthe citizen asking for the service, while they have a basic importance in runningthe whole system. This helps the public sector keeping and strengthening thegovernance in the Information Society. This means:

1. An open, simple, comprehensive public sector also able to understand thecitizens, and open to the democratic development of society;

2. An on duty public service for everybody. It should focus on the user withoutcutting out anybody, providing personal services treating everybody withcare;

3. A productive public domain. This means wasting less time at the front office,it means lessen the mistakes, it gives more time for the “usual” services thanthe inner back-office.

Both for the citizens and the firms, it is important to have those services andinformation fitting their needs, however the customized services need integration,sharing processes and knowledge among the agencies and the different institu-tions. This can be achieved interconnecting the different Public Administrationsystems so that they can share the information simplifying the interoperability tocarry out the administrative procedures. The aim is giving the citizen the highestefficiency in picking out the services and giving the users a single point of accessfor them.

The accomplishment of composite services in this scenario has a basic impor-tance because it allows the PAs to provide “value-added” services. The compositeservices are elaborated on the basis of other composite or non composite services,through the orchestration. The reuse is one of the key benefits because it allowsthe providing agency to have new services without having to elaborate new com-plex services. Working on existing services means implementing a new businesslogic that can be useful to the user providing formerly non available importantservices. The benefit of this performance is available in terms of costs and elabo-ration time. In this way services are included in a complex activity which is able


to implement more general services crossing more agencies that cooperate for thedevelopment of the administration process. Both the time and the costs of the op-eration are lower because they do not involve development from scratch, but justthe composition of legacy functionalities.

Moreover, organizations in the public sector needs flexible service supplyingto suit the laws and the rules changes. Complex service reorganization, that reallyare made up of composite services, is a simpler task when the changes are onlyin the composition leaving the same services as they exactly were. In this do-main, the composition helps giving flexibility to the various services without timelimits, so that each application can evolve and be suitable each time the PublicAdministrations will change its rules.

The composition allows an easier and scalable realization of the new servicesaccording to the citizens’ and users’ necessities. The composite services involvedifferent resources of the PA, but instead of specific solutions to fulfill an “atomic”service, a composition approach seems to be more effective. In this way, the usercan attain a greater amount of services, just apparently traditional, and he/she canreach them in a very simple way straight from the web, even when really theycome from specific tasks involving the cooperation between two or more subjectsof the Public Administration.

With applications based on the idea of service, the connection and the in-formation exchange among people comes from suitable services that accomplishthe necessary operations. Moreover, the composition must be verifiable, that isto say that the agencies involved should have the chance of making use of thecomposition specification in order to verify that each step making up a process isperformed in the right manner.

Making a composite service means first of all determining the tasks one is aim-ing at. Then it is necessary to pick out the operations and the partners appropriateto perform it. There are four steps for this activity:

• Design: in this stage the whole system is planned on the basis of the aimsof the composition, of constrains to respect and of quality criterion. Inthis stage will be detected the activities to perform, planned the messagesexchange and managed the exceptions;

• Discovery: identify the useful services. Once picked out the partners takingpart to the process it is possible to define the correlations among the differentmessages;

• Composition: implementation of a business process according to the out-comes got from the design phase and from the partner services. The datainterchange is going to be modeled.


• Execution: run-time phase of the whole process execution.

In order to improve the effectiveness of the services is possible to better outlinethe composite service interfaces, and to deploy a system able to simplify the pro-cess of the service discovery. The main advantages are summed up as follows:(i) granting a better fault tolerance, when a service is not available it is possibleto find its substitute; (ii) allowing the flexibility of the service to the elaborationcontext, e.g. as to the services for mobile users it is possible to select the near-est instance; (iii) having the chance of selecting among many service providersthe one that provides the best service (using a series of criteria); (iv) allowing tospecify composite services in an abstract way as regards the available instances.

2.4 Multi-disciplinary Research Themese-Government research has been in progress starting from a decade ago [55] [117]with the initial aim to focus on the implementation and delivery of on-line servicesto citizens and to promote their involvement in the decision making processes ofgovernment.

Research requires competencies of different disciplines and a cross-disciplinaryway of thinking to bring effective innovation in a field composed by socio-technicalsystems. The field combine applied multi-disciplinary research [115] [114] thatembrace concepts from: (i) social and human sciences, (ii) political, strategic,democracy and legal sciences, (iii) organizational and economic sciences, (iv) in-formation and knowledge research sciences, and (v) computer science. Aboutthese general topic an extensive research agenda is made as outcome of the EU-founded project eGovRTD2020 [95]. A large number of research themes havebeen identified and reported in several papers delivered during the project [116][31] and in its final outcome “Roadmapping eGovernment Research, Visions andMeasures towards Innovative Governments in 2020” [25] by Codagnone and Wim-mer:

Trust in e-Government Trust is a fundamental element in all aspects of gov-ernments, including e-Government. The processes by which trust is built,destroyed, used, or abused are poorly understood and differ from one cul-ture to another. Research is needed to understand what conditions are nec-essary and what mechanisms are needed to build and maintain trust in e-Government processes and services. In this respect there is also a need toidentify the different kinds of trust related to e-Government, e.g. trust ingovernment or trust in ICT, and its special characteristics.

Semantic and cultural interoperability of public services Globalisation and pop-ulation movements are making societies increasingly multicultural. In prin-


ciple, increased Internet access and the potential of the web for communi-cation and education should bridge cultural boundaries. Yet, cultural andlanguage differences continue to block effective communication and actionacross different countries, lobbies, and governmental functions. To facil-itate cross-organisational collaboration among the various users, semanticand cultural interoperability are preconditions.

Information quality Governments, the market, and individuals increasingly needwell-defined, timely, accurate, reliable and appropriate information drawnfrom many sources. In the future, guaranteeing information quality willbecome both more important and more difficult as the number and varietyinformation sources (including informal sources such as wikis and weblogs)continues to grow.

Assessing the value of government ICT investments After years of substantialinvestments of public funds, the potential benefits of e-Government can nolonger be assumed, but must be demonstrated. Proper frameworks, meth-ods, tools and metrics to monitor and evaluate the efficiency as well as ben-efits of e-Government investments are lacking. Above all, a clear under-standing of the value of e-Government, and value for whom, is needed.

eParticipation, citizen engagement and democratic processes In using Informa-tion and Communication Technology, elected officials and civil servantsmust remain open and accountable in their activities, behaviour, and decision-making. At the same time, government must ensure that those individualsand groups that wish to participate in democratic processes have the oppor-tunity and means to do so.

Mission-oriented goals and performance management Many projects do notstart with the primary missions of government in mind. Instead, they areoften dominated by a technology-driven approach. This is similar to thesituation in which a budget is structured and evaluated by the nature of ex-penses rather than by the public service goals that expenditures support. Inboth cases management attention is diverted away from the core mission.

Cyber infrastructures for e-Government Future e-Government technology plat-forms might consist of a reliable, ubiquitous infrastructure that supportssystems and applications assembled out of readily-available, reusable com-ponents. However, realisation of this possibility requires research in variousdomains including whether and how a building block-oriented ICT-industrycould develop, and what types of architectures, building blocks, and stan-dards are needed.


Ontologies and intelligent information and knowledge management All gov-ernments are currently struggling with huge information overloads, withnew and emerging ICT capabilities, and with a shortage of informationmanagement skills and human expertise. Ontologies and knowledge man-agement facilities (such as search, retrieval, visualisation, text mining, andintelligent reasoning) seem promising be exploited to achieve informationquality and economy, and to support knowledge management processes ine-Government settings.

Governance of public-private-civic sector relationships Increasingly, an highnumber of governmental functions and public services incorporate signif-icant roles for private sector or civic organisations. These roles play out ina variety of relationships from advisory, to collaborative, to contractual, tofull partnerships. Adequate principles and frameworks are lacking, whichfacilitate and set the ground of collaboration in advancing and deployinge-Government in regards to sharing responsibilities and exchanging infor-mation among networks of diverse organisations in ways that generate pub-lic value and satisfy public requirements for fairness, accountability, andcompetence.

Government’s role in the virtual world Global electronic markets, virtual or-ganisations, virtual identities, virtual products and services, and Internet-related crime are growing in prominence and importance. In a world that isincreasingly non-physical and borderless, government’s roles, responsibili-ties and limitations are subject to change and are blurring.

Crossing borders and the need for governance capabilities The scope of prob-lems and trends that governments need to cope with vary widely in size,intensity, and complexity. Social networks, gender issues, environmentalconcerns, political movements, etc. reach beyond local, regional or nationalborders. It is unclear, how these phenomena can be steered and governedproperly across organisational boundaries, especially through exploiting ca-pabilities available in neighbourhood regions and contexts.

e-Government in the context of socio-demographic change Demographic trendswith global consequences (such as age distribution, wealth distribution, im-migration, and mobility and distribution of workers) are generating pressingissues in both developed and developing countries. Within the EuropeanUnion, facilitating mobility of citizens and trade across the whole internalEuropean market are strategic aims to foster. These strategic goals as wellas the demographic movements and changes require the public sector at the


various administrative and political levels to act and react with accordingpublic service offers.

Data privacy and personal identity Data privacy and personal identity have be-come important aspects in the Information Society. On the one hand, thepotential of modern ICT could be exploited to take advantage of personal in-formation to improve the performance and quality of government services.On the other hand, privacy and personal data need to be secured and pro-tected in order to prevent misuse and fraud.

e-Government is now recognized as a research domain and a key conditionto promote the growth and competitiveness of the European knowledge society.For this e-Government research in Europe is embedded in the Information Tech-nology Society (IST) program with the aim to create the world’s most advancedinformation society.

Chapter 3The Service Vision

The aim of this chapter is to present Service Oriented Architecture (SOA) and theservice-orientation concepts. SOA is one of the next steps in software engineeringand service-oriented solutions tend to rely on a combination of architectural stylesand analysis, modeling, design and implementation activities. Main of the chapteris influenced by the reading of [40] and [39].

3.1 Fundamentals of Service-OrientationService Oriented Architecture refers to an architectural style that aims to enhancethe efficiency, agility, and productivity of an enterprise using services to representsolution logic.

Basically, SOA revolves around the service-orientation design paradigm andfrom a technical perspective consist of a combination of technologies, products,supporting infrastructures, etc. that support the creation, execution, and evolutionof service-oriented software.

SOA relies on the concept of service. Thomas Erl states that:

Services exist as a physically independent software programs withdistinct design characteristics that support the attainment of the strate-gic goals associated with service-oriented computing. Each service isassigned its own distinct functional context and is comprised of a setof capabilities related to this context. Those capabilities suitable forinvocation by external consumer program are commonly expressedvia a published service contract. [40]

In this sense a service is the fundamental unit of solution logic and service-orientation is the design paradigm on which SOA base its strength.

28 CHAPTER 3. THE SERVICE VISION

As a fundamental units services can be arranged to a coordinated aggregationto form a service composition. Services with functional contexts that are agnosticto any one business process are capable to participate in multiple service compo-sition. The key point is that services must cooperate and must not be extremelyspecific but they should have an abstraction level that allow reuse in several con-texts.

To support the repeated, agile creation of effective service compositions, ser-vices are collected using service inventory. A service inventory is an indepen-dently standardized and governed pool of complementary services that presentsan high degree of native inter-service interoperability.

Services can be categorized depending on: (i) the type of logic they encapsu-late, (ii) the extent of reuse potential this logic has, and (iii) how this logic relatesto existing domains within the enterprise.

Typically, a common classification will identify three kind of services:

Entity Services are related to one or more business entities that define relevantentities like customers, employees, etc.

Task Services are related to functional business task to perform. They encapsu-late business process logic to carry out a sequence of steps to complete aspecific task.

Utility Services represent services whose logic is not associate with an entity ora task. These services are not business-centric and provide reusable, cross-cutting utility functionality such as event logging, notification, etc. Theyare known also as infrastructure services.

SOA is agnostic to any one technology platform. An enterprise is free topursue its strategic goals leveraging future technology infrastructure but in thecurrent marketplace the reference implementation used to build SOA solutions isthe Web Service one.

The Web Service platform is composed by a continuously growing number ofindustry standards. These can be partitioned in two generations. The first is relatedto the original standards like Web Service Description Language (WSDL), XMLSchema Definition Language (XSD), Simple Object Access Protocol (SOAP),Universal Description, Discovery, and Integration (UDDI), and WS-I Basic Pro-file. The second concerns new proposal for message-level security, cross-servicetransactions, reliable messaging and so on, and is known as WS-* extensions.These supply rich feature for design services and to implement them.

In the platform a web service comprise three main things: (i) a service con-tract that consist in a WSDL description, a XML Schema definition and eventuallysome WS-policy policies. The contract exposes the service methods to potential

CHAPTER 3. THE SERVICE VISION 29

users; (ii) a programming logic developed for the service or derived form exist-ing components reengineered for service usage. This is the business logic im-plemented by the service; and (iii) a message processing logic that is commonprovided by the runtime environment.

Moreover, a service can be associated with roles depending on its utilization.It can be used as a service provider that receives a request message and responds,or can assume the role of consumer when it is required to issue request messagesto other web services.

SOA delivery and service implementation need a specific methodology thatconsist of structured analysis and design processes. These processes focus onthe accurate expression of business logic using technology which requires thatbusiness analysis play an active role in the definition of the conceptual design ofsolution logic. This assure alignment between the documented business modelsand their implementation.

Service-oriented analysis is a formal analysis process completed by businessanalyst and technology architects. In this context, service modeling producesconceptual service definitions called service candidates, and iterative approachof analysis and modeling results in the creation of service candidates that canform a service inventory. After modeling, service-oriented design aims to producephysical service contracts starting form the service candidates. During design,candidates services, that are conceptual services that has not been implemented,become physical service really implemented. This “contract first” approach is atthe heart of service-oriented design.

A single service can provide a collection of capabilities grouped together inthe same service because they relate to a functional context established by theservice. In this sense a service act as a container of related capabilities exposedby the service contract.

Design approaches for services rely on the well-known software engineeringprinciple of separation of concerns. This principle states that a large problem canbe solved more effectively when decomposed into a set of smaller problems orconcerns. This partitioning of the solution logic into capabilities and the groupingof capabilities into units of solution logic is an activity that best represent serviceanalysis and modeling.

Separation of concerns is the main feature of service-orientation as a designparadigm and a solution logic that can be state as “service-oriented” refer to sev-eral principles as: Standardized service contract, service loose coupling, serviceabstraction, service reusability, service autonomy, service statelessness, servicediscoverability, and service composability.

All these principles refer to the fundamental principle of interoperability that isinherent to the intrinsic nature of services itself. Indeed, the main goal of applyingservice-orientation is for interoperability.


3.1.1 Goals and BenefitsService Oriented Architecture has very ambitious goals and is very attractive toany organization interested in improving the effectiveness of the enterprise. Thisis the motivation that guide the adoption of SOA with all the changes that this mayimply. Several strategic goals and benefits can be identified:

Increased Intrinsic Interoperability Interoperability refers to the sharing of data.Interoperable software programs share information easily while softwarethat are not interoperable need to be integrated. Integration can be seen as aprocess to enable interoperability.

Service-orientation aim to produce native interoperability to reduce the needfor integration. The application of the design principles and design stan-dards focus on reach an high interoperability level among services. Interop-erability is a fundamental goal that establishes a foundation for the realiza-tion of other strategic goals and benefits.

Increased Federation A federation of environment is a context where resourcesand applications are united maintaining their single autonomy and self-governance. This is possible with the deployment of standardized and com-posable services that encapsulate business functionalities in a consistentmanner.

Increased Vendor Diversification Options Vendor diversification is the abilityto choose vendor products and technology to use inside the enterprise. Tohave diverse vendor products is non necessarily beneficial but the benefits isin the capability of choice and in the non-locked architecture independent toany one vendor platform. This imply the freedom of change, extend, replacesolution implementation without disrupting the whole architecture.

Increased Business and Technology Domain Alignment Abstraction introducedby SOA adoption reduce the gap between software applications and busi-ness needs when the nature of the business change. Service layers that en-capsulate and represent business logic can be aligned with real needs due tothe intrinsically interoperability that favor these business changes.

Increased ROI Return on investment is a critical factor for every technologyadoption. The greater is the return, the more an organization benefits formthe adopted solution. SOA focus on the creation of agnostic solutions thatcan be reused for multiple purpose increasing ROI. This is achieved by us-ing the services in different compositions and making the service part of theIT asset for the purpose of repeatable, long-term financial returns due to itsutilization.


Increased Organizational Agility Agility refers to the efficiency with which anorganization respond to changes. To increase organizational agility is veryattractive because a quickly adaptation to industry change can have a strate-gic significance. Service-orientation strategies results in the creation of ser-vices that are highly standardized and reusable and then useful to respondrapidly to changes. Service inventory should comprise more and more ofagnostic services that can be composed in reusable configurations. Thisapproach increase organizational agility.

Reduced IT Burden Introduction of service orientation results in waste and re-dundancy reduction, size and operational cost reduction, and reduced over-head associated with governance and evolution. Conversely, SOA adoptionincrease efficiency and cost-effectiveness. Software, through SOA, becomea more effective contributor to the enterprise strategic goals.

3.1.2 Problems SolvedBusiness tasks execution is the main software functionality in enterprise. Thiswas true even first the inception of service-orientation when such solution wherecreated identifying the business tasks, defining their requirements and buildingsolution logic (in a non-service-oriented way).

This achieve tangible business benefits providing a predictable return of in-vestment, but the capabilities of these applications are tied to a specific businessrequirement and change management become a very complex issues to deal with.When changes happens significant changes must be made on the application ora new applications should be built. This is not the perfect approach although so-lution are efficient, automate only a task at time that imply a clear vision andunderstanding from analysts and developers, but a lots of improvement should beintroduced in the delivery process.

The traditional approach can be wasteful because the creation of new solutionlogic does not favor reuse and a lot of redundant functionality can be discoveredinside applications. This drawback lead to a decrease of efficiency because com-mon functionality were rebuilt for many applications. Instead, creation of redun-dant logic should be avoided in an efficient process. Moreover, after their deploy-ment, applications need maintenance inflating budget and resources. This can bea problem of the overall organization that can be avoided reducing redundancies.Moreover, the management of applications result in complex infrastructure be-cause different application may use different generation of technologies each onewith its requirements. These augment problems in response to changes becauseit is difficult to plan the evolution of the enterprise. Last, but not the least, appli-cations are not interoperable because they are not designed to do so. Sharing of


data will need integration architectures or large middleware layers that contributeto augment the presented problems.

Service-orientation combines design elements of these approaches with newdesign elements. The application of principles of service design (presented laterin this chapter) will results in:

• increased consistency in the representation of functionality and data

• reduced dependencies between units of solution logic

• increased opportunities to reuse solution logic

• increased opportunities to combine solution logic into different configura-tions

• increased behavioral predictability

• increased availability and scalability

• increased awareness of available solution logic

These characteristics bring to a common synergy between service and sev-eral benefits for the enterprise are promoted. Services that implements agnosticand reusable functionality are not specific for any one application or process andthey constitute a valuable asset due to their reuse capability. This will reduce theamount of application-specific logic and the overall quantity of solution logic inan application.

Solution logic based on services are naturally aligned with the business of theenterprise. Moreover, an initial a base level of interoperability is achieved acrossservices due to their standardization of contracts and data models.

3.1.3 Challenges IntroducedService-orientation as we have seen can solve significant problems but its appli-cation can make serious impositions. Reuse implies that a significant amount ofservice inventory is made by agnostic services capable to fulfil requirements formultiple potential applications. This introduce an increased level of complexityfor both the architecture and individual services:

• increased performance requirements resulting from increased reuse

• reliability and availability issues of services

• single point of failure introduced by excessive reuse (that require redundantdeployments for risk mitigation)


• increased demand on service hosting environments

• service contract versioning issues and impact of potentially redundant ser-vice contracts

These can be addressed by sound technology architectures, modern runtimeplatforms, and the consistent application of service-orientation principles. More-over, to have a successful propagation service-orientation, design standards adop-tion can solve problems making several decision for architects and developers buttheir adoption may encounter cultural resistance and some people see them as aninhibitor of creativity and ability to innovation.

Service delivery is associated with a top-down strategy in which a significantamount of analysis effort involve many members of the organization to produce aservice inventory of all planned services, their relationships, boundaries, and indi-vidual service models. This is not often feasible due to budget and time constraintsand tactical priorities of the organization. This induce services to be producedearlier but this may imply the revisitation and redesign at a later point. Prematureimplementation introduces risks but it is considered as an acceptable compromise.

SOA enables agility inside organizations, but agility is exploited when servicesare implemented to produce new applications answering business needs. Duringinventory specification the amount of code to produce is high and this can beseen as a counter-agile if the organization needs to be responsible while buildingthe service inventory. Typically this can be overcame delivering SOA alongsideexisting legacy projects. In this manner, tactical requirements can be fulfilled intraditional ways while enterprise works on its innovation.

Service inventory needs to be managed and evolved introducing responsibil-ities on how manage service and on their “ownership” because often in a largeorganization the team that develop services may not continue to own the servicelogic as it gets utilized by others solutions and other teams. To overcome thesesituations precise governance structures are required which introduction may de-mand time, and expenses.

3.1.4 Effects on the EnterpriseService-orientation may induce high expectations. While SOA places an high em-phasis on reuse establishing a service inventory with a high percentage of reusableand agnostic services, applications are made by service compositions. They doesnot consist of self-contained programming logic but of a composition made up ofservices that very likely participate in other compositions. This cause that appli-cation loses their individuality due to an high level of service reuse, but it is clearthat there are services that are non-agnostic but represent dedicated logic of onebusiness task that is not necessarily reusable.


Services are designed to be intrinsically interoperable, this imply the freedomto mix them into potentially infinite composition configurations to fulfill businessrequirements. The concept of integration begins to fade because the exchange ofdata between units of solution logic become a natural and secondary design char-acteristic when an effective service inventory is present inside the organization.

It is worth to note that despite service composition has several benefits, it isnon an easy process but it is a design exercise that require detailed documentationof the planned composition architecture at the basis of the composition: servicesneed to be assessed to fulfill its role as a composition member, moreover messagedesigns, messaging routes, exception handling, cross-service transactions, poli-cies, and many more considerations should be made to make effective the servicecomposition respect to its designated business process.

3.2 Design Principles of Service Orientation

A design principle can be defined as “a recommended guideline for shaping so-lution logic with certain goals in mind” [40]. The goals stated previously can beachieved applying patterns when designing software programs. It is important thatthese principles take a larger, prominent role during development.

Eight principle were presented as they are state in [40]. They can be definedas in table 3.1 and grouped into two categories as showed in Figure 3.1: (i) princi-ples that results in specific service design characteristic, that comprise Standard-ized Service Contract, Service Reusability, Service Autonomy, Service Stateless-ness, Service Discoverability; and (ii) principles that regulate the application ofthe other as Service Loose Coupling, Service Abstraction, Service Composability.

3.2.1 Service Contracts

Service contracts are a fundamental concepts because rely on the description ofwhat the service do and how the service can be viewed form the outside.

The goals rely on enabling a natural level of interoperability within the bound-ary of the service inventory inside the organization. In this manner the need fordata transformation are reduced because data models for information exchangeare consistent. Moreover, service contracts allow a better comprehension of thepurpose and capabilities of services.

This principle must be achieved providing with the service a standardized ser-vice contract resulting from a formal process of design with has the aim to achieveconsistency inside the inventory.


Service-orientation principles Definitions

Standardized Service ContractServices share standardized contracts -Services within the same service inven-tory are in compliance with the samecontract design standards

Service Loose Coupling

Services are loosely coupled - Servicecontracts impose low consumer couplingrequirements and are themselves decou-pled from their surrounding environment

Service Abstraction

Non-essential service information is ab-stracted - Service contracts only con-tain essential information and informa-tion about services is limited to what ispublished in service contracts

Service ReusabilityServices are reusable - Services containand express agnostic logic and can be po-sitioned as reusable enterprise resources

Service AutonomyServices are autonomous - Services exer-cise a high level of control over their un-derlying runtime execution environment

Service Statelessness

Services minimize statefulness - Ser-vices minimize resource consumption bydeferring the management of state infor-mation when necessary

Service Discoverability

Services are discoverable - Services aresupplemented with communicative metadata by which they can be effectively dis-covered and interpreted

Service Composability

Services are composable - Services areeffective composition participants, re-gardless of the size and complexity of thecomposition

Table 3.1: Definitions of service-orientation principles


implement independent functional boundary and

runtime environment

minimize the availability of meta information

imp

lement co

mm

unicative m

eta inform

ation

imp

lement a

standard

ized co

ntractim

plement adaptive and

state managem

ent-free

logic

minim

ize

dependencies

max

imize

com

posabilit

y

implem

ent g

ener

ic an

d

reusa

ble lo

gic an

d

contra

ct

Service

Standardized service

contract

Service Discoverability

Service Autonomy

ServiceAbstraction

Service Statelessness

Service Composability

Service Reusability

Service LooseCoupling

Figure 3.1: Design principles: specific characteristics (on the right) and regulatory(on the left)

3.2.2 Service Coupling

Coupling in Information Technology is referred to anything that connects different“parts”. The aim of this principle is in loosening coupling that means to avoid toform tight dependencies between services, between a consumer program and aservice, and between services and their underlying implementation environment.

The goal of this principles is to reduce coupling within and between servicesincreasing independence of service contracts from their implementations and in-creasing independence between them. Services and their consumers can evolveover time with minimal impact each other.

This principle can be achieved through the existence of service contracts de-coupled from technology and implementation details and, from a user perspective,minimal consumer requirements.

3.2.3 Service Abstraction

Abstraction relies on the hiding of all information not absolutely required for oth-ers to effectively use a service. The more information is revealed in a service


contracts the deeper coupling between service and consumer can become. Thiscan have a bad influence on the design of consumer programs because can lead tosome consumer to implementation coupling. Moreover, keeping details hidden,service logic and its implementation are able to evolve over time continuing torespect the service contracts.

With this principle the goal is to keep the quantity and detail of contract con-tent concise and balances preventing unnecessary access to additional details.

3.2.4 Service ReusabilityThis principle is the more fundamental in service-orientation. The key concept isto make a software program useful for more than just one single purpose becausein this manner the development investment can be more valuable.

Goals related to reuse are tied directly to some of the objectives of service-orientation. Reuse allow service logic to be repeatedly used over time to havean high return from the original investment. At organizational level reuse allowsservice composition to fulfill business requirements of the organization increasingbusiness agility when change happens. Reuse takes advance on the generality ofservice logic, flexibility of service contracts, and agnostic functional context thatmake a service reusable in more than one usage scenario.

3.2.5 Service AutonomyThe attitude in service orientation is on decomposition of functionality when aservice inventory is made. Each service is viewed as a standalone building blockindependent form its surroundings.

Autonomy relies on self-government because something that is autonomoushas the freedom and control of its own decisions to act independently form oth-ers. High level of autonomy can be reached with program implementation moreisolated that brings to increased reliability and predictability due to its indepen-dence. Indeed, the main goal is the increase of runtime reliability, performance,and predictability, especially when services are reused and composed.

Autonomy can achieved with contracts that express well-defined functionali-ties without overlapping with other services, with environments in which servicescan have a great level of control, and with environments that supports concurrencyfor scalability purpose.

3.2.6 Service StatelessService compositions can be complex and the quantity of activity-specific data thatneeds to be managed and retained during the life of a service is high. Moreover,


this increase with the numerous instances of services that run concurrently in theinfrastructure.

Each state can be represented in a software system by data that typically hasa lifespan equivalent to the duration of the active task in the running application.State management is the management of these temporary data. The followingtypes of state conditions can exist: (i) active and passive states, (ii) stateful andstateless conditions, (iii) context, session, and business state data, (iv) contextdata and context rules. All these can be managed for the goals to increase servicescalability and to support design of agnostic service logic to potential improveservice reuse.

This principle promotes a condition of the service that is temporary in nature.For example, process-agnostic services are not designed to retain state informa-tion for specific processes, and are subjected to less constrained service contracts.Memory request in the infrastructure is reduced but statelessness can require aruntime that is highly efficient to perform state transitions from idle to active andto perform parsing of message payloads.

3.2.7 Service Discoverability

The process of searching for and finding solution logic within a specified environ-ment is referred as discovery. An architectural resource that can be discovered isconsidered to have a measure of discoverability.

Discovery of services require a consistent mean to communicate informationabout resources. The goal is that these information must be accurately defined andclearly documented in a consistent format to allow their access and interpretabil-ity for the research of available services. Meta information about a resource (aservice) comprise the purpose of the resource, their capabilities and the limitationof these capabilities.

Discovery allow enterprise to keep trace of the inventory content. When acapability is need, this is search in the inventory and if there is, it will be used.Instead, if the capability is not in the inventory, it will be build, used, and thencatalogued in the inventory.

In this way the discovery function is fundamental, if information about re-sources is inadequate user may lose opportunity to reuse an existing resource andthe new build resource may introduce redundancy in the enterprise software asset.Reuse and normalization are undermined and the architecture become bloated andconvoluted.

The primary motivation behind discovery is the use of service registry to estab-lishes a mechanism for on-demand location, retrieval, and interpretation of servicemetadata.


Discoverablity can be achieved with service contracts equipped with appropri-ate metadata useful for discovery and for human understandability. Although thegoal of this principle is about a design characteristic of a service and non aboutthe architecture, it is worth noting that a registry element is a part of the originalarchitectural representation of SOA in Figure 3.2

Service Provider

discover and retrieve contract

publish and register contract

exchange messages

Service Consumer

Service Registry

Figure 3.2: Original architectural representation of SOA

3.2.8 Service Composability

Reuse is considered a core principle of service-orientation which realization isrelated to an effective and repeated aggregation of services in compositions.

Separation of concerns encourage an approach in which a big problem is de-composed in small problems that are solved by units of solution logic. These unitsare assembled and coordinated into specific configurations to build a compositionthat has the aim to solve the original big problem. In this way solution logic existsas a composable units that can be used and reused to solve new problems.

The goal of this principle is to provide the medium through which the ultimategoal of service orientation can be achieved. Enterprises with inventory of highlyreusable services has the means for satisfy future business needs.

To participate in a composition, services must have a highly efficient execu-tion environment able to manage concurrency, and service contracts needs to beflexible to facilitate data exchange with different levels of granularity. As a conse-quence hosting runtime environments need to be scalable and reliable as possible.


3.3 Building Service Oriented Architecture

3.3.1 Delivery StrategiesSOA delivery projects with the aim to build service-oriented solutions are char-acterized by a life cycle with several steps showed in Figure 3.3. These steps arecommon in distributed application development but initially in the life cycle it isworth noting the “service-orientation” aspect that lead to the whole process.

Service-orientedAnalysis

Service-orientedDesign

ServiceDevelopment

Service Testing

ServiceDeployment

ServiceAdministration

Figure 3.3: SOA development life cycle

Service-oriented analysis starts the development modeling individual servicesas service candidates determining what must be build. Service-oriented designdetermine how these services can be build and if business processes should bedefined. This phase is related to technology and to standards used to respect allthe principles discussed previously. Next, services and processes are developedconsidering platform-specific issues and environment. After development a rigor-ous testing is required to better exploit the potential reuse of solution logic theycarry on in different scenarios and processes. Finally, the deployment phase isrelated to installing and configuring runtime environments and services while thelast phases refers to application management of the running system.

These sequential phases represent a simple very high-level description of astrategy to build SOA. We can refine this into three strategies that are based on theorganization’s priority of establish the right balance between long-term migrationgoals and the fulfillment of short-term requirements: (i) top-down, (ii) bottom-up,and (iii) agile.

Top-down

Top-down strategy is an ”analysis first” approach that derive to an existing busi-ness logic (that may be non-service-oriented) and that point to the developmentof numerous reusable services and business processes. Starting form businessrequirements the steps this strategy follows are showed in Figure 3.4.

The strategy starts defining relevant domain ontologies to define a classifica-tion of the information and their relationships. Existing solution logic may needto be adjusted to respect this classification and business modeling terms expressed


Define relevantontology

Align relevant business models


Service-oriented Design

ServiceDevelopment

Service Testing

ServiceDeployment

Figure 3.4: Top-down delivery strategy

in the ontology. These steps are a prerequisite for the analysis and design phasesand for quality assurance checks during testing. Finally, services are deployed asusual.

This approach results in a high quality service architecture. The design isefficient, maximizing reuse and opportunities for composition. Although, the top-down strategy require significant investments and time in analysis without imme-diate results during the initial phases.

Bottom-up

Bottom-up strategy builds services “as needed” and models application logic tosolve immediate requirements in a software application. Integration is the mainmotivation for this design and services can be developed as wrappers to legacysystems. Figure 3.5 show the strategy phases. As in the top-down strategy, busi-ness requirements are considered as collected and defined.

The first step define application requirements to build service-centric solu-tions, then wrapper services can be delivered by purchasing them by third-parties,while custom services will need an appropriate design process. Usual phases asdevelopment, testing and deploy follows with a particular emphasis on testingof performance and stress testing of legacy system that may need adjustments inprocessing parameter to best work with wrapper services.

Application service modeling

Application service design

Application service

developmentService Testing

ServiceDeployment

Figure 3.5: Bottom-up delivery strategy

The bottom-up approach is widely used because inside an organization legacysystems can benefit of the web service technology to implement SOA but service-orientation principles are not considered. Then this approach cannot be validto build SOA from scratch but can help to introduce SOA inside organization.


However, implementation of a “very” SOA at a later point may suffer of non-standardized service models produced with bottom-up.

Agile

The agile strategy aims to find an acceptable balance between the application ofservice-oriented design principles and the need to satisfy business requirementas soon as possible introducing web service technology as wrapper for legacyapplications.

Business-level analysis should occur concurrently with service design and de-velopment, for this the agile strategy is more complex than the previous two sim-ply because it needs to fulfill two opposing sets of requirements, as showed inFigure 3.6.


Service-orientedDesign

ServiceDevelopment

Service Testing

ServiceDeployment

Service and business process

revisitation

Top-down analysis

Align with current state business models

Align with current state business models

Re-design, re-develop, re-test, re-deploy as required

Figure 3.6: Agile delivery strategy

The strategy starts with a standard top-down analysis but the main focus is onthe parts of the business models directly related to the business logic to develop.

When the top-down analysis has sufficiently progressed, and while it is stillin progress, service-oriented analysis is performed. During this phase top-downanalysis become sufficient mature to proceed with the creation of business ser-vice models and design. After these phases, services are developed, tested anddeployed. Moreover, as the top-down analysis continues to progress, businessservices will be reviewed against the current business models. Discrepancies arelisted and services are scheduled for redesign that imply new phases of develop-ment, testing, and deployment.

This approach require an enforcement of the concept of service contract. Aftera contract is published, it cannot be modified unless revisions result in extensions,but not in restriction, respect to the original contract.

This strategy takes the best of both strategies with the aim to fulfil both shortand long-term needs. The “drawback” is that running services risk misalignment


with a constantly changing business model and maintenance tasks are required toensure alignment with these business models.

3.3.2 Service Oriented Analysis

Service-oriented analysis is the first step in the strategies presented previously. Itsaim is to establish what the services should consist of.

This process determines how business requirements can be represented usingservice-orientation and its outcomes consist on the decision of what services needsto be build and what logic should be encapsulated on each of them.

Indeed, after analysis a preliminary set of service operations are candidatesfor realization and groups of operation represent service candidates to be part ofthe SOA. Each service is considered respect to its boundary to avoid overlappingwith other and to identify logic with can potentially be reused. A preliminarycomposition model will be defined.

The service-oriented analysis process is a sub-process of the overall SOA de-livery life cycle that foresees the three steps in Figure 3.7. The first step definesbusiness automation requirements. Requirements centered around the creation ofservices for SOA are collected because their documentation is needed for the fol-lowing steps. Then, the analysis continue identifying existing automation systemswhich application logic eventually is related to the identified requirements. Thisis convenient in a large scale enterprise that can have already a service inventoryor some legacy systems. Finally, the last step models candidate services. Withthis process service operation candidates are identified and then grouped into alogical context. Service candidates are derived form these groups and a possiblecomposition model is assembled to represent the combination of the applicationlogic of services.

The final step of service-oriented analysis is service-oriented modeling. Thissub-process is organized on twelve steps (see Figure 3.7) to model SOA organizedon three layers: application, business, and orchestration.

The application service layer express technology-specific functionalities. Ser-vices that reside within this layer are solution-agnostic, generic, reusable appli-cation services whose purpose is to provide reusable functions related to dataprocessing. The business service layer introduces in the architecture services con-cerned the business logic, as task-centric services that encapsulates business logicspecific to a task and entity-centric services that encapsulates a specific businessentity. Finally, the orchestration service layer introduces process services compos-ing other services to provide specific sets of functions. These manage the inter-action details required to ensure that service operations are executed in a specificorder.


Business requirements

definition

Automation systems

identification

Candidate services modeling

Decompose Business process

Identify operation

candidates

Abstract orchestration

logic

Create service

candidates

Refine and apply

service-orientation

Identify service

composition

Revise operation grouping

Analyze processing

requirements

Identify application

service operations

Create application

service candidates

Revise service

composition

Revise operation grouping

Figure 3.7: Steps of service-oriented analysis and modeling

Step 1: Decompose the business process Starting form the analysis documentsbreak the process into granular steps.

Step 2: Identify business service operation candidates Isolate operation candi-dates and identify activities to be encapsulated in services, as manual pro-cess steps that cannon be automated, process steps performed by legacy sys-tems, . . . . This step isolate the processing parts more relevant for service-orientation.

Step 3: Abstract orchestration logic If SOA will comprise an orchestration layerthis steps is aimed to identify the parts of processing logic that orchestrationwill address: business rules, conditional logic, exception logic, sequencelogic, . . . . In this steps (an in the overall modeling), we are creating can-didates, namely potential services. In the service-oriented design phase,practical considerations come into play and some adjustments to the archi-tecture can be made.

Step 4: Create business service candidates Group business operations to deter-mine logical contexts. Each one represents a service candidate. In this step,task-centric business services will require a context specific to the process,while entity-centric business services will be grouped according to the otherentities their are related on. The scope of this step can be expanded to in-clude an analysis of additional service operation candidates not required by


the current business process, but useful for reuse purpose.

Step 5: Refine and apply principles of service-orientation Looking at the logicencapsulated in the service candidates identified previously try to refinethem applying principles of service-orientation. Reusability, autonomy,statelessness and discoverability can keep into consideration carefully be-cause web service technology does not intrinsically provide them. Althoughstatelessness and discoverability concerns with design, the focus in this stepis to ensure that each service will be reusable and autonomous as possible.

Step 6: Identify candidate service compositions Identify a set of scenarios thatcan take place within the boundaries of the business process. Analyzingthem we can have a good idea if the grouping of process steps has beenmade appropriately and we can identify potential compositions

Step 7: Revise business service operation grouping Revisit the grouping of thebusiness process steps and revise the organization of service operation can-didates as necessary.

Step 8: Analyze application processing requirements This next series of stepsis optional and more suited for complex business processes and larger service-oriented environments. In this step, to complete a preliminary applicationservices layer a closely study of the processing requirements of all servicecandidates is needed. Specifically, for each operation candidate it is impor-tant to determine what application logic needs to be executed.

Step 9: Identify application service operation candidates Identify and break downeach application logic processing requirement into a series of steps.

Step 10: Create application service candidates This step is focused on group-ing processing steps according to a predefined context. With applicationservice candidates, the primary context is a logical relationship betweenoperation candidates: (i) association with legacy systems, (ii) associationwith one or more solution components, (iii) logical grouping according tofunction.

Step 11: Revise candidate service compositions Revisitation of candidate ser-vice compositions to incorporate new application service candidates. Par-ticular attention must be given on how business service candidates map tounderlying application service candidates.

Step 12: Revise application service operation grouping Revisitation of the group-ing and definition of application service operation candidates on the basis


of step 11. Any omissions in application-level processing steps results inthe addition of a new service operation candidate.

Optional Step: Keep an inventory of service candidates This process has as-sumed that there are not service inventory an it is the first modeling activityof service candidates inside an organization. As optional step, a serviceinventory can be realized to keep trace of the analysis outcomes for the fu-ture. Subsequent iterations of this process should take care of the existenceof service candidates into service inventory.

Service-oriented analysis in a SOA delivery project requires critical decisionsabout the shape of individual services as well as the overall architecture. Servicemodeling is the process of identifying candidate service operations and group-ing them in candidate services. This sub-process is fundamentally a process ofgathering and organizing business model information. Business process logic isdecomposed into a series of granular steps that represent candidate service opera-tions that will grouped into logical contexts that represent candidate services. Allthese information are a precondition for an effective service-oriented design.

3.3.3 Service Oriented DesignService-oriented design is the process by which concrete physical service designsare derived from logical service candidates and then assembled into abstract com-positions that implement a business process.

This process address how physical service interface definitions can be derivedfrom the specification of the models of service candidates made during analysis.The focus of the process is about realizing SOA using industry standards andextensions to implement real services and SOA characteristics.

Some further analysis is needed to determine the boundaries of the architectureand identify potential service compositions. Moreover a core set of design stan-dards to support service-orientation principles must be identified to define serviceinterfaces. Service-oriented design as a part of delivery strategy is composed ofthe five steps showed in Figure 3.8

Compose SOADesign

entity-centric business services

Design application

services

Design task-centric

business services

Design service-oriented

business process

Figure 3.8: Steps of service-oriented design


Step 1: Compose a SOA Compose a SOA require three main steps: (i) the choiceof service layers, (ii) the positioning of core SOA standards, and (iii) thechoice of SOA extensions.

The first (i) is about decision on the design configuration for the servicelayers that will comprise and standardize logic representation within the ar-chitecture and is made studying the candidate service produced during theservice-oriented analysis phase. The second (ii) asses core standards thatwill be implemented in the architecture to best support the service-orientedsolution. Finally, the third (iii) determine contemporary SOA characteristicsto be considered. In the setting of web services this rely on WS-* specifica-tions.

The fundamental components that typically comprise an SOA built withweb service technology include: (i) an XML data representation architec-ture, (ii) web services built upon industry standards, (iii) a platform capableof hosting and processing XML data and web services.

Step 2-4: Design Services These steps effectively design services. Three sepa-rated sub-processes that starts from analysis of service candidates are in-volved: (i) Entity-centric business services design process, (ii) Applicationservice design process, (iii) Task-centric business services design process.

The first (i) is devoted to represent data entities defined within an organi-zation’s business models. The resulting services are solution-agnostic andprocess-agnostic built for reuse of enterprise information. The second (ii)is focused on the services that are responsible of carrying out activities dic-tated by the business layer; and finally the third (iii) aim to design task-centric services and to implement operation candidates identified as part ofthe service modeling process.

These sub-processes aim to have a balances service design to allow servicesto encapsulate the required amount of logic to meet business requirementswhile maintaining conformity with service-orientation principles.

Step 5: Design service-oriented business process This step aim to provide anexecutable workflow logic through the use of process definitions. This or-chestration layer is typically expressed using WS-BPEL and form the gluethat binds services with business process logic.

Although SOA is not related exclusively with web services this is the mainimplementation technology we refer to. Several technologies [29] are used alltogether and are related as in Figure 3.9.


WSDLXML Schema

UDDI

SOAP

BPEL

defines types for

binds to

is accessed using

enables discovery of

defines type and payload structure for

definestypes for

binds servicesusing

Figure 3.9: Relations among WS-related technologies

WSDL Web Services Description Language [20] provides a model and an XMLformat for describing Web services. WSDL enables the separation of thedescription of the abstract functionality offered by a service from concretedetails of a service description such as ”how” and ”where” that functionalityis offered.

A web service is described in two fundamental stages: one abstract and oneconcrete. Within each stage, the description uses a number of constructs topromote reusability of the description and to separate independent designconcerns. At the abstract level, WSDL describes a web service in terms ofthe messages it sends and receives; messages are described independently ofa specific transport format using a type system, typically XML Schema. Atthe concrete level, a binding specifies transport and transport format detailsusing endpoints to associates a network address with a binding.

XML-Schema XML Schema Definition Language [105] is a language that de-fine and describe a class of XML documents by using schema componentsto constrain and document the meaning, usage and relationships of theirconstituent parts: data types, elements and their content, attributes and theirvalues. Schemas can also provide the specification of additional documentinformation, such as normalization and defaulting of attribute and elementvalues.

Any application that consumes well-formed XML can use XML-Schema toexpress syntactic, structural and value constraints applicable to its documentinstances.

SOAP Simple Object Access Protocol [52] defines an XML messaging protocolfor basic service interoperability. It is a lightweight protocol intended forexchanging structured information in a decentralized, distributed environ-ment. It uses XML technologies to define an extensible messaging frame-work providing a message construct that can be exchanged over a variety ofunderlying protocols. The framework has been designed to be independent


of any particular programming model and other implementation specific se-mantics.

SOAP is fundamentally a stateless, one-way message exchange paradigm,but applications can create more complex interaction patterns (e.g., request/re-sponse, request/multiple responses, etc.) by combining such one-way ex-changes with features provided by an underlying protocol and/or application-specific information. SOAP is silent on the semantics of any application-specific data it conveys, as it is on issues such as the routing of SOAPmessages, reliable data transfer, firewall traversal, etc. However, SOAPprovides the framework by which application-specific information may beconveyed in an extensible manner.

UDDI Universal Description Discovery & Integration [8] provides the infrastruc-ture required to publish and discover services in a systematic way. Thefocus of UDDI is the definition of a set of services supporting the descrip-tion and discovery of (i) businesses, organizations, and other Web servicesproviders, (ii) the web services they make available, and (iii) the technicalinterfaces which may be used to access those services. It is based on a com-mon set of industry standards, including HTTP, XML, XML Schema, andSOAP, and provides an interoperable, foundational infrastructure for webservices-based software environments for both publicly available servicesand services only exposed internally within an organization.

The main UDDI purpose is the representation of data and metadata aboutWeb services. A UDDI registry offers a standard mechanism to classify,catalog and manage Web services, so that they can be discovered and con-sumed. Businesses and providers can use UDDI to represent informationabout web services in a standard way such that queries can then be issuedto a UDDI Registry (at design-time or run-time) to find web services im-plementations that are based on a common abstract interface definition anddetermine the protocols supported.

WS-BPEL Web Services Business Process Execution Language [4] provide amean to define business processes using a formal description of the messageexchange protocols used by business processes in their interactions. Modelsfor business interactions typically assume sequences of peer-to-peer mes-sage exchanges, both request-response and one-way, within stateful, long-running interactions involving two or more parties. A WS-BPEL process isa reusable executable definition that can be deployed in different ways andin different scenarios, while maintaining a uniform application-level behav-ior across all of them.


A WS-BPEL process may be used to describe observable message exchangebehaviour of each of the parties involved, without revealing their internalimplementation. These behaviour must clearly be described in a platformindependent manner and captures behavioural aspects that may have crossenterprise business significance. This enable the full potential of Web Ser-vices as an integration platform that will be achieved only when applica-tions and business processes are able to integrate their complex interactionsby using a standard process integration model.

To complete this chapter in Figure 3.10 is showed the overall process that acommon delivery strategy for an SOA should comprise. Most of the steps wasdiscussed here while the finest details can be found in [39].

CHAPTER 3. THE SERVICE VISION 51Se

rvic

e-or

ient

edAn

alys

isSe

rvic

e-or

ient

edDe

sign

Serv

ice

Deve

lopm

ent

Serv

ice

Test

ing

Serv

ice

Depl

oym

ent

Serv

ice

Adm

inis

tratio

n

Busi

ness

re

quire

men

tsde

finiti

on

Auto

mat

ion

syst

ems

iden

tifica

tion

Cand

idat

e se

rvic

es

mod

elin

g

Deco

mpo

se

Busi

ness

pr

oces

s

Iden

tify

oper

atio

n ca

ndid

ates

Abst

ract

or

ches

tratio

n lo

gic

Crea

te

serv

ice

cand

idat

es

Refin

e an

d ap

ply

serv

ice-

orie

ntat

ion

Iden

tify

serv

ice

com

posi

tions

Revi

se

oper

atio

n gr

oupi

ng

Anal

yze

proc

essi

ng

requ

irem

ents

Iden

tify

appl

icat

ion

serv

ice

oper

atio

ns

Crea

te

appl

icat

ion

serv

ice

cand

idat

es

Revi

se

serv

ice

com

posi

tions

Revi

se

oper

atio

n gr

oupi

ng

Choo

se s

ervi

ce

laye

rsPo

sitio

n co

re

stan

dard

s Ch

oose

SO

A ex

tens

ions

Stan

dard

ize

serv

ice

inte

rface

Exte

nd s

ervi

ce

desi

gnId

entif

y re

quire

d pr

oces

sing

Defin

e en

tity

Sche

ma

Deriv

e ab

stra

ct

inte

rface

Appl

y se

rvic

e-or

ient

atio

nRe

view

exi

stin

g se

rvic

esRe

view

exi

stin

g se

rvic

esCo

nfirm

con

text

Deriv

e in

itial

in

terfa

ce

Defin

e w

orkfl

ow lo

gic

Deriv

e in

ital

inte

rface

Appl

y se

rvic

e-or

ient

atio

n

Map

out

inte

ract

ion

scen

ario

sDe

sign

pro

cess

se

rvic

e in

terfa

ceFo

rmal

ize

partn

er s

ervi

ce

conv

ersa

tions

Com

pose

SO

ADe

sign

en

tity-

cent

ric

busi

ness

ser

vice

sDe

sign

app

licat

ion

serv

ices

Desi

gn ta

sk-c

entri

c bu

sine

s se

rvic

esDe

sign

se

rvic

e-or

ient

ed

busi

ness

pro

cess

Appl

y se

rvic

e-or

ient

atio

nSt

anda

rdiz

e se

rvic

e in

terfa

ceAd

d sp

ecul

ativ

e fe

atur

es

Stan

dard

ize

serv

ice

inte

rface

Iden

tify

requ

ired

proc

essi

ng

Defin

e pr

oces

s lo

gic

Alig

n in

tera

ctio

nsc

enar

ios

and

refin

e pr

oces

s de

finiti

on

Figu

re3.

10:O

vera

llde

liver

yst

rate

gyfo

ran

SOA

Part II

Design Guidelines forInteroperability

Chapter 4Interoperability in e-Government

In this chapter we discuss the importance of metadata in the e-Government domainshowing their application in a cooperative environment and their use as enablingtechnology for intelligent documents. Most of the contents were published in[CDPR07a] and [CDPP07].

4.1 Metadata in Cooperative EnvironmentsThe term “metadata” represents a set of information about data. This informaldefinition refer to the Greek term “meta” (who means pertaining) and from Latin“data”, plural of “datum” (that means information).

In literature there are several different definitions of metadata. We refer hereto the most common and relevant:

“Machine-understandable information about Web resources or otherthings” (Tim Berners-Lee, 1997) [10]

“Data associated with objects which relieves their potential users ofhaving to have full advance knowledge of their existence or character-istics. A user might be a program or a person” (Dempsey and Heery,1998) [33]

“Structured data about resources that can be used to help support awide range of operations” (Michael Day, 2001) [32]

It is clear that the distinction between data and metadata is not intrinsic but dependon the context in which we utilize metadata. The metadata them-self are data andtherefore they can be stored as usual data (in the resource they represent, or in

56 CHAPTER 4. INTEROPERABILITY IN E-GOVERNMENT

another), and can be described by other metadata, and so on. The number ofmetalevel to specify depends from the features of applications and from differentspecific needs. Typically, when we argue about metadata we make a distinctionon the basis of a classification on five levels (Figure 4.1).

Layer 1, Instance Metadata comprises the raw data as values, and does not referto anything other. They are represented by data instances that represents theeffective value-oriented elements that are not of interest if considered inisolation.

Layer 2, Syntactic Metadata are the first explicit metadata that are needed by amachine to “know about” the data. These metadata are inherent to the typesof digital information, data types, language formats, messages or documentslength, source, bit rate, encryption, and so on.

Layer 3, Structural Metadata gives form and structure to “units” of data. Thisis simply a way to understand the structure of data and the three main way torepresent them using on hierarchical, relational or object-oriented paradigm.

Layer 4, Referent Metadata provides linkage between different data models. Theydescribe how data should be converted from a schema to another in thesame language, or one schema to another in different languages, or again,one schema to another at very different abstraction levels. Their form canvary widely, and in some application that works with several data modelsthey can be embedded inside the application code, although, many systemsleverage mapping and scripting technologies to make explicit them.

Layer 5, Domain Metadata provides contextual data to other data and informa-tion. This capability is a crucial requirement for information sharing ar-chitectures to convert data meaning across multiple contexts. Typically theuse of ontologies [51] as contextual metadata gives application a referencepoint to perform transformation and interpretation of data from differentand seemingly incompatible heterogeneous contexts.

Layer 6, Rules is a transverse layer that cuts across all the discussed layers.Rules are used to constrain the semantics of metadata specifications andmodels at any abstraction level. Like structural and syntactic metadata theycan be embedded in application code also if recent efforts try to alleviate thisproblem with specific XML-based languages. Business rule represent def-initions of business terms, data integrity constraints, mathematical deriva-tions, logical inferences, etc.

Nowadays, the role that metadata has in the World Wide Web is very importantand in particular refers to the need of finding useful information in a wide amount

CHAPTER 4. INTEROPERABILITY IN E-GOVERNMENT 57

Domain Meta-data

Referent Meta-data

Structural Meta-data

Syntactic Meta-data

Instance Meta-data

Rule

s M

eta-

data

Figure 4.1: Metadata stack

of data. In this contest, the capability of metadata to be understood both formhumans and from machine result the right choice for the reduction of time andcosts related to information research and comprehension.

Today, in the Public Administration setting there is a process of administrativedecentralization of competencies and we observe a transformation of administra-tive procedures from uni-agency to multi-agency. The first represents independentactivities able to perform specific tasks that involve only a single administration,while the other represents the result of a cooperation among various administra-tions that cooperate for reach a common task (typically the delivery of a servicerequired by a final user).

The introduction of more agencies in the service delivery process refers to amodel that try to emphasize the uniformity of interactions but also the character-istics of single supplier and of the single user. There are a few obstacle to facefor the complete realization of administrative decentralization. First of all, the re-pulsion from the management of a reduction of decision power, but also technicalproblems due to the pluralism of architectural solutions. In this contest metadataemploys a fundamental role to detect a solution that - from one side - preserve ad-ministrative autonomy and that - from the other side - allows different systems tosafely cooperate. The introduction of recognized standards appear in this contesta way to realize a full interoperability.

In this section we would highlight the role that metadata plays in applica-tive cooperation presenting some guidelines and an architecture able to assureinteroperability between informative systems to favor the modernization of PublicAdministrations reducing time and costs for its functioning.

We note how metadata plays a crucial role supplying the necessary substratefor the functioning of software. On the basis of the functionality that metadata areable to manage, they should be classified in three classes:

Descriptive Metadata used for the identification and finding of digital objects;they are built from normalized descriptions of native digital documents.


They reside usually on information retrieval systems.

Administrative and Managerial Metadata that supplies useful data for the man-agement of described resources and for managerial operations about digitalobjects inside archives.

Structural Metadata that describes the internal physical or logical structure ofdocuments (es: introduction, chapters, sections, etc.) and their relationswith others digital objects.

Metadata can be distinguished also on the basis of their localization respect tothe resource they are related to. Indeed, metadata can be embedded or external. Inthe first case they are included in the resources, while in the latter they are outsidethe object who refer to and stored as a link to the described object.

The principal functions that them would realize are: (i) to manage resourcessupplying their identification to favor presentation and retrieval; (ii) to allow theorganization, the localization, the management and the statistics; (iii) to favorinteroperability and integration of similar resources; and (iv) to favor the storageand the preservation of resources.

4.1.1 Semantic InteroperabilityMetadata plays a crucial role in semantic interoperability that is defined as:

“a dynamic enterprise capability derived from the applications of spe-cial software technologies (such as reasoner, inference engines, on-tologies, and models) that infer, relate, interpret, and classify the im-plicit meanings of digital content without human involvement - whichin turn drive adaptive business processes, enterprise knowledge busi-ness, rules, and software application interoperability” [94].

Clearly, this capability rely on data that as the foundation for any information-sharing program. Looking at Figure 4.2 we can see how all integration levels arebased on data (and metadata) integration.

This enhanced notion of data include semantic and context then we turn datainto information using metadata. Several capabilities can emerge using metadata:

Data Interoperability enables data to maintain its original meaning in multiplecontexts using data meanings as the basis for transformations.

Process Interoperability enables business processes to be expressed in terms ofanother inferring meaning from contextual data and applying it in a differentprocess/context.


Business

Process

Method and

Transaction Level

Interface and Service Level

Data and Semantic Level

Figure 4.2: Hierarchy of integration levels

Services/Interface Interoperability enables a service to discover, bind and use(communicate) with a new service without predefined custom glue code.

Application Interoperability enables the interactions of methods and transac-tions between heterogeneous software applications to achieve platform in-dependence.

Taxonomy Interoperability enables any category in the taxonomy to be expressedin terms of other categories exploiting meaning in category definition.

Policy Interoperability enables businesses to protect valuable resources usingsecurity mechanisms and rights management.

Social Network Interoperability enables people in different communities to net-work, infer and discover connections through previously unknown contacts.

Interoperation of these components lead to a high level of dynamism with po-tentially the feature of an autonomic environments like: (i) self-configuring (ofinterfaces service descriptions, etc), (ii) self-optimization (of transactions, rout-ing, queries, etc.) (iii) self-healing (recovery of error flows, etc.) and (iv) self-protection of data.

4.1.2 Characteristics of the Interoperability FrameworkA framework for interoperability that can constitute the infrastructure for an e-Government information system should be defined - according to Pollock andHodgson [94] - as:


“a highly dynamic, adaptable, loosely coupled, flexible, real-time, se-cure, and open infrastructure service to facilitate a more automatedinformation-sharing framework among diverse organizational envi-ronments”.

We mention in the definition several characteristics:

Dynamic relies on the infrastructure ability to support the configuration of infor-mation assets in previously unforeseen ways without human intervention.This concerns dynamic data transformations, query and data mapping gen-eration, and discovery of information and services.

Real time relies in the capability of building new modes of communications amongservices and systems on demand, without change the infrastructure.

Loosely Coupled relies to the principle of indirection used in systems design andarchitecture. Indirection is used to separate concerns to prevent them to betightly coupled: when two components needs to be coupled, instead to dothis directly, a third thing act as a mediator connecting them. Abstractionenable looseling coupling allowing an efficient, dynamic, and automatedinformation sharing.

Highly Flexible relies on the capability of reconfiguration of components. Eachenterprise system or information resource should be capable to participatein the architecture that must be pluggable. Different technology platformsshould have the ability to use (or join) the framework using metadata de-scriptors (and eventually software artifact that implements some glue code).

Security needs to exist at every layer of a complete technology architecture. Net-work security, application security, data security must be considered andproperly enforced inside the architecture.

Open refers to the feature concerning the duration in the time of the architecture.A solution that is built for a long life should meet these criteria: (i) indepen-dence of proprietary products and adherence of open standards (platformneutral services, schemas, registries, communication protocols, etc.), (ii)neutrality to core business differences (use of data vocabulary mediation,query mediation, process mediation).

Service Oriented relies on the architectural style used that is supposed to beservice-based.

Information-Centric relies on the application of knowledge management prin-ciples that should be applied to a computing environment to formalize the


description and management of data. This give to data the right importancein this context.

Autonomic refers to the capability of the framework to evolve on its own, typi-cally performing configurations and maintenance in automation without hu-man intervention. To do this, software should be able to infer data meaning,alter data semantics over time and in general to reason about informationand services following high-level human guidelines.

Clearly, interoperability frameworks that fulfil all the presented characteristicsmay be the panacea in e-Government information systems and in general in mid-dleware technologies. Our proposal have an high level of abstraction but shouldencompass as much as possible these feature to bring near the optimal solution.Our interest is mainly focused on framework for service delivery, web servicesand document management.

4.1.3 Interoperability Architecture

Our proposal works in a distributed environment in which available informationsystems must be integrated to easily enable information sharing over the Internet.We promote an evolution and a reuse of existing solutions including them in aglobal environment preserving a correct information flow according to a businessmodel that will involve different actors. In Figure 4.3 we propose a general systemarchitecture.

Legacy application systems will be wrapped into subsystems that enable in-teroperability with other subsystems in a predefined scenario. A subsystem role(and its ontological description) will guarantee the delivery of appropriate systemfunctionality between processing modules - using web service technologies. Sub-systems use a document repository to store multi-format documents generated byexisting solutions. These documents form the input for a ontology engineeringframework.

The Interaction module, acting as a local mediator, guarantees the interactionsbetween roles associated with system functionalities. This means that incompati-bilities at message level are handled by the interaction module that tries to mediateinteraction between roles. On the other hand, it represents a part of a global me-diator between legacy systems and other subsystems involved into the distributedprocessing. In this setting, interaction module uses a shared metadata repositoryand exploits the potential of a shared dictionary respect to a given local conceptu-alization.

Communications will use the Communication channel for service message ex-change. It represents the unique medium for interaction among subsystems roles


Role C

Document Repository

Legacy System

Role A

Role B

Interaction Module

Subsystem

Role C

Document Repository

Legacy System

Role A

Role B

Interaction Module

Subsystem

Role C

Document Repository

Legacy System

Role A

Role B

Interaction Module

Subsystem

Communication Channel

Document Ontology

Process Specification

Schema Repository

ProcessInteraction

ModuleMessage Interaction

Module

Coordination Engine

Figure 4.3: Interoperability architecture


and is represented by the underlying network infrastructure. The communicationchannel will also support the distribution of knowledge around the service eco-system.

The global coordination activity is performed by a coordination engine andwill be able to manage global process specifications. In this context, a speci-fication document according to a conceptualization specifies process behaviourand manages document flow among subsystems. The basic functionalities of theengine are represented by two modules: the process interaction module and themessage interaction module. The first manages process specifications and is ableto manage data and documents to satisfy a specified goal. This is the core of thecoordination engine that uses process specification and manages the interactionbetween subsystems. At the same time it manages the roles involved in each sub-system and their relationships. A common schema message allows the interactionmodule to work effectively. Schemas and ontology are stored in a repository (on-tology library) that contains all the relevant information to identify messages thatare used by the interaction module to solve inconsistency problems. Moreover, itsupports process interaction module managing the schema of messages exchangedamong subsystems.

In our setting a shared set of schema/ontology avoid the construction of astatic mapping between heterogeneous models. Otherwise, we propose a seman-tically rich approach where a shared ontology enables interoperability betweensubsystems. With this solution, documents are annotated with semantic metadatausing a document ontology. This allows document retrieval starting from a partialspecification contained in the process definition. The interoperation between theco-ordination engine, document ontology and communication channel will makefull use of an element discovery engine. It is worth noting two forms of use (seeFigure 4.4): (1) when a definition requires one or more process elements, thesewill be found by the element discovery engine (and include decomposition) usingthe document ontology and (2) when new knowledge is extracted from a legacycomponent (or other multi-format document), it will be distributed across the net-work by a propagation engine using the communication channel and stored inlocal document ontology libraries.

Finally, interoperability will be achieved because process definitions specifiesbusiness interaction among roles involved in the whole system. The specificationby a business user, coupled with semantic decomposition into process element,provides a novel business integration infrastructure.

4.1.4 ConsiderationsThe importance of standards for information representation in the public sector isclear. Metadata standardization is the best manner to define semantics in cooper-


Communication Channel

Document Ontology

Coordination Engine

Element Discovery

Engine

Ontology Propagation

Engine

Figure 4.4: Ontology propagation and element discovery

ative decentralized systems in Public Administrations. With an adequate invest-ment the standardization should bring to the applicative cooperation considerablequantitative and qualitative benefits.

We can achieve a better accuracy in the management of semantic aspects ofcooperation, reduction of interdependencies, semantic transparency, and a fair dis-tribution of applicative logic. From the qualitative perspective, we can highlighthow applications can benefit of homogeneous conceptual models, reduction oftime for the implementation of legislative changes and a substantial reductionof integration costs. Naturally, we should considers costs related with the con-struction of the metamodels, the management of metadata services, as well as thetraining of people, the consulting, and specific software.

For IT management and in particular for what concern interoperability policiesinside Public Administrations a series of factors come into play: e-Governmentstrategies, service needs and requests, improve of investments, legacy systems,infrastructures and available knowledge inside agencies. Moreover, inside a sin-gle organization the integration of information and processes can go parallel butthe main idea is to allow cooperation among a set of shared elements using amiddleware infrastructure. Indeed, a small set of partners can establish continuecooperation for process integration to constitute a long-lasting cooperation activ-ity among Public Administrations.

With e-Government diffusion Public Administrations will face with a new di-mensions concerning technology. We propose a complete integration character-ized by open and dynamic distributed systems based from a strong heterogeneousresources and legacy information systems. It is clear that e-Government domainmust resolve problems that arise in all those contests. To do this a constructivecomparison between technical and managerial capabilities of different administra-


tions should take place. This is not a trivial task because require an high coopera-tion level for the definition of intra-administration common strategies. Moreover,cooperation become a complex challenge when information exchange is vehicu-lated using services but new opportunities for interoperability arises from the useof service-oriented architecture. These should be relevant for e-Government be-cause integration of processes and information will drive integration of large scaleapplications and Public Administration information systems.

4.2 Ontology-Driven development of IntelligentDocuments

In e-Government, interoperability and applicative cooperation compete for thedevelopment:

• back-offices process integration for service provisioning, and

• distribution of services with suitable quality attributes.

Public Administrations increase their shared knowledge [94], stimulating therealization of infrastructures that allow applications to suitably cooperate. Suchcooperation would certainly benefit by a formal representation of the reality ofinterest.

In this section we concentrate on document management and propose a model-driven document management for Public Administrations that is based on ontolo-gies [51] to describe and analyze the relations between concepts [104].

The importance of ontologies to describe the structure of a document can befound in [65]. An ontological description of electronic documents has been ex-plored in [28] for the so-called “Intelligent Document” that describes both thedocument structure and the procedural iter for its filling. Within an intelligentdocument we can identify different parts - different zones - the compilation ofwhich is responsibility of different PAs by means of suitable workflows.

We use ontologies also to describe the type of data and information within thedifferent zones. This provides a strong support for filling documents but also fortheir analysis and generation of suitable interfaces or documents form.

We also discuss how our ontology-based documents formalization supportsthe entire life cycle of the document: from the user interface creation to the man-agement of the document compilation and its storage. From the ontology, indeed,we can retrieve a form to represent the user interface of the document. We canalso manage the iter of compilation using the information contained in the processmodel of the document. Moreover, the document persistence is also managed by


means of an ontology management system that maps the document ontology to arelational database.

Besides providing a semantic management of electronic documents, the gen-eral ontology-based framework we discuss in the domain of Public Administra-tions, provides a solid support to automatic administrative procedures and allowsinformation retrieval and knowledge management according to the demands of asingle Public Administration.

4.2.1 Administrative and Semantic Cooperation

We use ontologies because it defines a set of the categories of certain entities thatexist (or could exist) in an application domain. Indeed, one of the well-knowndefinitions is by Tom Gruber [51]: “An ontology is an explicit specification of aconceptualization”.

The term is borrowed from philosophy, where an Ontology is a systematicaccount of Existence, but from a more applicative point of view what exists iswhat can be represented. In fact, an ontology allows to define the meaning of theconcepts that belong to a specific domain establishing the relationships betweenentities (classes, relations, etc.). To do this it is necessary a language (e.g. RDF)for ontology representation.

In particular, ontologies allow the formalization of a model of the world (or apart of it) that includes concepts and relations [15]. It is also worth of introducingthe concepts of informal ontology and formal ontology. The former, by using anatural language description, simply describes the defined and indefinite entitiesof a given catalog of types. The latter, instead, arranges names in concepts andtypes of relationships, and is organized in classes and sub-classes of types.

The first step for ontology construction is the creation of a reference dictionary(informal ontology, a list of keywords that describes the content of the document).After the creation of this catalog we compose a standard representation of the in-formation. In these years many standards have been proposed to describe ontolo-gies and the most known languages are RDF (Resource Description Framework)[74] and OWL (Ontology Web language) [103]; both based on XML.

Using an infrastructure based on ontologies, namely an ontology-driven infor-mation system, we are able to overcome various PAs problems such as:

• semantic management of documents;

• scalability and, in particular, dynamic specialization according to the realneeds of the Public Administration;

• knowledge access and knowledge sharing;


• integration of the existing technology.

4.2.2 Intelligent Document DefinitionMore and more organizations use electronic documents for process management.Marketing analysis have shown a cost-effective use of such electronic documentsin place of standard document management. In several cases, costs can even beeliminated in favor of a more efficient data retrieval from the actors of the auto-mated process.

PAs can take advantage of the use of electronic documents because of a (i)consistent decreasing of the costs of press, elaboration, distribution, delivery, etc.,(ii) consistent decreasing of compilation errors, (iii) possibility to share and/or toaccess the shared information. Moreover, from the other side, citizens and compa-nies, as end-users, can take advantage of the use of electronic documents becauseof a (i) consistent decreasing of the time needed for manual compilation, (ii) elec-tronic dispatch of the documents, (iii) decrease of the delivery costs (postal, fax,etc). This short and certainly incomplete analysis shows the necessity to create aprocess of workflow management that contemplates the fruition of the electronicdocument inside the application domain. The approach that has been used tillnow is not enough to answer our questions, we don’t have to think to an Intelli-gent Document as a simple form but as the result of an orchestration of servicesoffered by the community of PA’s that participates in its filling.

With this idea in mind we describe the main characteristics of an IntelligentDocument, namely an “e-Document for the Public Administration”. An intelligentdocument must be:

• Multi Composed: it contains information on both its state and the applica-tion domain. Different processes and users may compete to its creation;

• Multi Version: the tracking of data is guaranteed by the persistence of thevarious documents versions. Every office of the involved Public Adminis-trations compiles the part (zone) of the document of its competence;

• Multi Dependence: it consists in the creation of the electronic documentfrom a collection of other documents via a modular application-domain de-pendent architecture;

• Multi Data Type: different data types can be considered within the docu-ment;

• Multi Platform: the compilation and use of a document have to assure theinteroperability at the application level;


The attribute Multi Dependence is significant for our discussion. It autom-atizes the standard procedure of a document creation in the Public Administra-tion where different office may compete for a document filling. For example, a“Birth Certificate” needs information by both the registry office of the munici-pality where one person was born and by the residence office. Of course, themunicipality where one person was born can be different from where he/she lives.The compilation of this typology of documents may require, therefore, externalactors to a specific Public Administration [1].

Sequence Split Split-Join Any-Order Choice If-Then-Else

ControlCostruct

CompositeActivity

ActivityDataType

Document Version

PublicAdimistration

Intelligent Document

Document Part Document Process Model

controlledBy

hasVersion

isCompetenceOfperformedBy

isShowedIn

constitutedBy

isComposedOf manageconsiders

controlledBy

Figure 4.5: Intelligent document ontology

These concepts are shown in Figure 4.5. We describe a simple ontology thatrepresents the concept of Intelligent Document. This ontology can be mergedwith the ontology describing the structure of a document - a document-specificontology - in order to detect the forming parts of the document itself. In fact, anIntelligent Document can be divided in several parts shown in different version-s/views. Each view has a version identifier and each PA involved in the documentfilling process can modify only the specific part that is of its own competence.The filling process is itself part of the intelligent document definition. It performsactivities (represented by the Activity concept) that are a couples composed by aDocumentPart and a PublicAdministration.


4.2.3 Document-specific Ontology

In order to provide an ontology-based information system able to manage docu-ments of PAs, we need an ontology that describes the concepts and the relationsdefining the documents themselves.

In this section we consider, as a case study, the specific document of the “BirthAct”; though similar considerations hold for other kinds of documents within Pub-lic Administrations.

A birth act legalizes a birth [CDPB06]. The iter in the Italian legislation startswith a “birth declaration”(also called “birth denunciation”) carried out by a parentor a delegated. This document must be presented by ten days to the “Stato Civile”office in the municipality in which the birth was happened. However, the hospitalcan start this iter, but the birth declaration carried out by a parent or a delegatedmust be performed by three days after the birth. The birth declaration is mandatoryfor the “birth act” that is also the bases for other documents such as the “birthcertificate”. The birth certificate must be delivered to the registry office and to the“imposte dirette”1 office in order to allow the compilation of the “codice fiscale”2

that is demanding for the personal “tessera sanitaria”3.

The needed ontology must contain concepts describing a birth that refer toa child. Moreover, the document is composed by an header and several clausesthat represent DocumentPart of the intelligent document. This kind of pointersintegrate the intelligent document ontology with the document-specific ontologyas shown in Figure 4.6 regarding relation represent that binds concepts from doc-ument ontology to concept DocumentPart of the intelligent document ontology.The reader interested in the whole ontology description of the birth certificate canconsult [CDPB06].

Though we have presented the key work on a specific document, this is theprocedure one has to consider to develop a new document in our framework. Wehave to describe the reality with an ontology and link concepts to the intelligentdocument ontology. Of course, we also have to state the activities and how theseare handled by PAs. This can be done through the definition of Activity concept inthe intelligent document ontology.

These ontologies are the models used by our information system in order tobuild the infrastructure used to perform the procedural iter of a document compi-lation.

1Imposte dirette office is an office that manages taxes related documents2Codice fiscale is an Italian personal code for taxes related documents3Tessera sanitaria is an Italian document used to sanitary identification of people


"Birth Document"

Birth

Clause

Child

Person

Birth Information

Header

Document Part

makeOfficial

isComposedOf

representsrepresents

have

refers to

haveHeader

Relation to Intelligent Document Ontology

Several type of clauses that form the document

Figure 4.6: Document-specific ontology and relations to intelligent document on-tology

4.2.4 Ontology-driven Intelligent Document Compilation

All forms of engineering rely on models to better understand complex, real-worldsystems. Ontology-based models provide abstractions from physical world allow-ing developers to reason about systems at different abstraction levels. We nowdiscuss how ontologies can be used to guide the process of building on-line in-telligent documents and to drive the storage of relevant information inherent thedocument itself.

Our approach is based on the architecture shown in Figure 4.7. We modelthe document using the intelligent document ontology and the document-specificontology (describing document related concepts) just like the birth certificate dis-cussed in 4.2.3. This model is used in the Document Persistence and in DocumentEngine modules of our architecture. Document persistence module is constitutedby an ontology management system that is formed by an import module, a back-end storage and a query engine. The import module is responsible of the mappingfrom ontology to relational database. The main advantage of this approach in-stead of classic database is the use in conjunction with a query engine. Queryingontologies can benefit of inference mechanisms and it is possible for the systemto answer complex queries using deduction.

Moreover, document engine has two tasks performed by Forms Generator andCompilation Manager. The first generates forms - user interface of on-line intel-ligent document - based on ontologies. These forms can be viewed and utilized


Form/UI Generator Compilation ManagerDocument Engine

Query Engine

New Document Ontology

Intelligent Document Ontology

Ontology Modeling Document Persistency

Storage

Import Module

Figure 4.7: Architecture of the ontology-based information system for intelligentdocument delivery

with a browser. Using a formal representation of concepts and related data typeswe can assembly forms considering various constraint on controls inside it. TheCompilation Manager module is responsible for the control of the compilationprocess by taking into account the workflow that has to be performed to fill thedocument. The workflow is, of course, document-dependent and contains all theinformation about the procedural iter of the document filling.

For example, assume there is a document with two parts: part 1 and part 2. Thecompilation of part 1 is responsibility of the Public Administration “A” while thecompilation of part 2 is responsibility of the Public Administration “B”. Moreover,assume that the filling of part 2 must follow the filling of part 1 because PA “B”wants to check part 1 before its task. This also means that PA “A” starts thedocument compilation and only when it has finished sends the document version“B”. By its side, “B” completes part 2 and then sends the overall document to “A”because “A” has started the whole process.

Of course, this is a very simple kind of cooperation that involves only two PAs.In reality we can find more complex scenarios and in these cases a proper processspecification that describe the document compilation iter can be of great benefit.

Summing up, in order to deliver a new kind of document we must specify theontology that describes the document itself together with its iter of compilation.This ontology is used by the information systems of the involved PAs (those thatare involved in the delivering of the document). Each PA generates the forms


needed for the document filling and is able to detect the tasks to be performed onthe basis of the process model describing the activities. The compilation process ismanaged by the “Document Engine” of the PA that starts the iter of compilation asorchestration of services of the involved PAs, querying both the local knowledgebase and external ones and interacting with users by means of the generated forms.

4.2.5 ConsiderationsIn this section we have shown an ontology-based methodology and infrastructurefor the delivery of intelligent documents within Public Administrations. PAs canaccess a common repository to find ontologies describing a document and set uptheir information systems to manage the entire life cycle of the document: userinterface creation, data storage and management of the iter of compilation.

The models and the conceptual architecture that we have discussed in thissection derive from a careful analysis of the e-Government application domain.We deal with the concept of Intelligent Document, a document that is able todescribe its structure and to specify the procedural iter for its filling. This can beseen as a result of a cooperation between PAs involved in the delivery. Document-based cooperation has the potential to improve efficiency among PAs but alsosatisfaction for final users as citizens and firms.

Chapter 5The Marche Region delivery system

Marche Region is among the first places in Italy as welfare, cohesion and compet-itiveness. Last but not least, Marche presents an innovative and authentic cultureof social relations in which freedom and responsibility, autonomy and interdepen-dence, efficiency and solidarity are deeply linked. This has allowed lots of smalland medium enterprises to grow, to encourage the local economy to be more com-petitive. This needs an effective e-Government system.

In this chapter, we proposed an overview about e-Government in the MarcheRegion. It offers innovative solutions for authentication, authorization, discov-ery and composition. According with our knowledge the approaches proposedin Marche Region are “good practices”. This discussion takes into considerationTECUT as a fully integrated government portal for the delivery of standardizedservices to citizens and firms.

5.1 Requirements for Web Portals and ServicesThe importance of citizens is crucial in the e-Government vision. Whatever, therelationship between citizen and business, citizen and government, citizen andICT should be seriously considered to stand out the importance of citizen in thee-Government construction:

1. Citizens and firms: both are customers of government that have the rightto receive services and that require high service quality either in traditionalgovernment mode or in e-Government mode. Innovation in governmentrequires the building of an e-Government for them.

2. Citizens and government: citizens are customers of government and this isthe main focus of the e-Government construction. Governments must pro-vide integrated services via one stop e-Government (a single access point to

74 CHAPTER 5. THE MARCHE REGION DELIVERY SYSTEM

all services) and services must reach a wide part of the population especiallyin disadvantage zones in which e-Government must exploit the potential ofICT technologies.

3. Citizens and ICT: government adopts the Information and CommunicationTechnology to meet the requirements of citizens, and not trail behind tech-nology development. The construction of e-Government must be orientedto citizens and not to ICT.

After analyzing these relevant relationships, we can understand the self-evidentimportance of citizens in e-Government that requires a broadly understanding oftheir requirements during the whole process of e-Government construction. Wecan summarize the major benefit factors as follows:

1. Avoid personal interaction: e-Government provides opportunities to citi-zens to receive public services without any interaction with government’sstaff [43], [53], [83].

2. Control: e-Government experts more control over the delivery of the servicethan through another method. That is to say, e-Government gives citizensmore powers [18], [30], [121];

3. Convenience: government services are available and accessible at any time,anywhere and in any methods citizens want [18], [83], [121];

4. Cost: e-Government provides opportunity to save money [70];

5. Personalization: Citizens customize government services by use of ICT[109];

6. Time-saving;

At the same time, barrier factors are shown:

1. Confidentiality: the privacy of citizens must be kept in secret and not usedfor other purposes [18], [109], [121];

2. Easy to Use;

3. Enjoyable: the experience of citizens must be enjoyable [30], [69];

4. Reliable: the e-Government web site must have services that are required bycitizens and citizens must believe that a required service will be delivered.Accordingly, government must provide service accurately and update theinformation on the web in time [9], [53], [121];

CHAPTER 5. THE MARCHE REGION DELIVERY SYSTEM 75

5. Safety or Security: e-Government must avoid break-into of hacker and keepall information of citizens in secrete especially their sensitive and financialinformation [18], [70];

6. Visual Appeal: the web site should look good [70], [88].

In our work we try to receive all these requirements to build e-Governmentsystems around the citizens that are the final users. We can benefit of the experi-ence of several projects in Marche Region in Italy then we can test our solutionsin real case studies to investigate user satisfaction in approaching e-Governmentservices.

5.2 Service delivery in the Marche Region

The portal TECUT (“TECnologia Utile”) is realized by Marche Region taken ad-vantage of the “Choesion” [87] [27] infrastructure. This is a framework used toimplement infrastructural services to deploy applicative cooperation actions, se-cure front-office access, content management services, and workflow. For regionalcitizens and firms this portal represents an unique access point to information andservices. Also, services provided can be used by other agencies of Public Admin-istration inside the Region. In TECUT the unique access point provided by theweb portal hides the complexity of the back office organizations [112] [113] tothe final users.

The portal in Figure 5.1 is able to offer a vision of on-line Public Administra-tion, near to citizen needs. We point out that the used services and informationare make easier. All this engraves on the service niceness and related popular-ity. At the same time the portal become a reference point at organizational levelproviding back office governance. Today, the portal is a gateway for 677 publicorganizations, provides 53 different kinds of services and 38.881 running services.

About authentication process, the recent proliferation of digital services hasraised a lot of authentication mechanisms. Marche Region supports the realizationof a central authentication solution through Cohesion. This provides solutions forcomplex technical problems and a set of common standard services predisposedto realize applicative cooperation as the national e-Government plan states.

Moreover, Choesion introduces federated identity. It defines mechanisms forcommunities to share identities information among domains. In the Italian con-text of PAs the federation represents a good solution. As a result of it, we areable to create identity-based applications to enable the access to cross-boundaryinformation. Federated identity can be introduced to establish a standards-basedmechanism to both share and manage identities information; as it moves between

76 CHAPTER 5. THE MARCHE REGION DELIVERY SYSTEM

Figure 5.1: TECUT Home page

legal and organizational domains. It enables a cost-efficient means of establish-ing Single Sign-On to cross-domain and it provides the management of multiplesecurity domains with an efficient, lightweight mechanism of linking redundantidentities. In particular, the authentication on the framework is possible with dif-ferent levels: via weak and strong authentication, via the use of a smart card forthe digital signature or via services regional cards “Raffaello” [75]. Furthermore,SSO allows a transparent access to the portal reserved areas without any furtherauthentications and it allows that credentials and user profiling are made availableto different applications. Indeed, the user authentication check is delegated to theservice that uses a regional services register to validate the profile in respect to theaccess roles. The profiling system is dedicated to the coordinated management ofcredentials information, logically divided in a static subsystem and in a dynamicone, containing a series of attributes able to indicate the user’s preferences. A partof the user profile will be requested during the registration phase, while anotherpart is communicated after an explicit request, when a specific service is used.

In TECUT, The study about discovery process propose a rich description of theservices. The basic element in Marche Region is the UDDI registry [8], that playsa fundamental role in digital services distribution. The final aim is to developa repository able of manage services information. The service registry must beable to host information concerning applicative services and tools available to thecommunities.

The portal is evolving towards a distributed and cooperative approach. In par-

CHAPTER 5. THE MARCHE REGION DELIVERY SYSTEM 77

ticular, Marche Region presents a federate community for the discovery process inwhich interoperability and cooperation are fundamental concepts. This federatedreality allows the sharing of digital services and their fair distribution, saving timeand costs. The portal considers also metadata to introduce a flexible and exten-sible PA services representation. In this way, a description of services with highaccuracy level is provided and the metadata allow the introduction of differentclassifications: life events, geographic locations, user targets etc.

Finally, the service composition in the Region takes into consideration orches-tration processes. An execution engine governs web services interacting uponeach other at the message level, including the business logic and execution orderof the interactions. These interactions may span applications, organizations andresult in lifelong transactions. Moreover, documents flow and the management ofcomplex processes need the introduction of the workflow management function-ality that is a system that is used to specify, execute, monitor, and coordinate theflow of documents within a distributed environment.

We can note that our model is built around citizens exploiting the full potentialof service providers. The system is build to solve some issues like: (i) what servicecan be offered, (ii) how a service can be searched and delivered, (iii) how a servicemust be visualized/presented to the user, and (iv) who are the final users interested.

TECUT is a modular system for e-Government services distribution that canbe easily updated, extended and integrated with the existing information system ofPublic Administrations. End users, on the other hand, are expected to benefit froman easier (in terms of the effort to locate and use), faster (in terms of the time) ser-vice delivery. Moreover, TECUT deliveries better services in terms of the qualityand also avoid some direct and indirect costs incurred by current bureaucratic andhighly disintegrated administrative procedures.

Part III

Testing and Verification ofService Systems

Chapter 6Interoperability Testing ofBPEL Orchestrations

In this chapter we describes the work done on testing service orchestrations tohighlight interoperability mismatches that can cause failures in a composition.This work were published in [CDPP08b] and [CDPP08a].

6.1 Introduction

In the previous chapter we see how the Service Oriented Architecture promises toenable fast and secure integration of software infrastructures belonging to differ-ent organizations. The promise is mainly based on the concept of “service” andon the establishment and development of a suite of open standards fostering ser-vice interaction and composition. These standards typically define rules on thoseaspects which generally affect interoperability and composition, such as messageformats or interface descriptions. Indeed the most notable example of SOA, suchas that of Web Services (WS), is based on a quite wide set of agreed and standard-ised information models and format typically referred as WS-*.

Technically a web service [2] is a piece of software available over the Internetthat uses a standardized XML messaging system to interact with other WSs andgeneral clients. Web services technologies solve low level interoperability issuesthrough the use of open and standard XML-based formats (e.g. WSDL [29]) andprotocols (e.g. SOAP [29]). Over such low level standards other application levelstandards have been defined allowing to describe the integration and cooperationof several services in order to fulfill a particular task. This is the case of stan-dards for defining service orchestrations (e.g. WS-BPEL [4]), in which servicecompositions are defined assuming the availability of a central coordinator, or

82 CHAPTER 6. INTEROPERABILITY TESTING OF ORCHESTRATIONS

choreographies (e.g. [91]), in which such an assumption is not taken and servicesare integrated in a fully peer-to-peer fashion.

Particularly interesting in such a setting is the possibility of composing ser-vices externally exposed by different organizations, in order to provide higherlevel functionalities. So for instance a travel agency could compose services fromairlines companies, hotels, and museums in order to provide a higher level servicepermitting to plan holidays in a given place for a defined time period.

Application level standards seems particularly appealing for adoption withinthe e-Government domain. In many cases full provisioning of e-Government ser-vices could require and be represented through the integration and cooperation ofservices externally exposed by different PAs. In a near future a change of res-idence could be requested to the PA accessing to an orchestrated service whichinteracts with other services provided by the different municipalities involved inthe process. This would permit to a citizen to change her/his residence withoutthe necessity of physically going to the various PAs offices.

In such a setting communication standards can certainly help to reduce the riskof interoperability mismatches. Nevertheless communication standards can not gothat far in preventing application related mismatches. These refer to possible dif-ferent assumptions made by interacting services on their mutual behaviour. Withreference to the travel agency service this would mean that standards certainlyhelp to reduce the risk that incompatible data and message format will be used.Nevertheless in case the travel agency assume a different functional behaviourfrom the airlines company, for instance assuming that reservation to be confirmedfrom the airline company perspective, are indeed confirmed booking.

Certainly in the described scenario, and in most scenarios involving PAs, manyissues related to security, authentication, authorization, confidentiality and privacyof the process, and of the handled data, cannot be ignored. Indeed many standardsare starting to emerge trying to provide an answer to such important issues (e.g.WS-Security [85]). Nevertheless the situation become even worse if we admit thatservices can discover each other at run-time, starting only then to interact. In sucha setting many issues related to application level interoperability and integrationemerge. Let’s consider again the case of the change of residence. The servicesdeployed by the two municipalities could be involved in the first mutual interac-tion of their existence. Wrong assumptions on data formats or application levelprotocols could lead to dangerous behavior and unpredictable results. In such asetting our work suggests the usage of testing on discovered services in order tocheck service behaviour before real-usage. As consequence the interaction willstart only if no mismatches are discovered and aborted otherwise. As better il-lustrated in the following of the chapter the approach could also help to increasetrust on service usage from citizens. This use poses clear requests to run-timeplatforms and assumes the possibility of making testing invocations on running

CHAPTER 6. INTEROPERABILITY TESTING OF ORCHESTRATIONS 83

services. This behavior can certainly have dangerous consequences on runningservices that have to be take into account. Nevertheless, these are quite generalconsequences of any run-time testing approach that does not decrease the scopeof the work that can be useful also for the production of effective and powerfultest suites to be used during the service development.

Different approaches can be applied to deal with application related interop-erability mismatches in a open environment, in which services can enter and exitat any time. In restricted application domains one possibility is certainly that ofraising the standardization level to the application level. Nevertheless the mostgeneral solution is to apply techniques permitting to highlight behavioural mis-matches.

Testing is certainly one of the most used approach to highlight integrationproblems through the use of integration test suites. Nevertheless testing is anengineering activities that must be always reconsidered when applied in a newcontext. Testing should try to take profit of new opportunities for control and ob-servation, and should address emerging hurdles. For instance run-time integrationand discovery is certainly one of the major hurdle for testing service composi-tion. The result is that in a certain sense the full application is never availablebefore run-time. At the same the availability of formal models describing serviceintegration can be exploited in the testing activities such as test case derivation.

In this chapter, with reference to orchestration of services, i.e. a special kindof services composition in which a special process, the orchestrator, takes the roleof coordinator, we present an approach for test cases derivation based on formalmanipulation of the orchestration definition. In particular the approach combinemodel checking and genetic algorithms techniques to derive test cases to be usedin order to check the behaviour of the service that will take part in an orchestration.In particular genetic algorithms techniques are used in order to deal with test inputgeneration related issues.

6.2 Service Composition and Trust in e-GovernmentPublic Administration procedures to satisfy citizens needs can be quite complex.Full accomplishment of services that are explicitly defined to be directly usedby the citizens, requires, in the general case, the execution and coordination ofmany different related tasks, often to be performed by various offices, possiblybelonging to many different PA organizations. The involvement of different PAorganizations has important consequences on the total time required to completethe provisioning of a single service. It is not difficult to identify PA services thatlast several days before being completed. Even worse there are cases, particularlyin some countries, in which PA organizations are rather loosely integrated. In such


cases part of the coordination has to be directly carried on by the citizens, whichhave to visit different PA offices to collect, carry on, and return documents; inpractice the citizen has to fix the inefficiencies in PAs integration and organizationputting in place the needed coordination. This situation did not change mucheven with the advent and introduction of ICT within the PA sector. Indeed theintegration of heterogeneous ICT infrastructures has been a really complex andgeneral issue on the table for a long time, which, when feasible, often asks forextremely expensive solutions.

Service orientation will revolutionize the world in ICT infrastructures integra-tion. Thanks to the service abstraction concept and the adoption of open standards,different organizations can easily be integrated, starting to be interoperable with-out the necessity of sharing their internal business rules or data structures. Corre-spondingly a revolution can be easily foreseen on the provisioning of PA servicesto citizens. According to the new paradigm each PA will be abstracted has a set ofprovided services externally accessible, and implemented using one of the avail-able technologies enabling the service orientation vision; being web service andrelated technologies certainly the most prominent choice at the moment.

Adopting the service-oriented approach an e-Government service is derivedthrough the integration and interaction of services externally exposed by eachsingle involved PA. The integration and coordination of the different PA organi-zations is not anymore on the shoulders of the citizen. In this new scenario thecitizen that needs a service can directly go to the offices of the specific PA re-sponsible for providing the service, or can even simply connect to the PA relatedweb site. No knowledge of “PA to PA” interactions is anymore required or willbe evident to the citizen. The whole process is made real through the interactionof services exposed by the various PA organizations, with clear benefits also forwhat concerns total execution time.

Complex e-Government services are typically implemented through the def-inition of so called orchestrations. An orchestration describes, from the point ofview of the orchestrator (director), how a set of participating services should becoordinated. Often the binding of a real service instance to a participant is de-fined at run-time depending on data provided to the orchestrator. For instance ina change of residence the town of provenance, and so the corresponding service,cannot be defined a priori.

In order to make easier run-time composition and interoperability, at least atthe syntactic level, standard interfaces will emerge also in the PA sector. Def-inition of standard interfaces has also positive consequences on the market ofservices. Different developer can decide to provide implementation for definedservices still having the possibility to interact at least at the syntactic level. On theother side run-time composition has important consequences on semantic interop-erability increasing the risk of failure for a running orchestration.


Run-time misbehavior of service orchestrations can have subtle consequencesin preventing real usage of e-Government services. This is related to the impor-tant concept of user (citizen) perceived trust, which results strongly affected whenthe process handles sensitive data in a perceived incorrect way. Particularly dan-gerous are those failures that manifest themselves after that sensitive data havebeen provided. This is clearly the case for interoperability failures when run-timediscovery and binding is permitted. Interoperability failure scenarios lead to frus-trating sensations by the citizen that does not understand if her/his data have beenmodified or not. Even though a good infrastructure usually prevents from reachinginconsistent states, in which for instance the citizen looses the previous residenceand does not acquire the new one, it is certainly probable that the citizen will notuse the electronic service again.

Our proposal as an application of the approach, as described in detail in thenext sections, is to introduce a short interaction trial for dynamically discoveredservices involved in a orchestration scenario, and before the request for sensitivedata to the citizen. During the trial a number of tests will be executed on the dy-namically bound services in order to assess their behavior in the specific scenario.Therefore in case the trial ends with success the orchestration process will con-tinue requesting to the citizen for relevant information. Instead if the trial ends ina negative way the orchestration ends, returning a message to the citizen sayingthat due to technical problems the service is currently not available. For sure theuser will not be happy with this but its perceived trust will not be so much affectedsince no sensitive data have been provided.

6.3 Technical Background

6.3.1 Web Service Composition with BPEL

Integration of services dispersed over the Net, in order to fulfil more complextasks, is certainly the most appealing characteristics of the service-oriented ap-proach and related technologies making real the service-oriented vision.

Service integration can be mainly pursued through two different approaches.The first one foresees the description of the interaction of many services on a peerbasis. Such kind of description, typically referred as choreography, describes theactions that a set of interacting services has to carry on to fulfill a given task.In such a setting involved services interact with each other according to what isspecified for the corresponding role in the choreography. In case one of the partic-ipating service does not stick to the expected behaviour the whole choreographycould fail.

Another paradigm important to service integration foresees the presence of


a service that acts as the coordinator of the integration and invokes the differentservices involved in the integration in order to reach the final goal. In this caseservices are not integrated on a peer basis and relevant interactions, reported inthe orchestration description, are only those referring to communications amongthe orchestrator and the integrated services.

The second approach to integration is certainly the most mature one and themost used in practice. An orchestration can be defined using many different lan-guages, being traditional programming languages one possible choice. Neverthe-less the Web Service-Business Process Execution Language (WS-BPEL, BPELfor short) [4], seems currently to have the greatest chances to become the leadingstandard for orchestrations description. This is a language based on a XML syntaxthat can be used to define orchestration models and that can be directly executedby suitable orchestration engines.

BPEL determines the interactions between web services on the level of mes-sages, process logic and order of interactions. These interactions can involve manyapplications and/or Public Administrations through a business process. BPEL al-lows the description of the sequences with those activities where the interactionof different partners’ business processes. First of all, BPEL is based on XML andthis allows it an easy integration with other XML applications coming from theweb service field. It has a double task: on one side it gives a general descriptionon a business process, on the other side, like a procedural language, it specifiesthe web services call sequences to accomplish a specific task. The first BPELside can be better understood in thinking to the BPEL as a WSDL [20] docu-ment which is conceived for the business processes: in the WSDL, the starting“atomic” elements for the outlining are the messages between the client and theservice, while in the BPEL the atomic elements are the same web services as theyare the partners of complex interactions. The second side of BPEL is nearer theprogramming languages: it gives not only a service outline in the process and itsinteractions with the other partners, but it also specifies which are the input andthe output variables, the synchronous and asynchronous modality of the calling,the preliminary operations sequence and how you can run the exceptions. As al-ready mentioned, in the BPEL terminology a process is made up of the partners’interactions representation together with the activities sequences description: wecan say it is a “static” thing. On the contrary, a process instance is a “dynamic”thing and it is made at run-time in the same moment when a client is going tostart the activity sequence, besides it is made up of the process materializationinto instantiate variables, SOAP messages, etc. Since the BPEL is a descriptionlanguage, in order to execute what has already been said, it needs an “engine” thatcan accomplish the operations. This is the orchestration engine role. A BPELprocess is made up of: (i) the business process partners; (ii) an amount of vari-ables keeping the whole process state; (iii) the activity determining the logic lying


behind the partners’ interaction. Typically a BPEL is tending outside, becauseitself is exposed as a web service. This mechanism shows interesting sides, be-cause when a process is tending outside with a web service interface, it is possibleto outline complex business processes through the making of other simpler pro-cesses as already mentioned, having so modular and scalable systems able to mapperfectly the Public Administration real processes. BPEL shows a group of struc-tured and basic activities as well as the sequence and the conditions necessary totheir elaboration. We can sum up the basic activities as follows:

• Invoke, receive, reply: they refer to the interactions with external web ser-vices;

• Wait: it allows the processes synchronization;

• Assign: it allows copying the data from a variable to another;

• Throw: pointing out the chances of fault;

• Terminate: ending the whole setting;

• Empty: outlining the empty elaboration.

These primitive activities, at their turn can be included into more complex pro-cesses through structured activities. They are able to outline a precise sequence(sequence); they can provide different branching for the process (switch); theycan define a cycle (while), or point out the sequences of the activities that canbe achieved in parallel (flow). The application and control data are available in aGlobal Container. The latter together with the partners are two basic elements intoBPEL. A container identifies the types of the data exchange inside the messages,and it typically coincides with the WSDL messageType of the subjects that areexchanging the data. When a BPEL process gets a message, the suitable containeris filled in order to let its data available for following demands. A partner can be aservice requested by the process or any other service requesting the process. Eachpartner is combined with a specific role inside the process. However it is impor-tant to say that a partner can have a specific role, but it is not possible to combineindissolubly a partner with a role. As a matter of fact a specific partner can havea certain role in a process and a totally different one in another process. The part-ner concept is introduced for defining the web service to invoke. Specifically, thepartnerLink inside the BPEL outline the process refers to the service. It points outthe link to the web service for the composition. Another important element is theoperation element specifying the method to invoke, and the input/output elementsreferring to the sending and the receiving data. With the partnerLink it is possibleto outline a service role into the composed service.


From the testing perspective service orchestration presents important chal-lenges due to the fact that integrated services could belong to different externalorganizations. Moreover, it is possible that services are discovered and boundonly at run-time. On the other side the orchestration provides a model of foreseenservice interactions that could be fruitfully exploited for test cases derivation.

Indeed this is our idea which explore the possibility to use model checkingrelated techniques, on the orchestration description, for test cases derivation.

6.3.2 Model CheckingModel checking [36] is a very effective technique to deal with formal analysisand verification of complex software system specifications. A model checker isable, given an operational model of the system and a property that states spe-cific requirements on the same model, to show if the property actually holds ornot. Moreover in case the property is not satisfied the model checker points to acounterexample that shows a precise model execution that violates the property.

Since its first inception many tools have been proposed and developed, nev-ertheless all of them share the same principle. In particular the system is repre-sented by an operational model defining a system state space and the transitionsamong such states. The property instead is generally specified through a logi-cal formula such as a Linear Temporal Logic (LTL) formula ([38]). Given themodel and the formula the model-checker exhaustively explores all the possiblesystem successive configurations looking for possible violations of the formula.When a violation is detected the model checker reports to the user the sequenceof decisions and actions that it took, during the exploration, to reach the falsifyingconfiguration.

The possibility of exhaustively exploring the state space for a falsifying con-figuration results particularly appealing also for testing purpose. The general ideahere is to derive test cases from counter-examples of negation of expected prop-erties. For instance stating that does not exist a configuration in which a call willbe performed with a given value will result in a counterexample showing how toreach a similar configuration.

Model checking has been demonstrated to be a really powerful approach toverify system properties, nevertheless it generally suffers from the well knownstate-explosion problem, i.e. the number of possibly different system configu-rations can become too big to permit a complete state exploration. The state-explosion problem is particularly relevant when the model is augmented, as it isfor the case considered in this work, with data ranging over wide domains suchas - for instance - integer. To overcome this problem many heuristics have beenproposed in order to avoid the necessity of a complete state space exploration, insome cases giving place to almost-correct approaches.


Research on techniques to reduce the state-explosion phenomenon is a veryrelevant and investigated problem. In general using additional models and takingadditional assumptions different sets of states are merged together. When thestate explosion phenomenon is due to the inclusion of complex data within themodel one possibility is to explore different versions of the same models derivedthrough the selection of specific values for the included complex data. Clearlythe strategy used to select the values strongly affect the quality of the resultingverification phase. As discussed in the following, in our approach the selectionstrategy applies genetic algorithms techniques.

6.3.3 Genetic AlgorithmsGenetic algorithms [57] are a technique that mimics natural-evolution processes tofind approximate or exact solutions in search problems with large solution spaces,and that are not amenable to exhaustive search. The technique borrows conceptsfrom evolutionary biology like inheritance, mutation, selection, and recombina-tion to evolve candidate solutions, represented by a set of chromosomes, towardan acceptable solution for the problem.

A generic genetic algorithm requires the definition of a representation bothof the solution in terms of chromosomes and of a function (fitness function) tobe used to compare the evolving solutions. A fitness function is the objective toreach for a right solution. Therefore, a major issue with this kind of algorithmsis the design of the structure of the solution and of the method for its evaluationusing the fitness function as the objective.

From an initial solution the algorithm proceeds generating new potential so-lutions continuously evaluating them until the fitness function is maximized oranother halting condition is reached. Each new population is generated startingfrom the preceding one combining the various “individuals” and applying geneticoperators. Major issue with this kind of algorithms is the design of the structureof the initial solution and the method for its evaluation using the fitness functionas the objective. Other relevant parameters concern the size of the population, theadmitted recombination techniques, and the individuals mutation rate.

Like other Artificial Intelligence techniques, these kind of algorithms can beapplied to many software engineering fields. Their application as search strategyheuristics for model checking allows the exploration of large state spaces [49]starting from candidate solutions found by the algorithm. Application in softwaretesting instead concerns data generation. In designing test cases is desirable tofind test inputs and test oracles to verify correct behavior of programs. Find testdata may be a time consuming task for developer or an hard task if we deal withlarge domains. Numerous attempts try to overcome these drawbacks automatingthe generation of these kind of data. Well know techniques for this purpose other


than GAs rely on symbolic execution [96], random generation, constraint solving[50], simulated annealing and other [81].

6.4 The ApproachA service orchestration describes the integration of a set of services to providehigher level functionalities. Such a description typically defines a sequence ofdata manipulation and direct invocations to a set of services. Testing can play animportant role, in such a setting, as a mean to verify if a service, to be integratedin the orchestration, actually behaves accordingly to what expected by the orches-trator. This is a particularly difficult topic within the service domain also due tothe fact that services are often run by third party organizations and can also be dis-covered and bound only at run-time. The technique we propose aims at derivingtest cases to assess services to be integrated in a orchestration. Nevertheless wedo not specify a whole testing process which still has to emerge within the servicecommunity. The test cases we define can be used to assess a service off-line oreven on-line, but before the final binding, when suitable support is provided.

Different techniques can be used to derive test cases to test services involvedin an orchestration. As usual the selection of a black-box test case derivationtechnique is strongly related to the modeling techniques used to define participantsbehaviour. Indeed WS standards, such as WSDL, typically convey only syntacticinformation and do not leave much room for the application of testing strategiesexcept for those based on data definition such as partition testing.

In the approach introduced in this chapter we assume that invocations made bythe orchestrator to participant services are annotated with pre and post-conditions.This assumption is inspired to the work of Baresi et al. [6] which use invoca-tion annotations to permit run-time monitoring of participant services. Indeed inthe mentioned work the authors also define a specific language, called WS-CoL,suitable for expressing constraints on services invocations.

Availability of annotations for service participant invocations makes applica-ble contract-based test case derivation strategies. Nevertheless such an approachwould not take into consideration the implications deriving from the integrationof all the other services involved in the orchestration. In particular the presenceof other services could make not possible some invocations specified by the con-straints. Indeed in order to reduce and derive more powerful participant test suitesis important to consider the orchestrator and the other participants also in thederivation of test cases, instead of considering only the model of the single ser-vice. In particular it is our intuition that the best test suites are those composed oftest cases corresponding to execution of the orchestration code involving the great-est number of participants. Main objective of our test case derivation strategy is


to identify this kind of executions and derive from these execution test cases to beused to assess the various participants in isolation. The necessity of having testsuites for participant services strongly connoted with characteristics coming fromthe final environment is a particularly important since, within a service computingdomain, is in general not possible to perform a real integration testing phase. Thefinal application is often integrated only at run-time.

Applying our approach in order to derive a test suite for possibly discoveredservices, the orchestration developer has to put in place various steps. Some ofthese steps can be quite complex and time consuming. Nevertheless they haveto be executed once and for all before the final deployment of the orchestration.Such complexity is justified since it is important to reduce as much as possiblethe number of test cases to be executed. Certainly this contrasts with the idea thatbigger test suites provide a more comprehensive verification. Indeed the effec-tiveness of the approach strongly depends from the definition of a good test caseselection criteria focusing on interoperability issues. In the following subsectionwe discuss the different steps composing the approach thus to provide answers tothe these issues.

6.4.1 Defining BPEL Orchestration for TestingThe approach we propose has important consequences on the structure of the or-chestration specifications, that the developer has to take into account. In particularin order to carry on a testing trial on run-time discovered services it is necessary toorganize information requests, within the orchestration, in a two steps procedure.In the first step the orchestration only asks for information enabling the discoveryand identification of the services to be involved in the interaction. Then all thediscovered services will be submitted to a trial according to the defined test suites.In case no interoperability issues are highlighted the orchestration asks for otherdata. Instead, in case some interoperability threats are identified, the orchestrationreplies saying that the service is currently not available and some action must beperformed to recover the bad situation.

Considering for instance the change of residence example in the e-Governmentsetting, this would mean that the orchestration has to be organized in order tofirstly ask for the coming residence but not for name and other personal infor-mation. Having this information it is possible to identify the service that willparticipate in the orchestration i.e. the municipality to be contacted. Successivelypersonal information will be asked in the second phase and only if the testing trialends with a success.

In our research in the e-Government scenario, we have investigated many citi-zen directed services and for all of them it seems possible to split the informationrequest in a two phase procedure according to our requirement. Nevertheless in


case this would not be possible the orchestration could be organized in more thantwo steps asking in each step the less information as possible.

Nevertheless, our approach is useful also for testing services during their de-velopment allowing the developers to exploit powerful test suites built automati-cally or semi-automatically.

6.4.2 Model Checking BPEL Specifications

Our approach applies a counterexample-based technique that starting from a modeland a property is able to derive a test case from a counterexample for that property.A counterexample provides a trace of events for which the property does not hold.Therefore, if we declare that the property ¬P should hold for the system model,the technique generates, in case it exists, a trace for which P holds.

A BPEL flow is typically data-driven. This can be a big problem for a model-checking technique since it can easily lead to a state-explosion situation. To solvethis problem some approaches remove data from the model and then choose nondeterminism to handle conditional choices within the orchestration. In our workwe use a data generation technique to generate sets of data to drive the modelchecking phase. In this manner we simulate correct interactions between theorchestrator and the external services, given the selected data. To generate theneeded sets of data we apply genetic algorithm approaches as detailed in Section6.4.3.

Test-cases are derived from counter-example generated by the model-checkerwhen reachability properties are specified. In this way we can highlight all thepossible paths that can bring from the start of the BPEL process to any possiblefinal state. The derived paths include the interaction actions among the orchestra-tor and the composed services. For such steps also data are defined according tothose provided by the applied genetic algorithm.

6.4.3 Test Data Generation Criteria

Test data used to drive the state space exploration are generated using a biologi-cally inspired technique implemented as a genetic algorithm. The fitness functionof the genetic algorithm is used to compare different test suites and is tailored onthe concept of interaction adequacy criteria and interaction coverage. We definesuch concept exploiting classical definitions of branch testing, and path testing[93].


Interaction adequacy criteria

Let T be a test suite for a BPEL process P. T satisfies the interaction adequacycriterion for P iff, for each interaction I of P, there exists at least one test case inT that causes execution of I (Where an interaction represents a message exchangebetween the orchestrator and a composite service).

Interaction coverage

The interaction coverage CInteraction of T for P is the fraction of interaction ofprocess P executed by at least one test case in T .

CInteraction =number of executed interactions

number of interactions

T fully satisfies the interaction coverage adequacy criterion if CInteraction = 1

A solution that covers the greatest number of interactions in the process hasthe highest fitness function value. Interactions are counted with their occurrences.So in case the BPEL Process presents loops it is necessary to define limit to thenumber of execution.

Our approach aims to merge the space exploration task with data generationfeatures. This is possible if the model used for the state space generation is ex-pressive enough to support an exploration driven by data. Indeed this is the caseof BPEL processes.

Data generation terminates when generated data covers a specific amount ofinteraction in the model, also respecting eventually reachability properties ex-pressed on the model itself. With respect to other approaches in this manner wecan derive from the model checker traces input data (and oracle if the model fullyspecify participant’s behaviour) observing interactions among the various partici-pants.

6.4.4 Genetic Algorithm Test Data GenerationThe algorithm starts with: (i) an XML Schema Type definition that contains allthe data types used by the services to exchange data, (ii) a WSDL document of theprocess interface used to derive data that can be generated as process inputs, and(iii) an interaction coverage (CInteraction) value to be reached for an optimal statespace exploration. The result we want is a population of datasets that allow stateexploration and data derivation for participant testing.

A dataset is represented as D = {d1, . . . ,dn}. Each di represent a primitive typeof XML Schema or a portion of a complex type and it is used as input parameter


for the BPEL process. Complex types are flattened out to their primitive compo-nents to allow a simple implementation of the genetic operators. The populationof datasets is composed by pop size individuals, P = {D1, . . . ,Dpop size} and itsfitness is evaluated looking at the interaction coverage reached by the datasets asa whole.

Our algorithm allows the evolution of the whole population instead of a singleindividual (a dataset) and we need two fitness function able to compute both theinteraction coverage starting from a dataset Di, and from a population P. We usethe first for the selection phase and the latter as an exit condition for the algorithm.

Initially the algorithm need a starting population to be provided by the orches-tration developer. This implies the generation of several datasets composed ofprimitive types. This can be done using random procedure choosing data from alarge amount of predefined generic data (this may be the case for strings, dates,etc.).

Some data may be known at this stage (for example test data to access adatabase, some identifier needed for a service, . . . ), in this case a new popula-tion should allow some of the better organisms from the current generation tocarry over to the next, unaltered. This strategy is known as elitist selection andcan be implemented inside genetic operators.

After the initial definition the algorithm showed in Algorithm 1 starts calcu-lating the fitness function for the whole population.

If the population does not satisfy the desired coverage the evolution steps willbe performed until a new population of pop size individuals is generated. Thegeneration follows usual genetic procedures as selection, crossover and mutation.

During selection a pair of individuals are selected using the roulette-wheelselection. Each individual is chosen with a probability:

ps =I(Di)

∑i I(Di)

.The algorithm calculate the value Isum = ∑i I(Di) then chooses two random

numbers Rs for s = {1,2} between 0 and Isum. The roulette selection is imple-mented adding together the I(Di) of the solution members one at a time stoppingwhen the sum is greater than Rs. In this manner the last individuals added arethe individual chosen for the next generation. This operation is performed manytimes until pop size individuals are generated.

The generation Pt+1 is obtained from the selected individuals using crossover.Starting from Dt

i = {di,1, . . . ,di,Rs, . . . ,di,n} and Dtj = {d j,1, . . . ,d j,Rs, . . . ,d j,n} the

operator choose a random number Rs between 1 and n and perform a swap be-tween di,x and d j,x for x > Rs to produce Dt+1

i = {di,1, . . . ,di,Rs, . . . ,d j,n} and


Data: (a) XML Schema for types of messages,1

(b) WSDL document of the WS-BPEL process,2

(c) CInteraction we want to reach3

Result: A population P of datasets Di for testing4

Define schema for datasets as D = {d1, . . . ,dn};5

Define a population P0 = {D01, . . . ,D

0pop size};6

Pt ← P0;7

calculate I(Pt);8

while I(Pt) < CInteraction do9

while |Pt+1|< pop size do10

Select Dti and Dt

j from Pt using Selection;11

Generate Dt+1i and Dt+1

j using Crossover;12

Mutate the offspring using Mutation;13

end14

Pt ← Pt+1;15

calculate I(Pt);16

end17

return Pt18

Algorithm 1: Genetic Algorithm for Data generation

Dt+1j = {d j,1, . . . ,d j,Rs, . . . ,di,n}. These two new individuals belong to the new

population.Mutation preserve genetic variation along a population altering with proba-

bility pm a di ∈ Dt+1i preserving its type. The probability of mutation must be

selected to be at a low level because otherwise the new individual would havenothing in common with its parent. Mutation can be performed in different wayson different data types using the same technique used for the generation of primi-tive data for the initial population.

The generated population Pt+1 replace the population Pt and its fitness is eval-uated using the fitness function I(Pt) to determine if the population is suitable fortesting.

The algorithm terminates when the desired CInteraction is obtained. This meansthat the generated data are able to explore the model examining all the suitableinteractions. We can add also a stop condition on the number of generated popu-lation to avoid time consumption in searching optimal data, clearly the CInteractioncovering is not optimal in this case.

Data generated by the algorithmic approach drive the state space explorationthat is integrated with the generation by the fitness function. Fitness is evaluatedlooking at the coverage that the data can induce over the model and can be evaluate


for a single dataset or for the full population. The evaluation is made respect tointeraction coverage against the space state discovered with the population usedin the iteration. A solution that covers the greatest number of interaction in theprocess has the highest fitness function value.

6.4.5 Test Suite Generation

The combined use of model-checking and genetic algorithms techniques permit toderive a set of traces that are characterized by an high coverage of the interactionactions among the BPEL process and the composed services, as discussed in theprevious sections.

Given a selected trace in order to derive test cases for the different servicesinvolved we project the trace, as in Figure 6.1, with its relative data, over the var-ious participants. In this way we can isolate behavior snippets that can be usedfor test purpose. Successively we combine all these pieces in a sequence of invo-cations for a specific orchestration participant. The fact that the traces were de-rived and evaluated taking into account the number of enclosed interaction actionsguarantees that the selected test cases are certainly relevant for what concerns thedetection of interoperability threats.

6.5 Implementation Strategy

The strategy we propose is organised in successive steps and a subset of them haveto be executed more than once until the “best” test suite (according to the definedadequacy criteria) has been identified.

6.5.1 Orchestration Invocations Annotation

First step of the approach is the annotation of the orchestration definition withconstraints for the invocations to participant services. In order to apply the ap-proach these annotations should identify finite sets for the acceptable values. Thislimitation is mainly consequence of the application of a model-checking basedtechnique as discussed in point 3.

To express the constraints we include pre and post-conditions within the BPELspecification. This choice will make easier the transformation of BPEL to javacode as described in the following point.


(a) (b)

(c) (d)

Figure 6.1: (a) Unfolding of the system traces, (b) Example of traces selectedby the property verification with specific data, (c) Some traces isolated from thetree, (d) Trace snippets for a participant (the gray arrows are interactions with thecontext)

6.5.2 From BPEL to Java

The second step of the approach is the transformation of the orchestration defini-tion into a format suitable for model checking processing. We have developed aproof of concept tool that is able to translate a BPEL orchestration into java code.This choice is mainly related to the decision of using the model checker Java PathFinder (JPF). Nevertheless this is not the only possible option. For instance in[11] the authors describe a quite mature tool to transform a BPEL definitions intoBIR code which is the input format for the BOGOR model checker.

6.5.3 Input Data Generation

Once the annotated orchestration has been defined the next step concerns the def-inition of a set of starting values (population) for the parameters defined for the


!a !a !a

?c ?e

!b

?c

!a !b

?d?d?c

!a

?c ?e

!a

?d?d?c

!b

Traces Projections for Service X Corresponding Test Case for Service X

!a

?e

!b

?e

!b

?e

Optimal Traces

!a

?e

!b

?e

!a

?c

!b

?c

!a

?e

!a

?d

!a

?c

!b

?d

Y,Z XO Y,Z XO Y,Z XO Y,Z XO

(a)

(b) (c)

Figure 6.2: From traces to test cases

service exposed by the orchestration. A specific assignment of values for the in-put parameters identifies one possible execution of the orchestration. Therefore aset of assignments identify a set of executions of the orchestration. Some of thisexecution are, from the testing point of view, good and some are not. In our workwe define the quality of an assignment in terms of the service participants inter-actions that the assignment is able to exercise. After that a set of assignments hasbeen evaluated we apply genetic algorithms techniques in order to recombine thevalues in the current population to derive a successive version of the population.The strategy we use for such derivation remove half population and maintains inthe next version of the population those value assignments permitting to reach thegreatest score in terms of covered “orchestration-participants” interactions. The


remaining half population is derived recombining the values of the most promis-ing assignments, i.e. those assignments that individually get the greatest scores.It is worth noting that the initial population has to be directly defined by the or-chestration developer or possibly defined using a random strategy. As it is the rulefor genetic algorithms based strategies the starting population strongly affect thequality of the obtainable results.

6.5.4 Counterexample Identification

Given an initial assignment for the orchestration, the successive step applies acounter-based technique to identify interesting execution to be used for testingpurpose. To carry on this step we suggest to use a model checker providing to itproperties specified in terms of reachability constraints. These properties state thatsome orchestration exit points are not reachable given the defined value assign-ments and constraints on participant services invocations. As a result the model-checker will explore the execution state space and will return possible executions(counter-examples) that indeed are able to reach the defined exit points. Figure6.2(a) graphically reports possible traces for the case of an orchestration (O) in-volving three services (X, Y, Z). An execution trace is constituted by a sequenceof invocations made by the orchestrating service to all the services involved in theorchestration.

We experimented the approach using Java Path Finder (JPF) that is a modelchecker tool that takes as input programs written in java. This tool checks reach-ability by default (i.e. in case you do not provide a property it will check if itis possible to reach an exit point). At the same time JPF solves the constraintsspecified for the invocations looking for a counter-example. So, it will check withall the possible correct outputs.

6.5.5 Trace Evaluation

Once the model checker have identified a trace this has to be evaluated to assessits “quality”. In our approach this is defined in terms of the number of interactionsof the orchestrator with the participant services highlighted by the trace. After thatall the traces derived from a population has been evaluated we can calculate thequality of the whole population. In case the required quality has not been reachedand the number of iteration is lower than a given threshold or the quality did notincrease in the last n iterations, the process goes back to step 3.


6.5.6 From Traces to Test Cases Definition

The final result of the previous steps is a set of execution traces. Objective ofthis step is instead the definition of a test suite for the various participants. To dothis we need to operate a projection on the derived traces. The projection aims atidentifying the interactions of the orchestrator with one specific participant service(the process will be then repeated for each participant). In Figure 6.2(a) we havehighlighted the interactions of the orchestrator with service X. For the sake ofcomprehension we modeled service X with an Input-Output Transition System(IOTS). In particular X accepts messages a and b and can reply with messagesc, d, and e. Nevertheless a constraint defined on the first invocation declares thatafter a first invocation a possible correct answers are only c and e. According tothis and other constraints the model checker will generate a set of traces of whicha subset is shown in Figure 6.2(b). In this figure we can observe that no tracesshow an answer d after invocation a.

From a set of traces we derive then an equal number of projections. At thispoint a test case will be defined as a decision tree derived through a synthesis ofthe different traces. In particular to derive the decision tree we start consideringall the projections starting with the same invocation. Then we recursively add allthe possible interactions shown by any of the defined traces, and we continue untilall the traces reach the end node. Finally in each state in which the tree waits fora message from the service we add a sink state indicating that all the answers nothighlighted by any trace lead to a failure, and then to the identification of a faultin the service under test. Figure 6.2(a) shows the test case that has been derivedapplying the algorithm to the projections in 6.2(b). Executing this test case a testdriver will start sending message a waiting then for an answer from the service.Depending from the observed output the service will follow a different path in thetree. At the same time when more than one message can be sent to the serviceunder test the driver will randomly select one of them.

6.5.7 Participant Test Suite Definition

A test suite for a participant is derived through the application of the algorithmsketched in the previous step to all projections starting with any possible message.The process is also repeated for each participant. Therefore at the end of theprocess a test suite to evaluate each participant will be available.


6.6 Model implementation in JPFOutlined in Figure 6.3 we show the framework we have developed that is able tomanage BPEL process description with the aim to generate a full model check-able with JPF. Several artifacts are generated starting from a BPEL process and itsrelated partner descriptions expressed in WSDL language. Our framework gener-ate:

• A java model for each participant that include a java interface, an emptyimplementation and a java aspect for logging traces. The implementationmust be written according with pre/post conditions and using the JPF classesfor program instrumentation.

• A java class representing the BPEL process. Variables and BPEL activi-ties are replicated with their obvious counterparts in java using conditionalstatement, repetition statement and method invocation.

• A genetic representation for input data of the process. This is used insidethe genetic algorithm to build new generations of data and inside the javarepresentation of the process to consume the data itself.

• A JPF model class using the Model Java Interface mechanism to bridgethe genetic algorithm that runs outside JPF with the BPEL model that runsinside JPF.

• A java main for the overall system that runs JPF on the generated modelusing the data generated by the genetic algorithm.

BPEL

WSDL

Test Suitesfor

Participants

Java Participant Model

Java Process Model

Genetic Representation of Data

JFP Bridge

JFP Model Cheker

BPEL translation

WSDL translation

Test generation

Figure 6.3: Tool for the generation of the Java model for JPF

Generated code is a complete java application that runs JPF on the model. Themodel is checked several time using different data sets. Each input data set impliesthe execution of a certain amount of interactions that can be traced on participants.

Each input data set can contribute to the derivation of test cases for the partic-ipants involved in the composition and contribute to cover a certain amount of the


BPEL process. We must find more data sets such that their contribution consid-ered as a whole can cover the whole BPEL process (at least in theory, but we canstate different stop condition about BPEL coverage).

Stop conditions about coverage guide the genetic algorithm, different inputdata sets are tried to find a better combination of test inputs able to assure a highlevel of coverage on the model. When this coverage is reached and some data setsare chosen the execution of JPF is stopped.

During execution, traces are recorded on each participant with the data used toperform interaction on participants. These traces are the basis to implement testscases because they contains information about the methods called, their parameter,their return values (or their post condition, it depends on the level of the modelapproximation) as well as method ordering that is induced by the participation inthe composition.

Test derivation from these traces is easy and is implemented as an orderedset of invocations used by a java runner. This can be implemented as a TestCasedescription using the XML format of soapUI [41] and using this latter as testengine or as a JUnit [62] tests using a service endpoint to perform invocation onreal web services.

Test suites are build for each participant in a consistent way respect to thescenarios simulated with JPF. This means that, given a complete trace that leadsthe BPEL process to completion, this is used to derive one test case for eachparticipant to be inserted in its relative test suite.

In this manner tests are related each other and their success assure an accurateintegration between participants.

6.7 Examples

6.7.1 A Toy Example of Data Generation

In this section we present an example of data input generation for a simple or-chestration that mimic the calculation of triangle areas. Inputs to the orchestrationare represented by the length of the edges e1,e2,e3. To find the area the simpleformula S = bh/2 is used where b is the length of the base of the triangle, and his its height. The equilateral triangle is an exception because to know its area isenough the formula e2

√3/4 where e is the length of an edge.

To solve the problem the first step in the orchestration is to determine thenature of the triangle. If the triangle is equilateral the determination of the areais straightforward instead if the triangle is isosceles or scalene we must decidewhich edge is considered the base and find the corresponding height. Moreover, anon-equilateral triangle can be right-angled. This simplify the choice for base and


height because these can be represented by the two edges leaving from the rightangle. These two edges can be found easily being the hypotenuse the longest edge.

Three services are used to solve the problem. One service is exploited toclassify the triangle using the lengths of its sides. A triangle can be equilateral,isosceles or scalene. Moreover, a non-equilateral triangle can be right-angled.Another service is used to choose one edge to be consider as the base and tocalculate the height of the triangle from that base. This service is used only ifthe triangle is isosceles or scalene and there is not a right angle. Finally, a thirdservice simply implements a method to calculate the area. This service have amethod with respectively one or two arguments. If only an argument is given theused formula is valid for equilateral triangles, else if two arguments are given theyrepresent the base and the eight. In this case the usual formula applies.

The orchestration starts with e1,e2,e3 as inputs. The first task performed in-quiries the first service to determine the type of the triangle. If it is equilateral thearea is calculated inquiring a method from the service who calculate areas withone arguments. If the triangle is not equilateral, we inquiry the first service toknow if it is right-angled. If it is, we cut of the highest edge and use the remainingedges as base and height, else if the triangle is not right-angle the service whocalculate base and height is invoked. In both cases the method that calculates thearea is invoked with two arguments.

Although the orchestration is very simple the automatic determination of in-puts can lead to the trouble of having three edge that do not shape a triangle.This situation arises when, given three edges, there is an edge that is greater tothe sum of the other two. In this situation there is an exception thrown duringthe determination of the triangle type. Moreover, we must test all the situationsrepresentative of the triangle types we can found included those in which all theservices are involved.

Genetic algorithms generation of data manages quite well this problem be-cause tuple of data are generated to maximize the coverage of the orchestrationi.e. to maximize the number of situations we can encounter handling triangles. Inour example the best coverage we can have is given by three triangle (one equi-lateral, one right-angled, one isosceles or scalene) that considered as a whole cancover all the possible interaction between the involved services.

The genetic algorithm can start for example with the tuple 〈10,8,6〉, 〈10,14,15〉,〈5,10,10〉 but this not assure the best coverage (we have two scalene and oneisosceles but does not consider the right-angle case nor equilateral triangles). Af-ter recombination, possibly in more than one iteration, we can have 〈10,14,15〉,〈5,10,10〉, 〈10,10,10〉 and we have improved the coverage including the equi-lateral case but we have not reached the targeted coverage. It is worth notingthat the scalene and the isosceles cases will be maintained in the population giventhe greater score of this subset. Finally, after some further recombinations we


can have 〈10,14,15〉, 〈10,14,10〉, 〈10,10,10〉 considering all the possible cases.Also in this case in each iteration the equilateral and isosceles triangle will not beremoved.

6.7.2 Exemplifying scenarioIn this section we introduce a case study in the e-Government field to improvetrust using the proposed approach and to better explain it. Direct interferences ofinteroperability issues on service trustworthiness has been explicitely reported in[118]. We consider a composite service that represents the back-end of an on-linepayment of fines for traffic violations.

The system allows the user to list traffic violations issued by a given munici-pality. The user is able to pay a fine on-line (interacting with a payment service)or off-line (via bank transfer). The modality chosen for the payment modify thebehavior of the process affecting the methods that must be invoked to notify thepayment to the municipality. We want to test this service using an adequate testsuite that is expressive enough to cover all possible interactions. For simplicityand to explain our approach we refer to a single test suite for a service, but theaim is to produce test suites for all the services involved in the composition. Thesystem for traffic violations is composed by an orchestration of four services:

• Fiscal Code: given user data it returns the user Italian fiscal code (similar toUS SSN) that is used as unique identifier for the user and the municipalitycode used to identify an Italian municipality;

• Tickets: A service that returns the sanction (here called ticket) for trafficviolation within a given municipality;

• CreditCC: A service that allows the payment via credit card of a ticket;

• CreditBT: A service that allows the payment via bank transfer;

The four services are orchestrated by a BPEL process that handles the interactionbetween the user and the services as depicted in Figure 6.4.


14

56

78

910

141112

13

17St

art

End

2TE

ST

1516

3

Fail

Pre-

test

Ph

ase

Test

Phas

ePo

st-te

st P

hase

1R

eceiv

e A

ctivity

2In

voke A

ctivity

Pic

k A

ctivity a

nd

Choic

e A

ctivity

Repeat A

ctivity

1R

ece

ive

se

tMu

nic

ipa

lity f

rom

th

e a

pp

lica

tio

n

2R

ece

ive

se

lectP

aym

en

t fr

om

th

e a

pp

lica

tio

n

3R

ece

ive

se

tCre

de

ntia

l fo

rm t

he

ap

plic

atio

n

4In

vo

ke

se

tCre

de

ntia

l (o

n t

he

se

rvic

e F

isca

l C

od

e)

5In

vo

ke

ge

tFC

(o

n t

he

se

rvic

e F

isca

l C

od

e)

6In

vo

ke

ge

tMu

nic

ipa

lityC

od

e (

on

th

e s

erv

ice

Fis

ca

l C

od

e)

7In

vo

ke

ge

tTic

ke

tLis

t (o

n t

he

se

rvic

e T

icke

ts)

8O

nM

essa

ge

se

lectT

icke

t fr

om

th

e a

pp

lica

tio

n

9In

voke s

ele

ctT

icket (o

n the s

erv

ice T

ickets

)

10

Invoke g

etP

aym

entInfo

(on the s

erv

ice T

ickets

)

11

Invoke s

etP

aym

entInfo

(on the s

erv

ice C

reditC

C)

12

Invoke p

ay (

on the s

erv

ice C

reditC

C)

13

Invoke s

etP

aym

entB

yC

reditC

ard

(on the s

erv

ice T

ickets

)

14

Invoke s

etP

aym

entInfo

(on the s

erv

ice C

reditB

T)

15

Invoke p

ay (

on the s

erv

ice C

reditB

T)

16

Invoke s

etP

aym

entB

yB

ankT

ranfe

r (o

n the s

erv

ice T

ickets

)

17

Invoke g

etT

icketL

ist (o

n the s

erv

ice T

ickets

)

Figu

re6.

4:Sa

mpl

eB

PEL

Proc

ess


The interface exposed by the process include the methods that external appli-cations can invoke to perform payment of fines. A typical scenario foresees theinvocation of the method setCredential that supply the process with the necessaryinformation about the user, and the invocation of the method setPayment to selectthe modality of payment that will be used in the following interactions.

According to our approach the BPEL orchestration will ask, in a first step, forinformation concerning the municipality (so to identify the Ticket service) and theway of payment (so to identify the Credit service). These information permit tothe orchestrator to identify all the services that will interact at run time in orderto fulfill the task. After the identification the run-time discovered services will besubmitted to a testing trial using the corresponding test suite derived applying theapproach defined in the previous sections.

So for instance in case the user specifies town M and payment via Credit Cardissued by bank B, the orchestration will retrieve a reference to service Ticket ex-posed by M and to service CreditCC exposed by B and will start the trial usingthe test suites defined for the two services. Obviously no trial will be conductedon services of type CreditBT. It is worth noting that no data directly related to theuser have been provided so far.

In case during the trial phase no errors are highlighted, the process continuesasking for personal information such as Fiscal Code. Personal data are then pro-vided to the Fiscal Code service (which is a statically bound service so no testare executed on it). The returned fiscal code is passed to the Ticket service of themunicipality M and a possible list of fines are reported. The used select the fineshe/he wants to pay and credit card detail are then requested and passed to theCredit service provide by B.

On the other side if the trial discover a problem the process terminates sayingthat the service is temporarily unavailable. At this point failure details will belogged and reported to a technical team of the provider for further investigation.

Services considered in this example expose the following sets of operations,each one has its set of input and output data:

OFC = {setCredentialFC,getFCFC,getMunicipalityCodeFC};OTickets = {getTicketsListT ,selecTicketsT ,getPaymentIn f oT ,

setPaymentByCreditCardT ,setPaymentByBankTrans f erT};OCreditCC = {setPaymentIn f oCC, payCC};OCreditBT = {setPaymentIn f oBT , payBT}

Each operation name is labeled with a reference to the service it belong to andif we consider the set I we can found the same operation along with the type ofinteraction (re, i, rc which respectively stands for reply, invoke, and receive) usedby the BPEL process.


I = {〈setCredentialBPEL,rc〉〈selectTicketBPEL,rc〉〈setMunicipalityBPEL,rc〉〈selectPaymentBPEL,rc〉〈setCredentialFC, i〉〈getFCFC, i〉〈getMunicipalityCodeFC, i〉〈getTicketListT , i〉〈getPaymentIn f oT , i〉〈setPaymentByCreditCardT , i〉〈selectTicketsT , i〉〈setPaymentByBankTrans f erT , i〉〈setPaymentIn f oCC, i〉〈payCC, i〉〈setPaymentIn f oBT , i〉〈payBT , i〉}

The interactions marked with receive represent the inputs of the BPEL processand are used to identify process inputs and to build datasets used in the populationof the genetic algorithm. Instead, interactions marked invoke represent messageexchange between the BPEL process and the other services. These are used intraces to isolate system executions that can be projected over single participants.

The set I with the ordering imposed by the control constructs in the BPELprocess and analized by the JPF model checker with data-driven choises, bring tothe trace:

π = {setCredentialFC,getFCFC,getMunicipalityCodeFC,getTicketListT ,selectTicketsT ,getPaymentIn f oT ,setPaymentIn f oCC, payCC,setPaymentByCreditCardCC,getTicketListT ,selectTicketsT ,getPaymentIn f oT ,setPaymentIn f oCC, payCC,setPaymentByCreditCardCC,getTicketListT}

This trace can be projected to determine the tests to be executed on the in-volved services. This trace, representing the payment of two fines via credit card,is useful to derive test cases to verify if the involved services are able to performmore than one fine payment within the same transaction. πT shows the corre-sponding trace snippet:

πT = getTicketListT ,selectTicketsT ,getPaymentIn f oT ,getTicketListT ,selectTicketsT ,getPaymentIn f oT ,getTicketListT

Each invocation in πT carry its data as they compare in the whole trace π . Foreach invoke a set of ordered SOAP request is built to create a test case for serviceTickets which success assure the capabily for the service to perform more thanone fine payment. This test case along other created for the service Tickets willconstitute its test suite.


6.8 Related WorksDesigning test cases manually is a tedious, time-consuming and error-prone task.To overcome these drawbacks automated testing frameworks are developed toproduce, organize, and execute tests on software during the development phase.

Some interesting approaches dealing with web services and verification tech-nique were developed, for example [45] and [73] but, although testing is a veryimportant stuff developers need to perform to produce robust software, there area lack in testing generation frameworks for service-oriented languages such asBPEL.

Some guidelines and a real implementation called BPELUnit are given in [77].BPELUnit is a XML-based test framework for BPEL composition that works witha custom language for test specifications and provide a java test runner that canbe extended to support multiple engines (such as Active BPEL and Oracle BPELServer). The framework is usable by developer inside an IDE, and on the serverside to reinforce deployment of compositions.

In [120] the authors propose a model checking approach based on SPIN andNuSMV model checker and relying on a Web Service Automata (WSA) back-ground that models service composition using a custom made automata structure.BPEL composition are translated to the language used by SPIN (or NuSMV) toconform to the WSA model. Trap properties expressed as LTL formula are usedto isolate system behaviour and to produce traces from which test case derivationis performed. The same authors in [119] perform data analysis on BPEL flowmodeling internal, external and global data exchanges in BPEL compositions.

Due to some similarity of the service-oriented paradigm and the objected ori-ented one [40] we found interesting build java service model like mock objects[71] to mimic the behaviour of the real system like the approach in [68].

Derivation of test cases from counterexamples has been firstly proposed by [3]in which model checking is applied to the problem of test generation combinedwith mutation analysis at the level of the model checker specification. Verificationof web services by model checking is investigated from the general case [59]where the BLAST model checker is extended to handle concurrency. Analysis andverification techniques specifically for BPEL orchestrations have been proposedin [44] and [108]. Nevertheless in all these cases the verification phase aims atshowing properties of the whole orchestration, rather than to check compliance ofBPEL participants.

In [89], Offutt and Xu propose a framework for generating test cases to checkweb services behavior. The derivation of input data is in this case solved applyingdata perturbation techniques on previously observed messages. To apply the tech-nique for our purpose it would be necessary to observe and trust a first interaction.

An interesting survey of search based techniques to data generation for test-


ing can be found in [80] which shows several approaches including the geneticalgorithm one. Genetic algorithms (GA) are global search-based strategy that hasbeen proved suitable for software testing [61] used in several works [23] [111][110]. A GA-based system for dynamic test data generation is described in [79]where the problem of test data generation is reduced to the one of minimizing afunction. Other interesting approaches, but in the object oriented field, also dealwith genetic algorithms [107] providing automatic production of test cases for theunit testing of classes in a generic usage scenario.

A discussion on combining model-checking and genetic algorithms can befound in [49], where a framework for exploring very large state spaces is pre-sented.

6.9 ConsiderationsService Oriented Architecture and web services are emerging disciplines and tech-nologies that promise to revolutionize the way in which organizations will interact.As for any new domain is necessary to reconsider all the development activities tounderstand which are the new opportunities and the new challenges. This is cer-tainly true also for testing activities. In this chapter we proposed a novel approachto testing of those services to be integrated by a service orchestrator. Defining theapproach we tried to take advantage from the higher availability of formal modelsand standard formats. At the same time we tried to identify which one could bethe most promising test suite to be executed on a service participant. Our intuitionis that the best test suites could be derived from those executions that show thegreatest number of run-time interactions among the integrated services and theorchestrator.

The discussed approach combine model checking and genetic algorithms tech-niques in order to identify the execution traces to be used for test cases derivation.The combination of this two techniques permits to reduce the risk of the occur-rence of the state-explosion phenomenon. The approach is certainly time consum-ing given that model checking have to be executed many times. Nevertheless theprocess has to be executed only once given an orchestration.

The research is certainly still on going and the approach has to be validatedon bigger and more realistic case studies, nevertheless some encouraging resultshave been already obtained on some small examples, in particular within the e-Government domain. Particularly critical seems the validation of our intuitionthat suggests to search for test cases within those executions showing the greatestnumber of interactions. If this assumption could seem reasonable it is necessary tovalidate it with a more systematic study aiming at comparing different technique.

As an application the e-Government field, we use testing to improve trust on


services. Citizen trust is a major requirement for real take-off of e-Governmentprocedures. SOA promises to revolutionize the way in which services will beprovided to citizens permitting to easily integrate different PA organizations in adynamic and transparent way. Nevertheless dynamic discovery of services canincrease the risk of failure of composite services with strong consequences oncitizen trust. We propose an approach to reduce the risk or run-time failure dueto interoperability issues and after that sensible data have been provided by thecitizen. Doing so consequences of failures on citizen trust should be much lessimpacting.

The framework have been experimented with some exemplifying scenarios,providing comforting results. In the future we intend to continue the experimen-tation, also in order to compare the suggested test-case derivation techniques withother model based approaches discussed in the literature. Also the real impact onconsequences of citizen trust need to be empirically evaluated.

Chapter 7Verification of WS-CDLChoreographies using SPIN

In this chapter we report an approach to formal verification of service choreogra-phies by means of model checking. The aim is to show how a choreography canbe verified using existing techniques that can be extended or adapted to deal withnew problems arising in the web service world. This work were presented to[CDP07].

7.1 Introduction

In recent years, the need of distributed applications able to support informationsystems has driven the development of new technology for the vision of the Ser-vice Oriented Computing. The promise of this is to provide an architectural ap-proach in which loosely coupled services can be designed, implemented, and de-ployed to users that can use them, and compose them, to build applications. More-over, using services in several context allows reuse of software and reduction ofcosts.

Services are dynamic discoverable software artifacts available on the networkthat must support interoperability between heterogeneous applications. Currently,the vision of Service Oriented Computing is implemented with the web servicetechnology that rely on WSDL [20], SOAP [52], UDDI [8], WS-BPEL [4], WS-CDL [63] and many other WS-* standard.

To design a service-oriented distributed applications two major models can beused [7]. An orchestration model foresees a single point of control (an engine) forthe execution of the activities that must be performed by the services involved inthe application. An orchestration is expressed using WS-BPEL and represent an

112 CHAPTER 7. VERIFICATION OF CHOREOGRAPHIES

executable process that can be executed by the engine. From another perspectivea choreography model describes a collaboration between a collection of servicesin order to achieve a common goal. It does not describe internal action of par-ticipants but only the external behavior in terms of exchanged messages. Theinteractions expressed in WS-CDL are described from a global or neutral pointof view. Moreover, a choreography doesn’t have a central point of control and isintended for design purpose. Starting form a choreography is possible to build theservices needed for the application and realize a workflow of activities that can beexecuted in an orchestration fashion.

In the context of service cooperation is an important matter to deal with ver-ification and validation, moreover, the needs of models specification is very im-portant to show how different services can interact each other using messagesexchange. Indeed, like any other software application composed by processes,or components, or objects, and so on; an application build from services needsa level of dependability that cannot be ensured with approaches that lacks of aformal verification. Although, available existing techniques can be extended oradapted to deal with new problems arising in the web service world.

Model checking [36] can be used for the validation and verification of serviceoriented applications. A model checker is able, given a model of a service com-position and a property, to show if the property holds for the given model. If theproperty is not satisfied the model checker reports a counterexample that showsthe execution that doesn’t satisfy the property allowing the designer to correct it.Model checking foresees models that must be built with the specific language usedby the model checker to represent software systems, but software model checkingtry to extend this concept to the verification of already build software system usingsource code as model. This allow the verification of property for a real system,and not for a model of it, but this is a technique that can be used in an advantagestage of development because foresees the availability of the application sourcecode.

In this chapter we propose a technique to model check web services choreog-raphy expressed using the WS-CDL language. WS-CDL is not executable codebut it is used to generate service’s code skeleton and to drive the development ofworkflow of activities that the application must perform. For this, we use WS-CDL as model for the verification and we realize a translation of this model to aPROMELA model used by the model checker SPIN to verify properties [58].

7.2 WS-CDL OverviewWS-CDL [63] (Web Service Choreography Description Language) is an XML-based language for specify choreography models that describe collaborations be-

CHAPTER 7. VERIFICATION OF CHOREOGRAPHIES 113

tween a collection of services that interact each other to achieve a goal. Eachparty involved wishes to remain autonomous and no party drive the interactionsbecause there is not a centralization point of control. A choreography does notdescribe internal action of participants but concern only with externally visibleeffects capturing them from a global perspective.

The language provide a common and sharable means to describe how webservices described by WSDL can be used to achieve goals that require cooperationbetween parts. WS-CDL descriptions can be used to generate code skeletons forweb services or BPEL abstract processes because they are design-level artifactsthat are not intended to be directly executed.

A WS-CDL choreography is contained in a package that supply a container forcollections of activities performed by the involved web services. Three types ofactivities characterize WS-CDL: control-flow activities, WorkUnit activities, andbasic activities.

In the first category there are Sequence, Parallel and Choice that can enclosea number of sub-activities. Sequence, clearly, describes sequential executions;Parallel describes one or more activities that can be executed in any order or at thesame time; while Choice represents the execution of one activity among a set ofalternatives.

The second type, WorkUnit, describes a possible and conditional repetition ofan activity supplying a means to capture structured loops. A WorkUnit has a guardcondition and a repetition condition: the execution starts with the evaluation of theguard; if this evaluate to true, the activity is executed then the repetition conditionis evaluated. If this condition is true the activity is executed again and so on.

Basic activities includes Interaction, Noaction, SilentAction Assign and Per-form. NoAction and SilentAction respectively refers to the execution of no actionsor to actions behind the scenes that do not affect the rest of the choreography. As-sign is used to transfer values to a variable to another, while Perform is used to callanother choreography that may be defined within the same package as the calleror in a different one that has been imported.

Interaction is the most important activity because describes the messages ex-change between web services with a focus on the receiver of the information. In-teraction can make a request, make a response (respond), or a request that requiresa response (request-respond). Three main parts are involved in an interaction: (i)the participants; (ii) the exchanged message; and (iii) the channel used to transferinformation. In this context interactions refer to the operations performed wheninformation is received by the receiver.

The language foresees the notion of channel. A channel is associated withone of three actions: request, respond, or request-respond and is used to considerinformation exchange among different services. They represent the link betweenWS-CDL and operations in WSDL because every behavior in a choreography has


a corresponding channel type and this relation is one-to-one since each channeltype variable correspond to one behaviour. Moreover, channels are able to passother channel variables.

Moreover, a choreography description represents a container for top-level ac-tivities and for optional exception and finalizer work units. A package can containone or more WS-CDL choreography and is used to collect information common toall the choreographies contained in the package. Inside the package we can foundRoleTypes that exhibit Behaviors and RelathionshipTypes between two roleTypes.A role has at least one behavior while a participant plays a particular set of roles.

One the main requirement for WS-CDL it to provide techniques and tools tovalidate conformance of choreography description ensuring interoperability be-tween services. For this, WS-CDL is based on formal languages related to pi-Calculus [84] and to the structured communication-centred programming for webservices [17]. This enable design time or static validation and verification to en-sure correctness properties such as livelock, deadlock, etc. Moreover, runtimemonitoring can be useful to prove that the participants behaviour conforms to thechoreography model.

7.3 PROMELA and SPINSPIN is a state-of-the-art model checker based on automatons and developed byG.J Holzmann [58]. SPIN allows simulation and verification of models written inPROMELA (Process Meta-Language) that are composed by a set of communicat-ing processes that exchange messages along channels.

SPIN use PROMELA models to generate an optimized on-the-fly verificationprogram to verify properties expressed as Linear Temporal Logic (LTL) formulas.The generated C code is compiled and executed to perform the verification andif errors are detected it generates a counterexample that can be used in a SPINsimulation to determine the cause of violation of correctness requirements.

PROMELA is a system description language and its focus is on modelingprocess synchronization and coordination and not computation. Its target is onconcurrent software system and the building block that it use are asynchronousprocesses, buffered and unbuffered message channels, synchronization statementsand structured data.

Indeed, a PROMELA process is a finite state automaton described by basicstatements (assignments, assertions, print, send or receive and expressions) andby other elements that are used only to specify the control flow in the process exe-cution. Processes exchange messages using channels: a message is an ordered setof variables while a channel is a buffer with a fixed capacity that can be written andread by processes. A channel with buffer capacity of zero induce a synchronous


communication forcing processes to synchronize on message exchange. More-over, there is the possibility to choice between two semantics that can have a wideimpact on the model: one that blocks new messages when a channel is full andanother one that loses new messages.

For its maturity an potentiality SPIN is a widely used model checker usedin various application domain and several approaches for the verification of webservices compositions, included the one presented here, are based on it.

7.4 Related WorksFormal verification for web services is an important area of research that is attract-ing considerable attention because there is today an increasing adoption of ServiceOriented Architecture developed with the web services technology. Several exist-ing approaches discuss model checking composition of web service starting forma composition model described by some languages.

The majority of the approaches take into consideration WS-BPEL and typ-ically uses as model checker SPIN or consider the composition modeled by aprocess algebra using apposite tools to perform the verification tasks.

A first attempt to verification of web service composition is described in [86]that propose an approach to verify web service flows specified using WSFL (WebService Flow language). The approach use software model checking techniquesadapting WSFL to a PROMELA model to use the SPIN model checker. Severaltranslation template from WSFL to PROMELA and a mechanism to handle deathpath elimination are provided.

Other approaches take into consideration the WS-BPEL specification. In [45]and [46] is proposed a tool able to translate WS-BPEL into an intermediate rep-resentation based on automaton that use guards expressed in XPath [22]. Thisrepresentation, with a set of synchronizability conditions, allows to restrict theanalysis to a composite service using a synchronous semantic and allowing theuse of LTL formulas for the verification. Moreover, some realizability conditionallow the definition of a single automatons that represents the desired global be-havior of the composition. An algorithm for the translation from the intermediaterepresentation to PROMELA is also provided.

A different approach is used in [100] in which a semantic for WS-BPEL isgiven in term of Petri Nets [92]. The semantic consists of a set of patterns thatrepresents place bounded Petri Nets for each BPEL activity. To specify relevantcorrectness criteria they use the capabilities of the alternating temporal logics.

Finally, process algebras are used in [44] and in [66]. In the first web servicecomposition are modeled in UML using Message Sequence Charts then compiledin a Finite State Process notation used for the verification through the LTSA tools


[72]. Instead, in [66] is introduced the BPE-calculus to capture the control flowof BPEL and to use the concurrency workbench (CWB) [24] as a tool to analyzeweb service workflows. The CWB is usable thanks to a process algebra com-piler that build an appropriate front-end for it. With CWB, is possible to performequivalence checking, preorder checking and model checking.

A model checking approach that considers OWL-S [76] as a description forservice flows is showed in [59]. The approach is based on BLAST [56], a modelchecker that handles control flow models naturally and that has been extended tohandle the control flows construct of OWL-S. The test cases for the verificationare managed using PDDL [48] as language to specify logical formulas.

The work in [64] describes composition of web service using an asynchronouscommunications model instead of a synchronous one that is classically used inverification. Using this approach, that augment State Transition System withchannels and buffers to handle messages, is possible to associate the adequatemodel to every composition. The adequate model is the simplest model that cap-ture all the behaviors of the composition and can be used to improve verificationtechniques using the SPIN and NuSMV [21] model checkers.

7.5 A Simple Use Case

To explain the mapping from WS-CDL to PROMELA we use a little example ofa service choreography. We show the system using an UML sequence diagram inFigure 7.1.

There are four participants, each one is implemented as a web service, that arerepresented with four roleType: a Buyer, a Seller, a CreditChecker and a Shipper.The Buyer starts the interactions requesting a quote to the Seller. After that theseller has replied, the Buyer can accept the quote or can starts a bartering withthe Seller using messages to update the proposed quote. When the Buyer acceptsthe quote sends two messages to the seller: one carries the accepted quote and theother carries the channel that can be used for the communication with the Buyerthem-self. The Seller checks the credit card information to the CreditCheckerand, if this operation is successful, forward the channel to the shipper with allthe details to complete the delivery. Now, the Shipper has a channel to directlycommunicate to the Buyer and can send it the right information for the delivery.Clearly, if the CheckCredit doesn’t return a right credit information to the Sellerthe Buyer cannot complete the purchase.


Buyer Seller ShipperCreditChecker

RequestForQuote

Quote

UpdateQuote

QuoteAccept

QuoteAccept

SendChannel

CheckCredit

CreditAccept

DeliveryDetails

CreditReject

CreditReject

RequestDelivery

DeliveryDetails

ForwardChannel

loop

alt

Figure 7.1: Sequence diagram of the choreography example

7.6 WS-CDL to PROMELA Translation

The translation from WS-CDL to PROMELA foresees the identification of theactors of the system modeled by web services and that can be mapped as processesin PROMELA. For each participantType in WS-CDL a process is built withthe name used in the attribute name. Moreover a label end processname isused to mark the initial state as can be viewed in Figure 7.2. This expedient is usedto prevent a system deadlock if a process is never called. This can happen - as inthe example - when a web service/process is not involved in the choreographybecause something prevent this. (In the example the Shipper isn’t used if theCreditChecker returns a CreditReject message to the Seller). Thisis realistic because represents a web service that is waiting for a request, and itcan be in that state also when the choreography will be complete and it had notparticipated.

Each channel variable defined in the choreography become a channel variablein PROMELA. In the mapping each channel can carry two int, the first representthe action invoked and the second is a constant that represents the type of the


<participantTypename="Shipper"><roleTypetypeRef="ShipperRoleType"/>

</participantType>

proctype Shipper(){end_shipper:/** ...PROMELA statements...

*/}

Figure 7.2: WS-CDL to PROMELA processes translation

message exchanged by the processes. To do this, for each action and for eachmessage type a constant is defined.

<variableDefinitions><variablename="Buyer2SellerC"channelType="Buyer2SellerChannelType"/>

<variablename="Seller2ShipperC"channelType="Seller2ShipperChannelType"/>

<variablename="Seller2CreditChkC"channelType="Seller2CreditCheckChannelType"/>

<variablename="DeliveryDetailsC"channelType="toBuyerChannelType"/>

...</variableDefinitions>

chan BuyerToSellerC =[0] of {int, int}

chan SellerToShipperC =[0] of {int, int}

chan SellerToCreditChkC =[0] of {int, int}

/* channels to send other channels */chan BuyerToSellerCC =[0] of {int, chan}

chan SellerToShipperCC =[0] of {int, chan}

Figure 7.3: WS-CDL to PROMELA variables translation

About channels, there is the necessity to make a distinction between chan-nels used to send, and receive, data and channels used to channel passing. If achannel can be used to channel passing it can be translated into two channels inPROMELA. One for data ({int, int}) and one for sending other channels({int, chan}). The distinction is made looking at the channelType thatshows which channels are used to pass other channels and which is the type of thepassed channel. Variables that has this latter channelType are not translatedinto global channels because this will be local to the process that sends it for first.

In the example of Figure 7.3 the variable DeliveryDetails is not trans-lated because its channelType (toBuyerChannelType) is used in the defi-nition of BuyerToSellerChannelType and Seller2ShipperChannelType


to show that these latter can be pass a channel of that kind. Indeed, two channels({int, chan}) for channel passing that refer to them are built.

Each activity is mapped looking at several information that are present insidethe interaction tag: (i) relationshipType, fromRoleTypeRef andtoRoleTypeRef; (ii) channelVariable; (iii) exchange name, informationTypeand action. The relationshipType is used to identify the processes in-volved in the interaction. Using the fromRoleTypeRef value (resp. toRoleTypeRef),and looking to participantType definitions, it is possible the identificationof the name of the participantType with the given role. This was usedto name a process in PROMELA and it is the process that starts the interactionsending the message (resp. the process that receive the message). The messagefor the sending process is built as: channelVariable! exchange name,informationType while the message for the receiving process is the comple-mentary one obtained using “?” instead of “!”.

Continuing with the translation, in the Figure 7.4 there is an example of arequest-response interaction between the Buyer and the Seller. This is aninteraction that foresees a response after a request, both mapped using a pair ofcomplementary statements in PROMELA. The action attribute shows if themessage is a send message or a receive message from the perspective of thefromRoleTypeRef role. If action is “request” then the message startsfrom the fromRoleTypeRef while if it is “respond” the message is sent bythe ToRoleTypeRef. This is necessary because in WS-CDL there are threekinds of interactions that respectively foresee only a request, only a response or- as in the example - a request-response. This seems misleading but the ”From”and ”To” suffixes of RoleTypeRef refers to the relationshipType andnot to the interaction itself.

The mapping of sequence is straightforward because relies on the sequenceof statements in PROMELA. The choice and the repetitions (modeled withworkunit in WS-CDL) are more complex because the global behavior of a par-ticipant must be projected locally to PROMELA processes. While this is simplefor a single interaction activity that use complementary PROMELA statements,for a choice there is the necessity of an if statement in each PROMELA pro-cess involved in the choice. Same considerations apply to repetitions that requirea do statement for each involved process. Then, the content of the if (resp. do)is constituted of complementary statements performed in the choice (resp. inthe repetition).

For example, when the Seller performs the interaction with name CheckCredit,the CreditChecker can respond with a CheckOk or with a CheckFailmes-sage. This imply a choice in WS-CDL and an if in PROMELA, both for theSeller and the CreditCheker as is showed in Figure 7.5.

The parallel construct is a little bit different. When in the choreography


<interaction name="BuyerRequestsQuote"channelVariable="Buyer2SellerC"operation="requestForQuote"initiate="true"><participaterelationshipType="BuyerSeller"fromRoleTypeRef="BuyerRoleType"toRoleTypeRef="SellerRoleType"/>

<exchange name="request"informationType=

"RequestForQuoteType"action="request"><send/><receive/>

</exchange><exchange name="response"informationType="QuoteType"action="respond"><send/><receive/>

</exchange></interaction>

/* the Buyer process... */BuyerToSellerC!REQUEST,

RequestforQuoteType;BuyerToSellerC?RESPONSE,

QuoteType;

/* the Seller process... */BuyerToSellerC?REQUEST,

RequestforQuoteType;BuyerToSellerC!RESPONSE,

QuoteType;

Figure 7.4: WS-CDL to PROMELA activities translation

<choice> <sequence><interaction name="CheckFails"channelVariable="Seller2CreditChkC"operation="creditCheck"><participate ... /><exchange name="checkCreditFails"informationType=

"CreditRejectType"action="respond"><send/> <receive/></exchange>

</interaction>...notify the Buyer...

</sequence> <sequence><interaction name="CheckOk"channelVariable=

"Seller2CreditChkC"operation="creditCheck"><participate ... /><exchange name="checkCreditPasses"informationType=

"CreditAcceptType"action="respond"><send/> <receive/></exchange>

</interaction>... interaction to delivery...

</sequence> </choice>

/* CreditChecker */if

::SellerToCreditChkC!CREDITCHECKFAILS,CreditRejectType->skip;

::SellerToCreditChkC!CREDITCHECKPASSES,CreditAcceptType;->skip;

/** In both cases the

* execution ends

*/fi;

/* Seller */if

::SellerToCreditChkC?CREDITCHECKFAILS,CreditRejectType->

/** ...notify the Buyer

* about the fail...

*/

::SellerToCreditChkC?CREDITCHECKPASSES,CreditAcceptType ->

/* interaction to delivery */fi;

Figure 7.5: WS-CDL to PROMELA choice translation


there is a parallel construct the processes in the PROMELA model must instantiateone subprocess for each parallel activity.

Each process must handle its ”part” of parallel activities. Supposing that a par-ticipant must handle two parallel activities, it must instantiate two subprocessesthat synchronize on a specific channel created by the participant. While the com-plementary actions can be performed by other processes in the usually fashion.For example in Figure 7.6 is showed a synchronization between two processes,subprocess1 and subprocess2, controlled using the local channel syncro.

proctype Process(){/* do something... */chan syncro = [2] of {int}/* for 2 activities */run subprocess1(syncro);run subprocess2(syncro);do::full(syncro)->break;od;/* do something else... */}

}

Figure 7.6: WS-CDL to PROMELA parallel translation

If we consider the WS-CDL code in Figure 7.7 we can note that the BuyerRoleand the SellerRole must instantiate two subprocesses each one reproducing aparallel activity described in WS-CDL. But, because the participant involved canbe different, one participant can instantiate subprocesses that interact with otherprocesses that are already in concurrent execution without that them need the in-stantiation of other subprocesses. This happen when the fromRoleTypeRefis the same for the parallel activities but the toRoleTypeRef is different forthem.

This translation applied to a WS-CDL choreography is able to build a PROMELAmodel suitable for SPIN verification. In this chapter we apply this translation tothe simple scenario of Buyer-Seller to perform its verification.

7.7 Checking the model using SPINThe complete system models the simple use case showed previously applying themapping presented in this work to a WS-CDL description.

In Figure 7.8 we presents the constant used in the processes of the model.Processes Shipper, Buyer, Seller and CreditChecker are presented respectively inFigure 7.9, Figure 7.10, Figure 7.11, Figure 7.12; each one represents a participant


<parallel><interaction channelVariable="tns:channel1"name="UpdateQuote1" operation="updateQuote1"><participate fromRoleTypeRef="tns:BuyerRole"

relationshipType="tns:BuyerSellerRelationship"toRoleTypeRef="tns:SellerRole"/>

<exchange action="request"informationType="tns:UpdateQuote"name="updatedQuoteReq1">

<send/> <receive/></exchange><exchange action="respond"

informationType="tns:UpdateQuote"name="updatedQuoteResp1">

<send/> <receive/></exchange>

</interaction><interaction channelVariable="tns:channel1"name="UpdateQuote2" operation="updateQuote2"><participate fromRoleTypeRef="tns:BuyerRole"

relationshipType="tns:BuyerSellerRelationship"toRoleTypeRef="tns:SellerRole"/>

<exchange action="request"informationType="tns:UpdateQuote"name="updatedQuoteReq2">

<send/> <receive/></exchange><exchange action="respond"

informationType="tns:UpdateQuote"name="updatedQuoteResp2">

<send/> <receive/></exchange>

</interaction></parallel>

Figure 7.7: Parallel interactions in WS-CDL


involved in the choreography. Messages are modeled as integer constants thatsimulate the exchange of messages between the participant. Three global channelsare declared to carry the information and two global channels are used to allowschannel exchange among participants as we explain in a preceding section.

The SPIN model checker is the used to test the system showing possible prob-lems that can arise in this composition scenario. Naturally, this simple use casedoesn’t present problems but helps to understand the importance of software ver-ification on web service composition expressed with the WS-CDL language.

In fact, using SPIN we can perform a verification and a simulation of the inter-action between the participants. The verification exhaustively checks the systemfor deadlocks while the simulation simulate a random execution of the systemor an interactive execution driven by users choices. Clearly, a correct simulationcannot assure that the system behavior is correct because it is referred only to onepossible execution path but it is useful to see how the system works.

Figure 7.13 reports the output of SPIN when performs verification. We useSPIN version 4.2.9 on a Mac with a PowerPC G4 at 1.42 GHz and 1 GB of RAMrunning Mac OS X 10.4.8. SPIN takes the PROMELA model then builds and runthe verifier that takes less of 3 Mb of memory for the verification. The verifiercheck for deadlock and for invalid end states using a model that include, usingpartial order reduction, 22 state and 23 transitions.

Moreover, in Figure 7.14 there is a message sequence chart generated by aSPIN simulation. You can see that the simulated behavior looks like the sequencediagram presented in Figure 7.1 that graphically represents the choreography. Wehave rebuilt the system behavior in a PROMELA model starting from the chore-ography expressed in WS-CDL language using our translation technique.

7.8 ConsiderationsIn this chapter we report a first attempt to formal verification of web service com-position expressed using the WS-CDL language by means of the SPIN modelchecker.

WS-CDL is an emergent proposal for the description of web service compo-sitions using a neutral viewpoint focused on message exchange among involvedparties (web services). It is a non-executable artifact that enable the generationof code skeleton to facilitate the development of distributed application based onweb services. One of its requirements is the verification, validation and runtimemonitoring of the described systems.

Our approach foresees a design-time analysis using the well know ad widelyused model checker SPIN that allows deadlock detection, invalid end state detec-tion and verification of safety and liveness properties expressed using LTL. We an-


/** Constants

*/

/* Messages are modeled as constants... */

#define FALSE 0#define TRUE 1

#define REQUEST 11#define RequestforQuoteType 12#define RESPONSE 13#define QuoteType 14

#define ACCEPTQUOTE 21#define QuoteAcceptType 22

#define SENDCHANNEL 31

#define REQUESTNEWPRICE 41#define UpdateQuoteType 42#define ACCEPTUPDATEQUOTE 43

#define CHECKCREDIT 51#define CheckCreditType 52

#define CREDITCHECKFAILS 61#define CreditRejectType 62

#define CREDITCHECKPASSES 71#define CreditAcceptType 72

#define SELLERREQUESTDELIVERY 81#define RequestDeliveryType 82#define SELLERRETURNDELIVERY 83#define DeliveryDetailsType 84

#define FORWARDCHANNEL 91#define SENDDELIVERYDETAILS 92

/** Global channels

*/

chan BuyerToSellerC = [0] of {int, int}chan SellerToShipperC = [0] of {int, int}chan SellerToCreditChkC = [0] of {int, int}

/* channels to send other channels */chan BuyerToSellerCC = [0] of {int, chan}chan SellerToShipperCC = [0] of {int, chan}

Figure 7.8: Constants and channels declared in the PROMELA model


/** Processes

*/

proctype Shipper(){chan DeliveryDetailsC;end_shipper:SellerToShipperC?SELLERREQUESTDELIVERY,

RequestDeliveryType;SellerToShipperC!SELLERRETURNDELIVERY,

DeliveryDetailsType;SellerToShipperCC?FORWARDCHANNEL,

DeliveryDetailsC;DeliveryDetailsC!SENDDELIVERYDETAILS,

DeliveryDetailsType} /* end process Shipper */

Figure 7.9: Shipper definition in the PROMELA model

/** Processes

*/

proctype Buyer(){chan DeliveryDetailsC = [0] of {int, int};end_buyer1:BuyerToSellerC!REQUEST, RequestforQuoteType;BuyerToSellerC?RESPONSE, QuoteType;do::BuyerToSellerC!ACCEPTQUOTE, QuoteAcceptType;BuyerToSellerCC!SENDCHANNEL, DeliveryDetailsC;break;

/*::skip; NoBartening, do nothing*/::BuyerToSellerC!REQUESTNEWPRICE, UpdateQuoteType;BuyerToSellerC?ACCEPTUPDATEQUOTE, QuoteAcceptType;

od;/*end_buyer2:*/if::DeliveryDetailsC?SENDDELIVERYDETAILS,

DeliveryDetailsType;::BuyerToSellerC?CREDITCHECKFAILS,

CreditRejectType;/* This message notify the buyer about the fail */

fi} /* end process Buyer */

Figure 7.10: Buyer definition in the PROMELA model


/** Processes

*/

proctype Seller(){chan DeliveryDetailsC;end_seller:BuyerToSellerC?REQUEST, RequestforQuoteType;BuyerToSellerC!RESPONSE, QuoteType;do::BuyerToSellerC?ACCEPTQUOTE, QuoteAcceptType;BuyerToSellerCC?SENDCHANNEL, DeliveryDetailsC;break;/* ::skip;

NoBartening, do nothing */::BuyerToSellerC?REQUESTNEWPRICE, UpdateQuoteType;BuyerToSellerC!ACCEPTUPDATEQUOTE, QuoteAcceptType;

od;SellerToCreditChkC!CHECKCREDIT, CheckCreditType;if::SellerToCreditChkC?CREDITCHECKFAILS,

CreditRejectType->BuyerToSellerC!CREDITCHECKFAILS,

CreditRejectType;/* This message notify the buyer about the fail */::SellerToCreditChkC?CREDITCHECKPASSES,

CreditAcceptType ->SellerToShipperC!SELLERREQUESTDELIVERY,

RequestDeliveryType;SellerToShipperC?SELLERRETURNDELIVERY,

DeliveryDetailsType;SellerToShipperCC!FORWARDCHANNEL,

DeliveryDetailsC;fi;} /* end process Seller */

Figure 7.11: Seller definition in the PROMELA model


/** Processes

*/

proctype CreditChecker(){end_creditcheker:SellerToCreditChkC?CHECKCREDIT, CheckCreditType;if

::SellerToCreditChkC!CREDITCHECKFAILS,CreditRejectType->skip;

::SellerToCreditChkC!CREDITCHECKPASSES,CreditAcceptType;->skip;

fi;} /* end process CreditChecker */

init {atomic {run Buyer();run Seller();run CreditChecker();run Shipper();

};}

Figure 7.12: CreditChecker and init definitions in the PROMELA model

alyze the WS-CDL language source and isolate the necessary information to builda PROMELA model suitable for SPIN verification. Each participant involved inthe composition is mapped to a PROMELA process that exchange messages withthe other. Messages are represented by integer constants.

At the moment, the developed mapping is only a proof of concepts to showhow a choreography can be tested using existing model checking techniques.The mapping does not refer to the whole specification but only to the main con-cepts, namely, the main constructs that regulate compositions like interactions,sequence, choice and parallel.


Figure 7.13: Output of the SPIN verification procedure

Figure 7.14: Message Sequence Chart of the simulation

Part IV

Conclusions

Chapter 8Conclusions

This thesis concerned the engineering of service systems based on the service-orientation paradigm to improve interoperability in the e-Government domain.ICT in the government sector plays a basic role for a better delivery of govern-ment services to citizens, business and organizations, and for a more efficientmanagement of the governance. For these reason I addressed interoperability andcooperation among them as fundamental aspects to promote the governance, theservice delivery, and to support decision-making inside the public sector.

Public Administrations promote innovation to automate their activities, to im-prove their cooperation and to provide faster and more efficient access to the ser-vices they provide. I started form an analysis of the domain to identify needs andlacks in the technology adoption to build effective system to the delivery of gov-ernment services that are the result of complex interaction among heterogeneousPAs. I use the Service Oriented Architecture vision and the technology based onweb services to implement backend systems for e-Government service provision-ing. Practical benefits of this approach are today increasingly recognized permit-ting to improve business agility. Moreover, I highlight the need of managementsystems to organize the service delivery to the user.

Several challenges has been introduced in the background chapters (2 and 3).Heterogeneous PAs and heterogeneous users foster the need to cross-organizationalcollaboration whose achievement is possible through interoperability at softwarelevel and a proper management of knowledge.

In Chapter 4 the importance of standards for information representation in thePublic Administration setting were clarified. Metadata standardization is the bestmanner to define semantics in cooperative decentralized systems in Public Admin-istrations. They allows a better accuracy in the management of semantic aspectsof cooperation, reduction of interdependencies, semantic transparency, and a fairdistribution of applicative logic allowing integration of large scale applications

132 CHAPTER 8. CONCLUSIONS

and Public Administration information systems.In this setting I proposed an ontology-based methodology and infrastructure

for the delivery of intelligent documents within Public Administrations. PAs canaccess a common repository to find ontologies describing a document and set uptheir information systems to manage the entire life cycle of the document: userinterface creation, data storage and management of the iter of compilation. To dothis, I deal with the concept of Intelligent Document, a document that is able todescribe its structure and to specify the procedural iter for its filling. This can beseen as a result of a cooperation between PAs involved in the delivery of servicesto the citizens.

Moreover, e-Government research want to deliver a new class of technologyplatforms to constitute a reliable infrastructure to support service delivery. Therealization of such systems include the development of new approaches to thedesign and management of systems.

I presented a modular system for e-Government services distribution that canbe easily updated, extended and integrated with the existing information systemof Public Administrations. End users, on the other hand, are expected to benefitfrom easier (in terms of the effort to locate and use), faster (in terms of the timerequired for the delivery of results) and better services (in terms of the quality ofservices acquired and added value such as a greater selection of services to choosefrom, greater transparency of the service delivery cycle, . . . ). Moreover, somedirect and indirect costs incurred by current bureaucratic and highly disintegratedadministrative procedures were avoided.

In the same chapter, I proposed an overview about e-Government in the MarcheRegion model. It offers innovative solutions for the authentication, the authoriza-tion, the discovery and the composition with the potential to achieve operationalintegration into one-stop e-Government service offerings by means of a servicesmanagement system. This allows organizations that delivery e-Government torealize specific web portals for the distribution of personalized services that aretaken from a single repository managed by a central administration. The model isbuilt around citizens to solve some issues like: (i) what service can be offer, (ii)how a service can be searched and delivered, (iii) how a service must be visual-ized/presented to the user, and (iv) who are the final user interested.

In the presented systems, Service Oriented Architecture and web services areemerging technologies that promise to revolutionize the way in which organiza-tions will interact. Nevertheless, as for any new domain is necessary to reconsiderall the engineering activities to understand which are the new opportunities andthe new challenges. As software systems, e-Government systems must be reliable.To address this requirement I move the focus on the testing and the analysis of theservice-oriented backend of service systems in chapters 6 and 7.

In Chapter 6 I proposed a novel approach to testing of those services to be

CHAPTER 8. CONCLUSIONS 133

integrated by a service orchestrator. The intuition is that the best test suites tobe executed on a service participant could be derived from those executions thatshow the greatest number of run-time interactions among the integrated servicesand the orchestrator. I combine model checking and genetic algorithms techniquesin order to identify the execution traces to be used for test cases derivation. Thecombination of this two techniques permits to reduce the risk of the occurrence ofthe state-explosion phenomenon. The approach is certainly time consuming giventhat model checking have to be executed many times. Nevertheless the processhas to be executed only once given an orchestration.

This research is certainly still on going and the approach has to be validated onbigger and more realistic case studies, nevertheless some encouraging results havebeen already obtained on some small examples. Moreover, this approach could bevaluable to assess citizens trust. This is a major requirement in the research agendafor real take-off of the e-Government revolution in the public sector. Dynamicdiscovery of services can increase the risk of failure of composite services withstrong consequences on citizen trust and the use of testing want to reduce the riskor run-time failure due to interoperability issues and after that sensitive data havebeen provided by the citizen.

Chapter 7 reported an approach to formal verification of web service com-position expressed using the emerging WS-CDL language by means of a modelchecker. The approach foresees a design-time analysis using the well know andwidely used model checker SPIN that allows deadlock detection, invalid end statedetection and verification of safety and liveness properties expressed using LTL.I analyze the WS-CDL language source and isolate the necessary information tobuild a PROMELA model suitable for SPIN verification. Each participant in-volved in the composition is mapped to a PROMELA process that exchange mes-sages with the other. Messages are represented by integer constants. The mappingdoes not refer to the whole specification but only to the main concepts, namely,the main constructs that regulate compositions like interactions, sequence, choiceand parallel. At the moment, the developed mapping is only a proof of concepts toshow how a choreography can be tested using existing model checking techniques.

The presented guidelines for interoperability in the design of service systemsand the approaches to testing and verification in the SOA context are relevantin the e-Government field to increase the public service efficiency. With a care-ful design and engineering of software system it is possible to integrate the PAsto provide high-value services to citizens and firms using innovative technolo-gies. The application of service-orientation principles increase the opportunitiesto reuse of software and the availability and scalability of the proposed solutions.Systems engineered with these principles in mind allow the realization of simplepublic sector open to everybody and aimed to the democratic development of thesociety. I believe that technology should improve everyday life in this way.

Bibliography

[1] Helena Ahonen, Barbara Heikken, Oskari Heinonen, Jani Jaakkola, PekkaKilpelainen, Greger Linden, and Heikki Mannila. Intelligence Assemblyof Structure Document. Technical report, Deparment of Computer Science,University of Helsinky, June 1996. 68

[2] G. Alonso, F. Casati, H. Kuno, and V. Machiraju. Web Services–Concepts,Architectures and Applications. Springer–Verlag, 2004. 81

[3] P. Ammann, P.E. Black, and W. Majurski. Using model checking to gener-ate tests from specifications. In ICFEM 1998, 1998. 108

[4] T. Andrews, F. Curbera, H. Dholakia, Y. Goland, J. Klein, F.k Leymann,K. Liu, D. Roller, D. Smith, S. Thatte, I. Trickovic, and S. Weerawarana.Business Process Execution Language for Web Services Version 1.1, July2002. 49, 81, 86, 111

[5] David Avison and Guy Fitzgerald. Information Systems Development:Methodologies, Techniques and Tools. McGraw-Hill Higher Education,4 edition, March 2006. 10

[6] Luciano Baresi and Sam Guinea. Dynamo: Dynamic monitoring of ws-bpel processes. In ICSOC 2005, pages 478–483, 2005. 90

[7] A. Barros, M. Dumas, and P. Oaks. A Critical Overview of the Web Ser-vices Choreography Description Language (WS-CDL), March 2005. 111

[8] T. Bellwood, S. Capell, L. Clement, J. Colgrave, M. J. Dovey, D. Fey-gin, A. Hately, R. Kochman, P. Macias, M. Novotny, M. Paolucci, C. vonRiegen, T. Rogers, K. Sycara, P. Wenzel, and Z. Wu. UDDI spec technicalcommittee draft, 2004. 49, 76, 111

136 BIBLIOGRAPHY

[9] B.J. Berkley and A. Gupta. Improving service quality with informationtechnology. International journal of information management, 14(2):109–121, 1994. 74

[10] Tim Berners-Lee. Design issues for the world wide web,http://www.w3.org/DesignIssues/, 1997. 55

[11] D. Bianculli, C. Ghezzi, and P. Spoletini. A model checking approach toverify BPEL4WS workflows. In SOCA 2007, pages 13–20, 2007. 97

[12] Francesco Bolici. PA’s Boundaries and the Organizational Knowledge Pro-cesses. In Electronic Government: 4th International Conference, EGOV2005, Copenhagen, Denmark, August 22-26, 2005: Proceedings. Springer,2005. 10

[13] Francesco Bolici, Franca Cantoni, Maddalena Sorrentino, and FrancescoVirili. Cooperating strategies in e-government. Electronic Government,pages 1069–1070, 2003. 9

[14] D. Booth, H. Haas, F. McCabe, E. Newcomer, M. Champion, C. Ferris, andD. Orchard. Web Services Architecture, http://www.w3.org/TR/ws-arch/.W3C Working Group Note, 11:2005–1, 2004. 19

[15] Athman Boughettaya, Ahemed Elmagarmid, Brahim Medjahed, andMourad Ouzzani. Ontology based support for Digital Government. In Int.Conf. on Very Large Data Bases, London, 2001. 66

[16] Martin Bruggemeier, Angela Dovifat, and Klaus Lenk. open choice: Im-proving public sector performance with process reorganization methodol-ogy. Electronic Government, pages 186–194, 2006. 18

[17] M. Carbone, K. Honda, N. Yoshida, R. Milner, G. Brown, and S. Ross-Talbot. A Theoretical Basis of Communication-Centred Concurrent Pro-gramming. W3C-Working Note, October 2006. 114

[18] IT Centra. Unit (1998): Electronic Government: the view from the queue.Cabinet Office, 1998. 74, 75

[19] Hsinchun Chen, Lawrence Brandt, Valerie Gregg, Roland Traunmuller,Sharon Dawes, Eduard Hovy, Ann Macintosh, and Catherine A. Larson,editors. Digital Government: E-Government Research, Case Studies, andImplementation (Integrated Series in Information Systems) (Integrated Se-ries in Information Systems). Springer, 1 edition, December 2007. 1, 9

BIBLIOGRAPHY 137

[20] E. Christensen, F. Curbera, G. Meredith, and S. Weerawarana. Web Ser-vices Description Language (WSDL) 1.1, 15 March 2001. 48, 86, 111

[21] A. Cimatti, E. M. Clarke, E. Giunchiglia, F. Giunchiglia, M. Pistore,M. Roveri, R. Sebastiani, and A. Tacchella. NuSMV 2: An OpensourceTool for Symbolic Model Checking. In CAV ’02: Proceedings of the 14thInternational Conference on Computer Aided Verification, pages 359–364,London, UK, 2002. Springer-Verlag. 116

[22] J. Clark and S. DeRose. XML Path Language (xpath) version 1.0. W3CRecommendation, 16 November 1999. 115

[23] J. Clarke et al. Reformulating software engineering as a search problem.Software, IEE Proceedings -, 150(3):161–175, 2003. 109

[24] Rance Cleaveland and Steve Sims. The NCSU Concurrency Workbench.In CAV ’96: Proceedings of the 8th International Conference on ComputerAided Verification, pages 394–397, London, UK, 1996. Springer-Verlag.116

[25] Cristiano Codagnone and Maria A. Wimmer, editors. Roadmapping eGov-ernment Research, Visions and Measures towards Innovative Governmentsin 2020. MY Print snc di Guerinoni Marco & C, Clusone, 2007. 22

[26] Commission of the European Communities. The role of e-government foreuropes future. In communication from the commission to the council theEuropean parliament the European economic and social committee and thecommittee of the regions, 2003. 2, 9

[27] F. Corradini, A. Polzonetti, O. Riganelli, L. Forestieri, and A. Sergiacomi.Shared Services Center for E-Government Policy. eGOV INTEROP’05Conference, February 2005. 75

[28] Flavio Corradini, Alberto Polzonetti, and Romeo Pruno. E-Governmentadministrative and semantic cooperation: the role of ”Intelligent Docu-ments”. In Electronic Government: 4th International Conference, pages150–157, Copenhagen, Denmark, August 2005. EGOV (Workshops andPosters) 2005. 65

[29] F. Curbera, M. Duftler, R. Khalaf, W. Nagy, N. Mukhi, and S. Weer-awarana. Unraveling the web services web: an introduction to SOAP,WSDL, and UDDI. Internet Computing, IEEE, 6(2):86–93, Mar/Apr 2002.47, 81

138 BIBLIOGRAPHY

[30] Pratibha A. Dabholkar. Consumer evaluations of new technology-basedself-service options: An investigation of alternative models of service qual-ity. International Journal of Research in Marketing, 13(1):29–51, February1996. 74

[31] Sharon S. Dawes. An exploratory framework for future e-government re-search investments. In Hawaii International Conference on System Sci-ences, Proceedings of the 41st Annual, page 201, 2008. 22

[32] Michael Day. Metadata for digital preservation: A review of recent devel-opments. Research and Advanced Technology for Digital Libraries, pages161–172, 2001. 55

[33] Lorcan Dempsey and Rachel Heery. Metadata: a current view of practiceand issues. Journal of Documentation, pages 145–172, 1998. 55

[34] Rahul De. Evaluation of e-government systems: Project assessment vsdevelopment assessment. Electronic Government, pages 317–328, 2006.18

[35] Y. Dittrich, A. Ekelin, P. Elovaara, S. Eriksen, and C. Hansson. Making e-government happen everyday co-development of services, citizenship andtechnology. In System Sciences, 2003. Proceedings of the 36th AnnualHawaii International Conference on, pages 12 pp.+, 2003. 9

[36] Jr. Edmund M. Clarke, Orna Grumberg, and Doron A. Peled. Model check-ing. MIT Press, Cambridge, MA, USA, 1999. 88, 112

[37] A. K. Elmagarmid and W. J. Mciver. The ongoing march toward digitalgovernment. Computer, 34(2):32–38, 2001. 11

[38] Allen E. Emerson. Temporal and modal logic. Handbook of theoreticalcomputer science (vol. B): formal models and semantics, pages 995–1072,1990. 88

[39] Thomas Erl. Service-Oriented Architecture: Concepts, Technology, andDesign. Prentice Hall, USA, 2005. 2, 19, 27, 50

[40] Thomas Erl. SOA: Principles of Service Design. Prentice Hall, USA, 2007.2, 27, 34, 108

[41] eviware.com. The Web Service, SOA and SOAP Testing Tool,http://www.soapui.org, 2008. 102

BIBLIOGRAPHY 139

[42] Z. Fang. E-government in digital era: Concept, practice and develop-ment. International Journal of the Computer, the Internet and Manage-ment, 10(2):1–22, 2002. 11

[43] A.M. Forman and V. Sriram. The depersonalization of retailing: its impacton the lonelyconsumer. Journal of Retailing, 67(2):226–243, 1991. 74

[44] H. Foster, S. Uchitel, J. Magee, and J. Kramer. Model-based verification ofweb service compositions. In ASE 2003, pages 152–161, 2003. 108, 115

[45] Xiang Fu, Tevfik Bultan, and Jianwen Su. Analysis of interacting BPELweb services. In WWW ’04: Proceedings of the 13th international con-ference on World Wide Web, pages 621–630, New York, NY, USA, 2004.ACM Press. 108, 115

[46] Xiang Fu, Tevfik Bultan, and Jianwen Su. WSAT: A Tool for Formal Anal-ysis of Web Services, 2004. 115

[47] Inc. Gartner. http://www.gartner.com/. 11

[48] Malik Ghallab. PDDL - The Planning Domain Definition Language v. 2.Technical Report CVC TR-98-003 / DVS TR-1165, Yale Center for Com-putational Vision and Control, 1998. 116

[49] P. Godefroid and S. Khurshid. Exploring very large state spaces using ge-netic algorithms. International Journal on Software Tools for TechnologyTransfer (STTT), 6(2):117–127, 2004. 89, 109

[50] A. Gotlieb, B. Botella, and M. Rueher. Automatic test data generationusing constraint solving techniques. In ISSTA 1998, volume 23, pages 53–62, New York, NY, USA, March 1998. ACM Press. 90

[51] Tom Gruber. A translation approach to portable ontologies. KnowledgeAcquisition, 5(2):199–220, 1993. 56, 65, 66

[52] M. Gudgin, M. Hadley, N. Mendelsohn, J. Moreau, and H. F.Nielsen. SOAP Version 1.2 Part 1: Messaging Framework.http://www.w3.org/TR/2003/REC-soap12-part1-20030624, 24 June 2003.W3C Proposed Recommendation. 48, 111

[53] Hans R. Hansen. A case study of a mass information system. Information& Management, 28(3):215–225, March 1995. 74

[54] Richard Heeks. Implementing and Managing eGovernment: An Interna-tional Text. Sage Publications Ltd, November 2005. 1, 9

140 BIBLIOGRAPHY

[55] Richard Heeks and Savita Bailur. Analyzing e-government research: Per-spectives, philosophies, theories, methods, and practice. Government In-formation Quarterly, 24(2):243–265, April 2007. 1, 22

[56] T. A. Henzinger, R. Jhala, R. Majumdar, and G. Sutre. Lazy Abstraction. In29th Annual Symposium on Principles of Programming Languages, pages58–70, 2002. 116

[57] John H. Holland. Adaptation in natural and artificial systems. MIT Press,Cambridge, MA, USA, 1992. 89

[58] Gerard J. Holzmann. The SPIN Model Checker: primer and reference man-ual. Addison Wesley, 2003. 112, 114

[59] Hai Huang, Wei-Tek Tsai, Raymond Paul, and Yinong Chen. AutomatedModel Checking and Testing for Composite Web Services. In ISORC’05: Proceedings of the Eighth IEEE International Symposium on Object-Oriented Real-Time Distributed Computing (ISORC’05), pages 300–307,Washington, DC, USA, 2005. IEEE Computer Society. 108, 116

[60] Lakshmi S. Iyer, Rahul Singh, Al F. Salam, and Fergle Daubeterre. Knowl-edge management for government-to-government g2g process coordina-tion. Electronic Government, an International Journal, pages 18–35, De-cember 2005. 12

[61] B.F. Jones, H.H. Sthamer, and D.E. Eyres. Automatic structural testingusing genetic algorithms. Software Engineering Journal, 11(5):299–306,1996. 109

[62] JUnit.org. Resources for Test Driven Development, http://www.junit.org,2008. 102

[63] N. Kavantzas, D. Burdett, G. Ritzinger, T. Fletcher, Y. Lafon, and C. Bar-reto. Web Services Choreography Description Language Version 1.0, 9November 2005. 111, 112

[64] R. Kazhamiakin, M. Pistore, and L. Santuari. Analysis of communicationmodels in web service compositions. In WWW ’06: Proceedings of the 15thinternational conference on World Wide Web, pages 267–276, New York,NY, USA, 2006. ACM Press. 116

[65] Ralf Klischewski. Towards an ontology for e-document management inpublic administration, the case of schleswig-holstein. In 36th Hawaii Int.Conf. on System Sciences, Hawaii, 2003. 65

BIBLIOGRAPHY 141

[66] Mariya Koshkina and Franck van Breugel. Verification of Business Pro-cesses for Web Services. Technical report, York University - Department ofComputer Science, 4700 Keele Street, Toronto, Ontario, M3J 1P3, Canada,2003. 115, 116

[67] H. Kubicek and R. Cimander. Three dimensions of organizational interop-erability. eGovInterop’07 Conference, October 2007. 19

[68] Zhong Li and Wei Sun. Bpel-unit: Junit for bpel processes. Service-Oriented ComputingICSOC 2006, pages 415–426, 2006. 108

[69] Ziqi Liao and Michael T. Cheung. Internet-based e-shopping and consumerattitudes: an empirical study. Information & Management, 38(5):299–306,April 2001. 74

[70] Ziqi Liao and Michael T. Cheung. Internet-based e-banking and consumerattitudes: an empirical study. Information & Management, 39(4):283–295,January 2002. 74, 75

[71] Tim Mackinnon, Steve Freeman, and Philip Craig. Endo-testing: unit test-ing with mock objects. The XP Series, pages 287–301, 2001. 108

[72] Jeff Magee and Jeff Kramer. Concurrency: state models & Java programs.John Wiley & Sons, Inc., New York, NY, USA, 1999. 116

[73] Jeff Magee, Jeff Kramer, Sebastian Uchitel, and Howard Foster. Ltsa-ws:a tool for model-based verification of web service compositions and chore-ography. icse, 0, 2006. 108

[74] F. Manola, E. Miller, and B. McBride. RDF Primer.http://www.w3.org/TR/rdf-primer/, 10 February 2004. W3C Recom-mendation. 66

[75] Regione Marche. Piano d’azione regionale per l’emissione della cns/ts -carta raffaello. Accordo programma quadro ”Societ dell’informazione, de-libere CIPE 36/02 e 17/03, 2003. 76

[76] D. Martin, M. Paolucci, S. McIlraith, M. Burstein, D. McDermott,D. McGuinness, B. Parsia, T. Payne, M. Sabou, M. Solanki, N. Srinivasan,and K. Sycara. Bringing Semantics to Web Services: The OWL-S Ap-proach. In First International Workshop on Semantic Web Services andWeb Process Composition (SWSWPC 2004), San Diego, California, USA,July 6-9 2004. 116

142 BIBLIOGRAPHY

[77] Philip Mayer and Daniel Lubke. Towards a bpel unit testing framework. InTAV-WEB ’06, pages 33–42, New York, NY, USA, 2006. ACM. 108

[78] Stephen Mcgibbon. The case for service oriented architecture in realis-ing trusted, interoperable, pan-European egovernment services. eGovIn-terop’05, February 2005. 19

[79] G. Mcgraw, C. Michael, and M. Schatz. Generating software test data byevolution. Technical report, Reliable Software Technologies, Sterling, VA,1997. 109

[80] P. McMinn. Search-based software test data generation: a survey: ResearchArticles. Software Testing, Verification & Reliability, 14(2):105–156, 2004.109

[81] Phil Mcminn. Search-based software test data generation: a survey. Soft-ware Testing, Verification and Reliability, 14(2):105–156, 2004. 90

[82] Brahim Medjahed, Abdelmounaam Rezgui, Athman Bouguettaya, andMourad Ouzzani. Infrastructure for e-government web services. IEEEInternet Computing, 7(1):58–65, January 2003. 20

[83] M.L. Meuter, A.L. Ostrom, R.I. Roundtree, and M.J. Bitner. Self-ServiceTechnologies: Understanding Customer Satisfaction with Technology-Based Service Encounters. Journal of Marketing, 64(3):50–64, 2000. 74

[84] R. Milner, J. Parrow, and D. Walker. A calculus of mobile processes, I andII. Inf. Comput., 100(1):1–40, 41–77, 1992. 114

[85] A. Nadalin, C. Kaler, P. Hallam-Baker, and R. Monzillo. Web ServicesSecurity: SOAP Message Security, August 2003. 82

[86] S. Nakajima. Verification of Web Service Flows with Model-CheckingTechniques. In CW ’02: Proceedings of the First International Symposiumon Cyber Worlds (CW’02), page 0378, Washington, DC, USA, 2002. IEEEComputer Society. 115

[87] RTI Neta. Framework regionale per lo sviluppo dei servizi telematici ai cit-tadini ed alle imprese (COHESION), architettura e servizi. internal reportRTI Neta, 2003. 75

[88] Aron O’Cass and Tino Fenech. Web retailing adoption: exploring the na-ture of internet users web retailing behaviour. Journal of Retailing andConsumer Services, 10(2):81–94, March 2003. 75

BIBLIOGRAPHY 143

[89] Jeff Offutt and Wuzhi Xu. Generating test cases for web services using dataperturbation. SIGSOFT Softw. Eng. Notes, 29(5):1–10, 2004. 108

[90] C. Peltz. Web Services Orchestration - a review of emerging technologies,tools, and standards. Technical report, HP, January 2003. 19

[91] C. Peltz. Web services orchestration and choreography. Computer,36(10):46–52, 2003. 82

[92] James Lyle Peterson. Petri Net Theory and the Modeling of Systems. Pren-tice Hall PTR, Upper Saddle River, NJ, USA, 1981. 115

[93] M. Pezze and M. Young. Software Testing and Analysis: Process, Princi-ples and Techniques. Wiley, April 2007. 3, 92

[94] Jeffrey T. Pollock and Ralph Hodgson. Adaptive Information: ImprovingBusiness Through Semantic Interoperability, Grid Computing, and Enter-prise Integration (Wiley Series in Systems Engineering and Management).Wiley-Interscience, 2004. 3, 19, 58, 59, 65

[95] EU Project. eGovernment RTD 2020 Visions and Conceptions of EuropeanCitizens. http://www.egovrtd2020.org/. 22

[96] C.V. Ramamoorthy, S.B.F. Ho, and W.T. Chen. On the automated genera-tion of program test data. IEEE TSE, SE-2(4):293–300, 1976. 90

[97] Regulatory Impact Unit, Cabinet Office. Code of Practice on Consultation- Guidance, 2003. 17

[98] Peter Salhofer and David Ferbas. A pragmatic approach to the introductionof e-government. In dg.o ’07: Proceedings of the 8th annual internationalconference on Digital government research, pages 183–189. Digital Gov-ernment Society of North America, 2007. 18

[99] F. Sanati. An optimal intelligent framework for integrating e-governmentservice delivery. In eGovInterop’07 conference, October 2007. 10

[100] H. Schlingloff, A. Martens, and K. Schmid. Modeling and Model Check-ing Web Services. In Proceedings of the 2nd International Workshop onLogic and Communication in Multi-Agent Systems, volume 126 of Elec-tronic Notes in Theoretical Computer Science, pages 3–26. Elsevier, 2004.115

[101] Hans J. Scholl. Organizational transformation through e-government:Myth or reality? Electronic Government, pages 1–11, 2005. 10

144 BIBLIOGRAPHY

[102] Rajiv C. Shah and Jay P. Kesan. Open standards and the role of politics.In dg.o ’07: Proceedings of the 8th annual international conference onDigital government research, pages 3–12. Digital Government Society ofNorth America, 2007. 11

[103] M. K. Smith, C. Welty, and D. L. McGuinness. OWL Web Ontology Lan-guage Guide. http://www.w3.org/TR/owl-guide/, 10 February 2004. W3CRecommendation. 66

[104] John F. Sowa. Knowledge Representation: Logical, Philosophical, andComputational Foundations. Brooks Cole Publishing Co., Pacific Grove,CA, August 1999. 65

[105] H.S. Thompson, D. Beech, M. Maloney, N. Mendelsohn, et al. XMLSchema Part 1: Structures. http://www.w3.org/TR/xmlschema11-1/, lat-est version of 20 June 2008. W3C Recommendation. 48

[106] James Y. L. Thong, Chee-Sing Yap, and Kin-Lee Seah. Business processreengineering in the public sector: The case of the housing developmentboard in singapore. J. Manage. Inf. Syst., 17(1):245–270, 2000. 18

[107] P. Tonella. Evolutionary testing of classes. ACM SIGSOFT Software Engi-neering Notes, 29(4):119–128, 2004. 109

[108] F. van Breugel and M. Koshkina. Models and verication of bpel. Technicalreport, York University, 2006. 108

[109] A. C. R. van Riel, V. Liljander, and P. Jurriens. Exploring consumer evalu-ations of e-services: a portal site. International Journal of Service IndustryManagement, pages 359–377, 2001. 74

[110] J. Wegener, A. Baresel, and H. Sthamer. Suitability of evolutionary algo-rithms for evolutionary testing. In COMPSAC 2002, pages 287–289, 2002.109

[111] Joachim Wegener, Andre Baresel, and Harmen Sthamer. Evolutionary testenvironment for automatic structural testing. Information and SoftwareTechnology, 43(14):841–854, December 2001. 109

[112] M. Wimmer and J. Krenner. An Integrated Online One-Stop GovernmentPlatform: The eGOV Project, . Proceedings of 9th Interdisciplinary Infor-mation Management Talks, pages 329–337, 2001. 75

BIBLIOGRAPHY 145

[113] M. Wimmer and E. Tambouris. Online One-Stop Government: A workingframework and requirements. Proceedings of the IFIP World Computer-Congress, August, pages 26–30, 2002. 75

[114] Maria Wimmer. Integrated service modelling for online one-stop govern-ment. Electronic Markets, pages 149–156, September 2002. 22

[115] Maria Wimmer. The Role of Research in Successful E-Government Im-plementation. E-government guide Germany: strategies, solutions and ef-ficiency. Fraunhofer IRB Verlag, Stuttgart, pages 79–87, 2007. 22

[116] Maria Wimmer, Cristiano Codagnone, and Marijn Janssen. Future e-government research: 13 research themes identified in the egovrtd2020project. In HICSS ’08: Proceedings of the Proceedings of the 41st An-nual Hawaii International Conference on System Sciences, Washington,DC, USA, 2008. IEEE Computer Society. 1, 22

[117] Mete Yildiz. E-government research: Reviewing the literature, limitations,and ways forward. Government Information Quarterly, 24(3):646–665,July 2007. 22

[118] J. Zhang. Trustworthy web services: Actions for now. IT Pro, 7(1):32–36,January/February 2005. 104

[119] Yongyan Zheng, Jiong Zhou, and Paul Krause. Analysis of bpel data de-pendencies. In Software Engineering and Advanced Applications, 2007.33rd EUROMICRO Conference on, pages 351–358, 2007. 108

[120] Yongyan Zheng, Jiong Zhou, and Paul Krause. A model checking basedtest case generation framework for web services. In ITNG ’07, pages 715–722, 2007. 108

[121] F. X. Zhu, W. Wymer, and I. Chen. It-based services and service quality inconsumer banking. International Journal of Service Industry Management,pages 69–90, 2002. 74

PhD in Information Science and Complex SystemsCollection of theses

XXI-09-1 Ezio Bartocci. A Formal Framework for Modeling, Simulating andAnalyzing Network of Excitable Cells. January 2009.

XXI-09-2 Francesco De Angelis. Interoperability in e-Government Services. Jan-uary 2009.

XXI-09-3 Oliviero Riganelli. Online Public Service Delivery for Small and MediumSize Organizations. January 2009.