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

1. TCGOV 2005A Distributed Architecture for Supporting e-GovernmentCooperative Processes Mariangela Contenti (1), Massimo Mecella (2) Alessandro Termini (2), Roberto Baldoni (2) (1) Università LUISS Guido Carli, Centro di Ricerca sui Sistemi Informativi (Roma – ITALY) (2) Università “La Sapienza”, Dipartimento di Informatica e Sistemistica (Roma – ITALY)

2. The EU-PUBLI.com Project • 3 year IST project (2002-2005) • Official website: www.eu-publi.com

3. At intra-organizational, national and European level macro-processes The Contribution (1) General framework & architecture Design and development of a technological infrastructure facilitating cooperation among PA’s employees in the provision of complex business processes

4. 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

5. Service Requestor 3. Bind( ) 2. Find( ) Transport Medium Service Directory 1.Publish( ) Service Provider Eu-Publi.com Requirements (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 4. Invoke( )

6. Eu-Publi.com Requirements (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

7. Motivations • 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 theenactment • 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)

8. (1) (2) (3) (3) (4) (5) (6) (7) City Council service Local Health Authority service Citizen service Prefecture service

9. Choreography is ONLY the specification of these multy-party message exchanges (see DeGiacomo & Mecella – Tutorial @ ICSOC 2004) (1) (2) (3) (3) (4) (5) (6) (7) Enactment, monitoring, etc. of the message exchanges (i.e., of the workflow) is orchestration … currently only centralized City Council service Orchestration Task Local Health Authority service Orchestration Task Citizen service Prefecture service

10. Overall Conceptual Architecture 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

11. Eu-Publi.com Requirements (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

12. Semantic Engine Engine Engine Sec uri ty Eng Transaction Security ine Eu-Publi.com Peer Presentation Layer Presentation Layer Sub-component: • Front End • Semantic Engine Peer Cooperative Gateway Sub-component: • Peer Orchestration Engine • System Wrapper • Transaction Engine • Security Engine Peer Information Manager Sub-component: • Local Repository Eu EU - - Publi.com PUBLI.com Front Front - - End End Peer Orchestration Local Local Engine Repository Repository Peer Information Manager System System Wrapper Wrapper Information Information systems systems ( ( legacy legacy applications applications ) ) Peer Information Gateway

13. Design Issues (1)General 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

14. Design Issues (2)Service Types

15. 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

16. 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)

17. An Explanatory Process: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

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

20. PROCESS SUB-PROCESS 1 1st SendResponsability SUB-PROCESS 2 Agency23 SUB-PROCESS 3 Police Headquarter 2nd SendResponsability An Explanatory Process:a License Request (4)

21. Specifying and Running the Process • 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

22. Specifying and Running the Process • 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

23. Architecture of the Orch. Engine

24. ca 477.000(around 8 minutes) Absolute values 1.000.000 execution (msec) 1st instance next instances Perfomance Analysis

25. Conclusion • 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

26. Questions?

28. Formal Model: Service 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 a, the Web-Service does some work and then it sends the message b as output • at this point, the Web-Service is ready to accept new input messages

29. Service Nets (2) (Input) message place ( a ) Control place (representing a state of the Web-Service with respect to possible message exchanges it can be involved in) Transition ( b ) (Output) message place

30. Orchestration Nets (1) • AnOrchestration Netconnects 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 netinthe form of a XML document

31. Output message place (from Web-Service 1) Orchestration place ( organizationa ) Transition ( b ) ( organizationb ) Input message place (to Web-Service 2) Input message place (to Web-Service 3) ( a2 ) ( a3 )

34. 1 memorizzaRequest memorizza 2 memorizzaResponse aggiornaStatoPraticaRequest aggiornaStatoPratica 3 RilascioPortoArmi 1 A 7 Agenzia23 2 3 Q 4 Anagrafe 5 6 CasellarioGiudiziario Questura Process Development Metodology • 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

35. WS i-esimo s s s s s WS i-esimo Organization N α α α α WS i-esimo WS i-esimo WS i-simo WS i-esimo process partnerLink Transition O transaction O transaction O transaction O transition F variables α β β t t t correlationSets q t β faultHandlers γ β sequence transaction Q Organization L activities WS j-esimo β t WS j-esimo WS k-esimo Process Development Metodology • BPEL mapping of the Orchestration Net • Mapping of the Service Net transition • Request-Response • Request-Reply • One-way • Notification • Mapping of manipulating transition • Mapping of Send Responsability transition