TCGOV 2005 A Distributed Architecture for Supporting e-Government Cooperative Processes

TCGOV 2005TCGOV 2005

A Distributed Architecture for A Distributed Architecture for Supporting e-GovernmentSupporting e-Government

Cooperative ProcessesCooperative Processes

Mariangela Contenti (1), Massimo Mecella Massimo Mecella (2)(2)

Alessandro Termini (2), Roberto Baldoni (2) (1) Università LUISS Guido Università LUISS Guido Carli, Centro di Ricerca sui Carli, Centro di Ricerca sui Sistemi Informativi (Roma – Sistemi Informativi (Roma – ITALY)ITALY)

(2) (2) Università “La Sapienza”, Università “La Sapienza”, Dipartimento di Informatica Dipartimento di Informatica e Sistemistica (Roma – e Sistemistica (Roma – ITALY)ITALY)

2TCGOV2005Bolzano/Bozen – March 3rd,

2005

The EU-PUBLI.com ProjectThe EU-PUBLI.com Project

• 3 year IST project (2002-2005)• Official website: www.eu-publi.com


2005

The Contribution (1)The Contribution (1)

Design and development of a

technological infrastructure facilitating

cooperation among PA’s employees in the

provision of complex business processes

macro-processes

At intra-organizational,national and European level

General framework & architecture


2005

The Contribution (2)The Contribution (2)

• Formal and Architectural definition of distributed orchestration– Enhancement over current state of the

art in Service Oriented Computing (SOC)

• Perfomance overhead is acceptable wrt. the gained flexibility– In term of legal constraints– In term of support for decentralization


2005

Eu-Publi.com Requirements Eu-Publi.com Requirements (1)(1)

• Interoperability among autonomous PAs– cooperation between different administrations

without any modification of each administration internal system

• Service Oriented Architecture (SOA)– service abstraction

indipendent from techologies

TransportMedium

3. Bind( )2. Find( )

1.Publish( )

ServiceDirectory

Service Provider

ServiceRequestor

4. Invoke( )


2005

Eu-Publi.com Requirements Eu-Publi.com Requirements (2)(2)• Complex business processes

– an architecture that allow the management of complex business process in a common and non-intrusive way (e.g. organizational and/or technical constraint)

• A service-based WfMS processing orchestration schemas

– which act as “scripts” coordinating the interactions among services

– the orchestration should be dynamic and decentralized


2005

MotivationsMotivations• Orchestration of Web-Services is based on

cooperative processes• It needs to be carried on, controlled and

monitored by organizations– but such a task can not be assigned to a single

organization, due to laws, regulations, etc.– conversely it should be moved all along the

enactment– in a given time instant, only one and exactly

one organization is orchestrating (i.e., coordinating) the different Web-Services involved in the given cooperative process case

• E.g., some Italian complex processes (as the one described in Mecella and Batini, IEEE Computer 2001)


2005

(1)

(2)

(4)

(3)

(3)

(5)

(6)

(7)

City Councilservice

Citizenservice

Local Health Authorityservice

Prefectureservice


2005

(4)

(5)

(6)

(7)CitizenservicePrefecture

service

(1)

(2)

(3)

(3)

OrchestrationTask

Local Health Authorityservice

City Councilservice

OrchestrationTask

ChoreographyChoreography is ONLY the specification of these multy-party message exchanges (see DeGiacomo & Mecella – Tutorial @ ICSOC 2004)

Enactment, monitoring, etc. of the message exchanges (i.e., of the workflow) is orchestrationorchestration … currently only centralized


2005

Overall Conceptual Overall Conceptual ArchitectureArchitecture

Presentation Layer

Peer

Information

ManagerPeer

Cooperative

Gateway

Presentation Layer

Peer

Information

ManagerPeer

Cooperative

Gateway

References toorganizationinformation

managers

Global InformationManager Registry

O2

On

O1

Presentation Layer

Peer

Information

ManagerPeer

Cooperative

Gateway

Peer Information Manager• stores local schemas

(services and orchestration)

• stores instance data

Peer Cooperative Gateway

• exports the set of data and services application offered by a single administration

• includes the Peer Orchestration Engine component

Presentation Layer• represents the interface

to the employees


2005

Eu-Publi.com Requirements Eu-Publi.com Requirements (3)(3)

• Semantic Issues– semantic conflicts related with

organizational, cultural and linguistic differences in the information exchanged

• Dependability Issues– Long term Transaction – Reliability and High availability

