TCGOV 2005 A Distributed Architecture for Supporting e-Government Cooperative Processes
description
Transcript of 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
3TCGOV2005Bolzano/Bozen – March 3rd,
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
4TCGOV2005Bolzano/Bozen – March 3rd,
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
8TCGOV2005Bolzano/Bozen – March 3rd,
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( )
9TCGOV2005Bolzano/Bozen – March 3rd,
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
10TCGOV2005Bolzano/Bozen – March 3rd,
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)
11TCGOV2005Bolzano/Bozen – March 3rd,
2005
(1)
(2)
(4)
(3)
(3)
(5)
(6)
(7)
City Councilservice
Citizenservice
Local Health Authorityservice
Prefectureservice
12TCGOV2005Bolzano/Bozen – March 3rd,
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
13TCGOV2005Bolzano/Bozen – March 3rd,
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
14TCGOV2005Bolzano/Bozen – March 3rd,
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
15TCGOV2005Bolzano/Bozen – March 3rd,
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
16TCGOV2005Bolzano/Bozen – March 3rd,
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
17TCGOV2005Bolzano/Bozen – March 3rd,
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
18TCGOV2005Bolzano/Bozen – March 3rd,
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
19TCGOV2005Bolzano/Bozen – March 3rd,
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)
20TCGOV2005Bolzano/Bozen – March 3rd,
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
21TCGOV2005Bolzano/Bozen – March 3rd,
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.
22TCGOV2005Bolzano/Bozen – March 3rd,
2005
23TCGOV2005Bolzano/Bozen – March 3rd,
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)
24TCGOV2005Bolzano/Bozen – March 3rd,
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
25TCGOV2005Bolzano/Bozen – March 3rd,
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
26TCGOV2005Bolzano/Bozen – March 3rd,
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
*
27TCGOV2005Bolzano/Bozen – March 3rd,
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
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
wit
h S
R /
late
nc
y w
ith
ou
t S
R
second instances
1
10
100
1.000
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
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)
28TCGOV2005Bolzano/Bozen – March 3rd,
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
29TCGOV2005Bolzano/Bozen – March 3rd,
2005
Questions?Questions?
30TCGOV2005Bolzano/Bozen – March 3rd,
2005
31TCGOV2005Bolzano/Bozen – March 3rd,
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
32TCGOV2005Bolzano/Bozen – March 3rd,
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
33TCGOV2005Bolzano/Bozen – March 3rd,
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
34TCGOV2005Bolzano/Bozen – March 3rd,
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 )
35TCGOV2005Bolzano/Bozen – March 3rd,
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
36TCGOV2005Bolzano/Bozen – March 3rd,
2005
37TCGOV2005Bolzano/Bozen – March 3rd,
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
38TCGOV2005Bolzano/Bozen – March 3rd,
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>
<process . . . xmlns:wsi=”http://. . . WS_i-esimo”>
. . . <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
<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:α” />
. . . </variables>
. . . <sequence>
. . . <invoke . . . parternLink=”WS_i-esimo” operation=”O” inputVariable=”in”/> . . . </sequence></process>
s
tβ
WS i-esimo
Transition O
<process . . . xmlns:wsi=”http://. . . WS_i-esimo”>
. . . <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