TCGOV 2005 TCGOV 2005 A Distributed Architecture for A Distributed Architecture for Supporting e-Government Supporting e-Government Cooperative Processes Cooperative Processes Mariangela Contenti (1) , Massimo Mecella Massimo Mecella (2) (2) Alessandro Termini (2) , Roberto Baldoni (2) (1) Università LUISS Guido Carli, Università LUISS Guido Carli, Centro di Ricerca sui Sistemi Centro di Ricerca sui Sistemi Informativi (Roma – ITALY) Informativi (Roma – ITALY) (2) (2) Università “La Sapienza”, Università “La Sapienza”, Dipartimento di Informatica e Dipartimento di Informatica e Sistemistica (Roma – ITALY) Sistemistica (Roma – ITALY)
35
Embed
TCGOV 2005 A Distributed Architecture for Supporting e-Government Cooperative Processes
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
TCGOV 2005TCGOV 2005
A Distributed Architecture for A Distributed Architecture for Supporting e-GovernmentSupporting e-Government
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
• 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
• 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)
– 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
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