• Security Issues– Secure exchange and long term data storing – Access control policies intra and inter

organization


2005

Eu-Publi.com PeerEu-Publi.com Peer

Presentation Layer Sub-component:

– Front End– Semantic Engine

Peer Cooperative Gateway Sub-component:

– Peer Orchestration Engine

– System Wrapper– Transaction Engine– Security Engine

Peer Information ManagerSub-component:

– Local Repository

LocalRepository

EU-PUBLI.com Front-End

Information systems(legacy applications)

System Wrapper

Information systems(legacy applications)

System Wrapper

LocalRepository

Eu-Publi.com Front-End

PeerOrchestration

Engine

Peer Information Gateway

Peer Information Manager

Presentation Layer

Semantic Engine

SecurityEngine

TransactionEngine

SecurityEngine


2005

Design Design Issues (1)Issues (1)General OverviewGeneral Overview

• Web service as natural implementation of services– Each PA exports its functionalities as Web-services

(basically SOAP and WSDL)

• Web service composition– BPEL4WS Specification, Orchestration schema as BPEL

files

• Semantic conflict resolution– OWL-S based technologies

• Transaction and Security– based on WS-C, WS-T and WS-S standards

• Global registry and Repositories– Based on UDDI technologies


2005

Design Design Issues (2)Issues (2)Service TypesService Types

Back-end Legacy System

Service

Client

Back-end Legacy SystemFront-End

Organization AEmployee

Organization AEmployee

Service

Client


2005

Technical Details (1)Technical Details (1)

• An orchestration schema is moved from an orchestration engine (deployed onto an organization) to another one (deployed onto another organization) as the task of the overall coordination is assigned to some other organization

• Orchestration schemas are enacted by orchestration engines– deployed by different cooperating

organizations


2005

Technical Details (2)Technical Details (2)• Cooperative Process Designer specifies

(i) process flow as in the “centralized” scenario, and (ii) the responsibilities

• The platform automatically generates the “portions” of the orchestration schema to be enacted by the different involved engines

• Orchestration language: BPEL4WS• An extension of BPEL4WS with

“SendResponsibility” operations (obtaining the BPEL++ orchestration language)


2005

An Explanatory Process:An Explanatory Process:a License Request (1)a License Request (1)• Involved Authorities are:

– Police Headquarter– Registry Office– Criminal Records Office

• It’s supposed the process is provided by a private Agency

– The process started under Agency responsability from client request

– It must be assigned to the Police Headquarter to perform the core of the process– Check personal data correctness by Registry Office– Check the lack of criminal cases pending by Criminal

Records Office– It returns to Agency to communicate the result of the

client request


2005

An Explanatory Process:An Explanatory Process:a License Request (2)a License Request (2)

ServerAgency23

ServerPoliceHeadquarter

1st SendResponsability3→4

2nd SendResponsability15→16

Client

WSAgency23

WS PoliceHeadquater

WSRegistryOffice

WSCriminal RecordsOffice

3.17.

1.

2.16.

4.8.12.14.5.9.13.15.

6.

7.

10.

11.

18.

ServerAgency23

ServerPoliceHeadquarter

1st SendResponsability3→4

2nd SendResponsability15→16

Client

WSAgency23

WS PoliceHeadquater

WSRegistryOffice

WSCriminal RecordsOffice

3.17.

1.

2.16.

4.8.12.14.5.9.13.15.

6.

7.

10.

11.

18.


2005


2005

Agency23

Police Headquarter

1st SendResponsability

2nd SendResponsability

PROCESS

SUB-PROCESS 1

SUB-PROCESS 2

SUB-PROCESS 3

An Explanatory Process:An Explanatory Process:a License Request (4)a License Request (4)


2005

SpecifyingSpecifying and Running the and Running the ProcessProcess• The designer specifies the process and

the responsibilities– A BPEL++ file with “SendResponsibility”

operations

• The BPEL++ file is deployed onto the engine of the initial organization– If there isn’t any “SendResponsibility” then

the process is deployed as in the “centralized” scenario

– Else, the first subprocess is deployed

• The process is ready to be instantiated


2005

• An instance of the process is started– it’s possible to view the execution of the process

through a visual representation of the flow history

• When the first “SendResponsibility” is executed– on the Police Headquarter the second subprocess is

deployed and– the instance proceeds its execution

• Again, the second “SendResponsibility” is executed– on the Agency the third subprocess is deployed and– the instance proceeds and terminates correctly

SpecifyingSpecifying and Running the and Running the ProcessProcess


2005

Architecture of the Orch. Architecture of the Orch. EngineEngine

Peer Orchestration Engine

BPEL Engine

DistributedOrchestration

Module

Interceptor

+send_responsability*

*

*

+deploy_process*from the Peer Orchestration

Engine of another organization

Web Service j

*

+invoke

*


2005

Perfomance AnalysisPerfomance Analysis

0

20

40

60

80

100

120

140

160

180

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25number of send_responsibility operationsla

ten

cy w

ith

SR

/ la

ten

cy

wit

ho

ut

SR

first instances

0

1

2

3

4

5


ten

cy

wit

h S

R /

late

nc

y w

ith

ou

t S

R

second instances

1

10

100

1.000


ten

cy

wit

h S

R /

late

nc

y w

ith

ou

t S

R

first instances second instances

Durata di esecuzione delle istanze

1 10 100 1.000 10.000 100.000 1.000.000

0

3

6

9

12

15

18

21

24

Se

nd

Re

sp

on

sib

ility

esecuzione (msec)

prime istanze seconde istanze

Absolute values

execution (msec)

1st instance next instances

1.000.000

ca 477.000(around 8 minutes)


2005

ConclusionConclusion

• Standardized and reusable infrastructure – exposition and composition of additional

services in a modular fashion– performance analysis support for Business

Process Reengineering

• Seamless PA services to citizen

• Current stage of the project– architectural component developed– a real complex business process involving the

end users under development– Tests and final assessment as final phase


2005

Questions?Questions?


2005


2005

Formal Model: Service Formal Model: Service Nets (1)Nets (1)• A Web-Service is specified both in its

static interfaces and in its protocol • A Web-Service communicates through

messages– both the received ones and the messages

the Web-Service produces– upon receiving the message , the Web-

Service does some work and then it sends the message as output

– at this point, the Web-Service is ready to accept new input messages


2005

Service Nets (2)Service Nets (2)

( )

( )

Transition

(Input) message place

Control place

(representing a state of the Web-Service with respect to possible message exchanges it can be involved in) (Output) message

place


2005

Orchestration Nets (1)Orchestration Nets (1)• An Orchestration Net connects at least two

Service Nets– specifies the routing of messages ...– ... and the act of passing the task of the

orchestration from an organization to another one

• The orchestration engine– manipulates the messages and correctly routes

them;– then the engine moves the orchestration schema to

the engine of the next organization which is assigned the orchestration task

– the orchestration schema is the representation of the net in the form of a XML document


2005

( )

Transition

Input message place (to Web-Service 2)

Orchestration place

( )

Output message place (from Web-Service 1)

( )

Input message place (to Web-Service 3)

( organization )

( organization )


2005

IC E

NATH

G ov ernm entG aze tte

(re que s t_ inc o rpo ratio n_ lic e ns e )

(re que s t_ inc o rpo ratio n_ lic e ns e )

(ac ts _ and_ de e d_ s umm ary)

(ac ts _ and_ de e d_ s umm ary)

(inc o rpo ratio n_ lic e ns e )

(inc o rpo ratio n_ lic e ns e )

(pub lis he d_ ac ts _ and_ de e d_ s umm ary)

(pub lis he d_ ac ts _ and_ de e d_ s umm ary)

O rches tra tion

ICE_ e -Se r vi c e

ICE_ e -Se r vi c e

G G _ e -Se r vi c e

NATH _ e -Se r vi c e

1

2


2005


2005

Process Development Process Development MetodologyMetodology• Choice of the Web-

Services involved in the process– Specifying as

Service Net

• Specification of the Orchestration Net through the design of messages exchange between Web-Services

<Conversation name=”Agenzia23Conversation”> <Transition source=”1” target=”2” type=”synchronous”> <InputMessage> memorizzaRequest</InputMessage><OutputMessage>memorizzaResponse</OutputMessage> </Transition> <Transition source=”2” target=”3” type=”synchronous”> <InputMessage>aggiornaStatoPraticaRequest</InputMessage> </Transition>

</Conversation>

1

2

3

memorizzaRequest

memorizzaResponse

aggiornaStatoPraticaRequest

aggiornaStatoPratica

memorizza

A

Q

Casellario Giudiziario

Anagrafe

Questura

Rilascio Porto Armi

Agenzia23

1

27

3

4

5

6


2005

Process Process Development Development MetodologyMetodology

• BPEL mapping of the Orchestration Net – Mapping of the

Service Net transitionRequest-ResponseRequest-ReplyOne-wayNotification

– Mapping of manipulating transition

– Mapping of Send Responsability transition

<process . . . xmlns:wsi=”http://. . . WS_i-esimo”>

. . . <plnk:partnerLinks> < plnk:partnerLink name="WS_isimo“ partnerLinkType="wsi:plnkWS_i-esimo“ . . . /> . . . </ plnk:partnerLinks > . . . <variables> <variable name=”in” messageType=”wsi:α” /> <variable name=”out” messageType=”wsi:β” />

. . . </variables>

. . . <sequence>

. . . <invoke . . . parternLink=”WS_i-esimo” operation=”O” inputVariable=”in”/> . . . <receive . . . parternLink=”WS_i-esimo” operation=”Q” variable=”out”/> . . . </sequence></process>


. . . <plnk:partnerLinks>< plnk:partnerLink name="WS_i-esimo"partnerLinkType="wsi:plnkWS_i-esimo". . . />. . . </ plnk:partnerLinks >. . .

<variables><variable name=”in”

messageType=”wsi:α” /><variable name=”out”

messageType=”wsi:β” />. . .

</variables>. . .

<sequence>. . .

<invoke . . . parternLink=”WS_i-esimo”

operation=”O” inputVariable=”in” outputVariable=”out”/> . . .

</sequence> </process>

s

t

α

β

WS i-esimo

transaction O

process

partnerLink

variables

correlationSets

faultHandlers

sequence

activities

sα

tβ

WS i-simo

transaction O

q

transaction Q

sα

t

WS i-esimo

transaction O


. . . <plnk:partnerLinks> < plnk:partnerLink name="WS_isimo“ partnerLinkType="wsi:plnkWS_i-esimo“ . . . /> . . . </ plnk:partnerLinks > . . . <variables> <variable name=”in” messageType=”wsi:α” />

. . . </variables>

. . . <sequence>

. . . <invoke . . . parternLink=”WS_i-esimo” operation=”O” inputVariable=”in”/> . . . </sequence></process>

s

tβ

WS i-esimo

Transition O


. . . <plnk:partnerLinks> < plnk:partnerLink name="WS_isimo“ partnerLinkType="wsi:plnkWS_i-esimo“ . . . /> . . . </ plnk:partnerLinks > . . . <variables> <variable name=”out” messageType=”wsi:β” />

. . . </variables>

. . . <sequence>

. . . <receive . . . parternLink=”WS_i-esimo” operation=”Q” variable=”out”/> . . . </sequence></process>

s

α

t

β

γ

WS i-esimo

WS j-esimo WS k-esimo

transition F

<process . . . xmlns:wsi=”http://. . . WS_i-esimo”xmlns:wsj=”http://. . . WS_j-esimo” xmlns:wsk=”http://. . . WS_k-esimo” >

. . . <variables> <variable name=”inJ” messageType=”wsj:γ” /> <variable name=”inK” messageType=”wsk:β” /> <variable name=”out” messageType=”wsi:α” />

. . . </variables>

. . . <sequence>

. . . <assign name=”F”> <copy>

<from variable=”out” . . . /><to variable=”inJ” . . . />

</copy> <copy>

<from variable=”out” . . . /><to variable=”inK” . . . />

</copy> </assign> . . . </sequence></process>

<process . . . xmlns:sr=”http://localhost:8080/axis/PARIDE/SendResponsability_NameService.jws”>

. . . <plnk:partnerLinks>< plnk:partnerLink name="SendResponsability" partnerLinkType="sr:SendResponsability" partnerRole=”SendResponsabilityService”/>. . . </ plnk:partnerLinks >. . . <variables> <variable name=”sendin” messageType=”sr:SendResponsabilityRequest”/> <variable name=”sendout” messageType=”sr:SendResponsabilityResponse”/> . . . </variables>

. . . <sequence>

. . . <assign name=”SaveStateOfProcessInstance”> . . . </assign> <invoke name=”SendResponsability” parternLink=”SendResponsability” portType=”sr:SendResponsability_NameService” operation=”SendResponsability” inputVariable=”sendin” outputVariable=”sendout”/> . . . </sequence></process>

α

β

WS i-esimo

WS j-esimoOrganization L

Organization N

Documents

TCGOV 2005 A Distributed Architecture for Supporting e-Government Cooperative Processes