Coordinamento di e-service Argomenti di ricerca B. Pernici Politecnico di Milano Dipartimento di Elettronica e Informazione.

Presentazione sul tema: "Coordinamento di e-service Argomenti di ricerca B. Pernici Politecnico di Milano Dipartimento di Elettronica e Informazione."— Transcript della presentazione:

1 Coordinamento di e-service Argomenti di ricerca B. Pernici Politecnico di Milano Dipartimento di Elettronica e Informazione

2 B. Pernici, Milano, Maggio 2004 - 2 - Outline Gestione di e-service Altri linguaggi Approcci alla progettazione Transazioni Progetti di ricerca: VISPO e MAIS Progettazione di e-service Invocazione dinamica di servizi architetture

3 B. Pernici, Milano, Maggio 2004 - 3 - GESTIONE DI E-SERVICE

4 B. Pernici, Milano, Maggio 2004 - 4 - Extended SOA Papazoglou, CACM ott. 2003

5 B. Pernici, Milano, Maggio 2004 - 5 - Managed services Casati et al, 2003, CACM

6 B. Pernici, Milano, Maggio 2004 - 6 -

7 B. Pernici, Milano, Maggio 2004 - 7 - New interfaces for e-services E-service e port type funzionali Port type di gestione Leymann, 2004

8 B. Pernici, Milano, Maggio 2004 - 8 - ALTRI LINGUAGGI

9 B. Pernici, Milano, Maggio 2004 - 9 - Further dimensions When Static composition happens at design/compile time Dynamic composition happens while executing the process How Non functional aspects like QoS Security Transactional behavior Need for long-lived atomic interactions

10 B. Pernici, Milano, Maggio 2004 - 10 - Technology stack

11 B. Pernici, Milano, Maggio 2004 - 11 - How many standards do we need? WSCI BPEL4WS WS-Transaction WS-Security BPML DAML-S WSXLWS-Coordination WS-I WSFL XLANG WS-Policy WSLA WSRP WSCL

12 B. Pernici, Milano, Maggio 2004 - 12 - APPROCCI ALLA PROGETTAZIONE

13 B. Pernici, Milano, Maggio 2004 - 13 - Collaboration Orchestrazione e coreografia Protocolli di coordinamento

14 B. Pernici, Milano, Maggio 2004 - 14 - Composition models Orchestration Intra-process Process controlled by one party Choreography Inter-processes Sequence of observable messages Conversation among equals

15 B. Pernici, Milano, Maggio 2004 - 15 - Example Casati et al., CACM 2003

16 B. Pernici, Milano, Maggio 2004 - 16 - Conversation or choreography? Peltz, Computer 2003

17 B. Pernici, Milano, Maggio 2004 - 17 - Modeling conversations State diagrams Interaction diagrams Sequence diagrams Activity diagram Rif. Alonso et al, 2004

18 B. Pernici, Milano, Maggio 2004 - 18 - Come progettare un processo Viste sui processi Progettazione bottom-up e top-down

19 B. Pernici, Milano, Maggio 2004 - 19 - Vista privata e vista pubblica dei processi Leymann, 2001

20 B. Pernici, Milano, Maggio 2004 - 20 - Activities and services Two approaches Bottom-up We try to create the requested process out of a set of available services Top-down We start from a well-defined process and try to associate each activity with a suitable service Two moments During the process phase (static) At run-time (dynamic)

21 B. Pernici, Milano, Maggio 2004 - 21 - Bottom-up Where does the travel take place? ACME Travel Agency US Hotel Reservation European Hotel Reservation

22 B. Pernici, Milano, Maggio 2004 - 22 - Top down Where does the travel take place? ACME Travel Agency US Hotel Reservation European Hotel Reservation

23 B. Pernici, Milano, Maggio 2004 - 23 - Associations depend on Semantic aspects Context in which the service operates Goals of the service Syntactic aspects Name of the operations provided Name and order to the requested parameters Order in which the operations have to be invoked

24 B. Pernici, Milano, Maggio 2004 - 24 - Back-tracking planning Is based on approaches used in the agent community Algorithm We start looking for the service that matches my goal The input of the selected service is the new goal The composition terminates when the goal and available inputs match

25 B. Pernici, Milano, Maggio 2004 - 25 - Service directory Service composition depends on the discovery phase Can be done both at design time and at run-time Given an activity we can try to find the most suitable service But, what is the meaning of most suitable? UDDI provides A way to search for services A business oriented classification A set of standard taxonomies Yellow, white, green pages UDDI does not provide Information about quality Content-based discovery

26 B. Pernici, Milano, Maggio 2004 - 26 - Service models Matchmaking mechanism necessarily relies on a specific service models A classical model involves Interface Behavior Quality

27 B. Pernici, Milano, Maggio 2004 - 27 - Interface Defines What the service requires What the service provides From a syntactic perspective defines Exchanged data types Order of parameters in the operations Supported protocol WSDL specifications match the majority of these requirements

28 B. Pernici, Milano, Maggio 2004 - 28 - Behavior A service has two kinds of behaviors Internal or non-observable behavior External or observable behavior During the composition we have only to consider the external behavior and satisfy related constraints The service could be composed of a simple request/response invocation or could require a more complex interaction If the interface includes different operations the behavior could define the order in which such operations have to be invoked

29 B. Pernici, Milano, Maggio 2004 - 29 - Order really matters Leymann et al, 2001

30 B. Pernici, Milano, Maggio 2004 - 30 - Conversation A service execution requires a correct exchange of messages The process has to satisfy the constraints on the external behavior The state machine model used to describe the service behavior could be also used to describe the process conversation

31 B. Pernici, Milano, Maggio 2004 - 31 - Conversation aspects Transition: Explicit: if it refers to explicit operation invocations Implicit: if it depends on the application logic Timed: if it occurs automatically Compensation: similar to roll-back but from a user perspective and not from a database perspective Resource Locking: e.g. the flight seat Conditions and instance-specific properties: transition may require that certain conditions be verified in order to be enabled

32 B. Pernici, Milano, Maggio 2004 - 32 - Conversation meta-model Transition Name Source Target Activation Mode Event Domain Specific Extension Compensation Type Domain Specific Extension Locking Type L-Resources TL-Resources Cost Domain Specific Extension Pre-conditions O-Condition U-Condition T-Condition Domain Specific Extension Compensation-Transition Name Cost Domain Specific Extension B. Benatallah, F. Casati, F. Toumani, and R. Hamadi, Conceptual Modeling of Service Conversation, Proceedings of CAiSE 2003

33 B. Pernici, Milano, Maggio 2004 - 33 - TRANSAZIONI

34 B. Pernici, Milano, Maggio 2004 - 34 - Transazioni Transactions are a fundamental concept in building reliable distributed applications. mechanism to insure all the participants in an application achieve a mutually agreed outcome. Traditionally, transactions have held the following properties collectively referred to as ACID: Atomicity: If successful, then all the operations happen, and if unsuccessful, then none of the operations happen. Consistency: The application performs valid state transitions at completion. Isolation: The effects of the operations are not shared outside the transaction until it completes successfully Durability: Once a transaction successfully completes, the changes survive failure.

35 B. Pernici, Milano, Maggio 2004 - 35 - Transactional behavior Web services Require the same coordination behavior provided by a traditional transaction mechanism to control the operations of an application Also require more flexible transaction models non-ACID transactions Collaborations, workflow, etc. Grouping of Web services into applications that need some form of correlation but do not necessarily require transactional behavior

36 B. Pernici, Milano, Maggio 2004 - 36 - Supporting reliable transactions WS-Coordination and WS-Transaction support reliable, transactional coordination of Web Services Can be used to extend the BPEL composition model with distributed coordination capability BPEL offers constructs for composing existing Web services WS-Coordination implements coordination types by offering a shared context WS-Transaction defines two coordination types for short- and long-running transactions

37 B. Pernici, Milano, Maggio 2004 - 37 - WS-Coordination A meta-specification, that governs concrete forms of coordination, for example transactions Coordination context: the shared context that is propagated between distributed interacting services (to be included in a SOAP header) Activation service: the service used by clients to create a coordination context Registration service: the service used by participants to register resources (ports) to take part in a coordination protocol Coordination services

38 B. Pernici, Milano, Maggio 2004 - 38 - Web service coordinator Web service coordinator (a) central coordination (b) distributed coordination Copyright Springer Verlag Berlin Heidelberg 2004 Alonso et al 2004

39 B. Pernici, Milano, Maggio 2004 - 39 - Services Activation Service Begins a new activity Specifies the coordination protocols available to the activity Allows the user to specify a relationship between a newly created activity and an existing activity (that is, to establish a subordinate or nested relationship between the activities) Registration Service Allows a Web service to register and to select a protocol for the activity: Enrollment and selection allow the Web services involved in the activity to establish the traditional roles of coordinator and participant The registration process identifies the specific protocol used for activity coordination

40 B. Pernici, Milano, Maggio 2004 - 40 - CreateCoordinationContext -... - coordination type - current context CreateCoordinationContextResponse -... - coordination context - identifier - coordination type - registration service -... ActivationCoordinatorPortType coordinator ActivationRequestorPortType Web service Copyright Springer Verlag Berlin Heidelberg 2004 Alonso et al 2004

41 B. Pernici, Milano, Maggio 2004 - 41 - register -... - protocol identifier - participant protocol service registerResponse -... - coordinator protocol service RegistrationCoordinatorPortType coordinator RegistrationRequestorPortType Web service Copyright Springer Verlag Berlin Heidelberg 2004 Alonso et al 2004

42 B. Pernici, Milano, Maggio 2004 - 42 - Coordination context For each newly created activity, the activation service returns a CoordinationContext that contains the following fields: Identifier: a unique name to identify the CoordinationContext Expires: an activity timeout value CoordinationType: a set of coordination protocols that describe the supported completed processing behaviors Registration Service: address of the registration service; the service is used to register interest and participation in a coordination protocol for determining the outcome of the activity Extensibility element: provides for optional implementation- specific extensions

43 B. Pernici, Milano, Maggio 2004 - 43 - Services Coordination Service Controls the activity completion for the registered Web services using the selected coordination protocol (defined in WS-Transaction) Operations are identified by role For example, for atomic transactions The coordinator provides an interface to the application to direct completion (that is, commit and rollback) The participant provides an interface to the coordinator to direct agreement (that is, prepare, commit, rollback)

44 B. Pernici, Milano, Maggio 2004 - 44 - protocol-specific messages from participant to coordinator protocol-specific messages from coordinator to participant XCoordinatorPortType coordinator XParticipantPortType Web service Copyright Springer Verlag Berlin Heidelberg 2004 Alonso et al 2004

45 B. Pernici, Milano, Maggio 2004 - 45 - Coordinating services 1. Activating a coordination 2. Creating a Coordination Context 3. Propagating context when a service is invoked 4. Registering an invoked service to the coordination protocol by means of the Registration Service located at the port specified within the Coordination Context Coordination Client Activation Service Coordinator Registration Service 2 1 3 4

46 B. Pernici, Milano, Maggio 2004 - 46 - Web service A activation participant registration participant protocol participant coordinator C activation coordinator registration coordinator protocol coordinator Web service B activation participant registration participant protocol participant 1. create CC 2. X1 3. register 4. protocol coordinator 5. operational message 6. register 7. protocol coordinator 8. protocol-specific message 9. protocol-specific message Web service implementation Copyright Springer Verlag Berlin Heidelberg 2004 Alonso et al 2004

47 B. Pernici, Milano, Maggio 2004 - 47 - Web service Acoordinator C a Web service Bcoordinator C b 1. create CC 2. X1 3. register 4. protocol coordinator 5. operational message 6. create CC 7. X2 8. register 9. register 10. protocol coordinator 11. protocol coordinator 12. protocol message 13. protocol message 14. protocol message 15. protocol message Copyright Springer Verlag Berlin Heidelberg 2004 Alonso et al 2004

48 B. Pernici, Milano, Maggio 2004 - 48 - WS-Transaction A standard protocol for long-running transactions (business activities) It also provides a set of specifications for short transactions (atomic transactions) Builds upon WS-Coordination Assumes the existence of coordinators coordinating transactions

49 B. Pernici, Milano, Maggio 2004 - 49 - Protocols for atomic transactions Handle activities that are short-lived Atomic transactions are often referred to as providing a two-phase commitment protocol (atomicity) The transaction scope states that all work must be completed in its entirety (isolation) The results of the activity are available to other users only upon successful completion

50 B. Pernici, Milano, Maggio 2004 - 50 - Protocols for business transactions Handle long-lived activities Activities can take much longer to complete (compensation) Mechanisms for fault and compensation handling are introduced to reverse the affects of previously completed business activities (non-atomicity) The results of interim operations are released before the overall activity has completed Minimizes latency of access by other potential users of the resources used by the activity

51 B. Pernici, Milano, Maggio 2004 - 51 - atomic transaction coordinator CompletionCoordinatorPortType CompletionWithAckCoordinatorPortType PhaseZeroCoordinatorPortType 2PCCoordinatorPortType OutcomeNptificationCoordinatorPortType CompletionParticipantPortType CompletionWithAckParticipantrPortType PhaseZeroParticipantrPortType 2PCParticipantPortType OutcomeNptificationParticipantPortType ActivationCoordinatorPortType RegistrationCoordinatorPortType RegistrationParticipantPortType WS-Coordination interfaces needed for chaining WS-Transaction interfaces WS-Transaction interfaces needed for chaining Copyright Springer Verlag Berlin Heidelberg 2004

52 B. Pernici, Milano, Maggio 2004 - 52 - Web service Acoordinator CaWeb service Bcoordinator Cb create CC T1 register for Completion completion coordinator operational message create CC T2 register for PhaseZero PhaseZero coordinator complete PhaseZero register for 2PC 2PC coordinator register for 2PC PhaseZeroComplete prepare prepared commit committed completed Copyright Springer Verlag Berlin Heidelberg 2004

53 B. Pernici, Milano, Maggio 2004 - 53 - business activity coordinator BusinessAgreementCoordinatorPortType BusinessAgreementWithCompleteCoordinatorPortType BusinessAgreementParticipantPortType BusinessAgreementWithCompleteParticipantrPortType ActivationCoordinatorPortType RegistrationCoordinatorPortType RegistrationParticipantPortType WS-Coordination interfaces needed for chaining WS-Transaction interfaces WS-Transaction interfaces needed for chaining Copyright Springer Verlag Berlin Heidelberg 2004

54 B. Pernici, Milano, Maggio 2004 - 54 - Research at Politecnico di Milano Information systems area VISPO project: e-services in virtual districts MAIS project: e-services in multichannel adaptive information systems

55 B. Pernici, Milano, Maggio 2004 - 55 - VISPO (Virtual district Internet-based Service PlatfOrm) Italian applied project that aims at proposing an architecture supporting the dynamic execution of cooperative processes (2001-2004) Cooperative processes are composed of several services that interact to reach a common goal Aim at propose an architecture which supports the dynamic execution of cooperative process The cooperative process is composed by several Web Services which interact in order to reach a common goal VISPO proposes an architecture that enables a run-time selection of the services Dynamic execution requires a support for the Web substitution at run time Methodology for e-service design

56 B. Pernici, Milano, Maggio 2004 - 56 - MAIS Project Multichannel Adaptive Information Systems Italian basic research project that aims at studying a set of models and methodologies which allows service provisioning through different channels (2002-2005) Web Site: http://www.mais-project.it/http://www.mais-project.it/ WP2: e-service composition Multicanalita Specifica dei servizi Qualità del servizio Invocazione dinamica

57 B. Pernici, Milano, Maggio 2004 - 57 - An approach to Web Service compatibility in cooperative processes Substitutability

58 B. Pernici, Milano, Maggio 2004 - 58 - Cooperative process definition UDDI Analysis of the available Web Services xxxx xxx Cooperative process Cooperative process specification Abs1 Abs2 Abs3Abs4

59 B. Pernici, Milano, Maggio 2004 - 59 - Compatibility class A compatibility class is a set of Web Services which can be mutually substituted by each other The compatibility class is represented by an abstraction of the service which composes the class called abstract service The members of the class is called concrete services

60 B. Pernici, Milano, Maggio 2004 - 60 - Web Service specification Web service is defined in terms of: Interface: provided and exchanged information (WSDL) Behavior: order in the operation execution (WSCL, BPEL4WS) Quality of Service: features like availability, throughput and so on (language under development) Context: semantic information with respect to the environment in which the services operate (Service descriptor) In VISPO we take into account the interface and context

61 B. Pernici, Milano, Maggio 2004 - 61 - Service Descriptor Used in the field of reusable software Can be automatically extracted from the WSDL specification Can be processed by Semantic Analyzer tools as ARTEMIS

62 B. Pernici, Milano, Maggio 2004 - 62 - From WSDL to Descriptor WSDL File … … Service Descriptor SERVICEDeliveringGoods OPERATIONReceiveOrder INPUTorderId INPUTorderDetails OPERATIONMonitor INPUTorderId OUTPUTstatus

63 B. Pernici, Milano, Maggio 2004 - 63 - Our approach For each abstract service, we consider two main phases: High level analysis: we use the service descriptor and the semantic information to obtain a set of possible compatible services Structural analysis: for each selected service, we analyze the structure

64 B. Pernici, Milano, Maggio 2004 - 64 - High level analysis (1) UDDI Abs1 Abs2 Abs3Abs4 Abs1 Abs2 Abs3Abs4

65 B. Pernici, Milano, Maggio 2004 - 65 - The Registry

66 B. Pernici, Milano, Maggio 2004 - 66 - ARTEMIS High level analysis (2) C1.1 Abs1 Service descriptor Service descriptor Similarity evaluation C1.3 Service descriptor Compatibility class (Abs1) Concrete ServiceG Sim C1.31 C.1.10.9 C.1.20.88 C.1.40.75 …… t c = 0.80

67 B. Pernici, Milano, Maggio 2004 - 67 - Structural analysis C1.1 Abs1 Service descriptor Service descriptor WSDL Compatibility class (Abs1) AbstractC1.1 OperationCorres- pondent Affinity ReceiveOrde r Receive0.9 Monitor 1 …… ARTEMIS Similarity evaluation

68 B. Pernici, Milano, Maggio 2004 - 68 - Adaptation

69 B. Pernici, Milano, Maggio 2004 - 69 - Mapping information Used build wrappers to allow service invocation: ReceiveOrder -> Order Structure of parameters Complete missing data XML file passed from compatible service provider to invocation module

70 B. Pernici, Milano, Maggio 2004 - 70 - Behavior A service execution requires a correct exchange of messages The process has to satisfy the constraints on the external behavior state machine model

71 B. Pernici, Milano, Maggio 2004 - 71 - Compatible behavior

72 B. Pernici, Milano, Maggio 2004 - 72 - VISPO Architecture Compatibility Module Compatible Service Provider Registry Orchestration Engine populate control Process instance data e-Services instance data publish e-Services invoke, use Invocation Module adapt exception find Cooperative Process Specifications Terms Ontology retrieve Domain Service Ontology

73 B. Pernici, Milano, Maggio 2004 - 73 - Adaptation Used build wrappers to allow service invocation: ReceiveOrder -> Order Structure of parameters Complete missing data XML file passed from compatible service provider to invocation module Prototipi per la costruzione automatica di wrapper Interazione aggiuntiva con lutente Riconoscimento di servizi comuni a una categoria sulla base di dizionari dei termini (es. orari ferrovari) e costruzione di servizi astratti generici

74 B. Pernici, Milano, Maggio 2004 - 74 - Progettazione in VISPO Progettazione del servizio (include wrapper) Progettazione del processo orchestrato Delega del coordinamento

75 B. Pernici, Milano, Maggio 2004 - 75 - E-service net e orchestration net

76 B. Pernici, Milano, Maggio 2004 - 76 -

77 B. Pernici, Milano, Maggio 2004 - 77 -

78 B. Pernici, Milano, Maggio 2004 - 78 - E-service in MAIS

79 B. Pernici, Milano, Maggio 2004 - 79 - MULTI-CHANNEL information systems Today the services are usually provided by a single- channel We want to provide services through different channels

80 B. Pernici, Milano, Maggio 2004 - 80 - Multi-channel ADAPTIVE information systems

81 B. Pernici, Milano, Maggio 2004 - 81 - Multi-channel ADAPTIVE information systems The client could change the channel, according to available channels, during service exploitation The system could adapt the service provisioning by changing the providing channel, according to the quality of service (QoS) of the available channel

82 B. Pernici, Milano, Maggio 2004 - 82 - M come MOBILE Il contesto nel SI non e piu solo concettuale Non solo web-based Nuovi requisiti, nuove dimensioni progettuali

83 B. Pernici, Milano, Maggio 2004 - 83 -

84 B. Pernici, Milano, Maggio 2004 - 84 -

85 B. Pernici, Milano, Maggio 2004 - 85 - E-service composition platform Interaction enabling platform Reflective Architecture User accessE-service providers E-service directory ic Mapping rules E-Service composition Adaptation rules event MAIS General architecture

86 B. Pernici, Milano, Maggio 2004 - 86 - MAIS - Enhanced service model Besides the classical service model we could consider the context in which the service operates The service context could be defined by (e.g.) The channels The time-zone The location Two models Service provisioning model Service request model Quality of service

87 B. Pernici, Milano, Maggio 2004 - 87 - e-Service model When we consider the e-Service we separate: Application logic (the real e-Service) Presentation logic which depends on the used channel Two different modeling perspectives: Request perspective (user) Provisioning perspective (provider) Includes issues about channels and quality of service

88 B. Pernici, Milano, Maggio 2004 - 88 - e-Service provisioning

89 B. Pernici, Milano, Maggio 2004 - 89 - Compatibility classes To support run-time selection we need compatibility classes A compatibility class is a set of services that can be mutually substituted A compatibility class is represented by an abstraction of the services that compose the class called abstract service The members of the class are called concrete services VISPO and MAIS rely on a set of ontologies, two of them are: Service ontology on which the services are organized in order to create the compatibility class Domain specific ontology which organizes the more relevant concepts in the specific domain

90 B. Pernici, Milano, Maggio 2004 - 90 - Service Ontology GENERALIZATION ASSOCIATIONS EQUIVALENCE UNSPSC category AbstractService Concrete Service Cluster DISJUNCTION UDDI registries Standard taxonomy (UNSPSC ) Abstract Service Concrete Service xxx bbbb Flight Reservation Guides and interpreters Restaurant and catering Travel agents Travel facilitation Travel, Food, Lodging and Entertainment Services a1 a2 a1 a2 Hotel Reservation cccc USHotel ItalianHotel EuropeanHotel USHotel ItalianHotel EuropeanHotel Alitalia Lufthansa AirContinental Alitalia Lufthansa AirContinental cc1 ccc2 cc1 ccc2 zzz yyy aaa xx1 xx2 xxxx3 xx1 xx2 xxxx3

91 B. Pernici, Milano, Maggio 2004 - 91 - e-Service request An Actor (the user): Requests the e-Services Has a profile (preferences) Is in a context The context is defined by: The channel The time-zone The location

92 B. Pernici, Milano, Maggio 2004 - 92 - e-Service request UserProfile User preference Role Expertise Generic preference e-Service Context Channel NetworkDevice Application Protocol 1 1 1 1..n current 1..n 1 is in 1..n 1

93 B. Pernici, Milano, Maggio 2004 - 93 - Context

94 B. Pernici, Milano, Maggio 2004 - 94 - Multi-channel ADAPTIVE information systems t QoS Accepted quality threshold

95 B. Pernici, Milano, Maggio 2004 - 95 - I Processi – Esempio di struttura op1 op2 op3 op1 op2 op3 S1 S2 Servizi S1.op1 S1.op2 S1.op3 S2.op1 S2.op2 S2.op3 PROCESSO

96 B. Pernici, Milano, Maggio 2004 - 96 - I Process – Operazione di Link S1.op1 S1.op2 S1.op3 S2.op1 S2.op2 S2.op3 Ricerca dei servizi e operazione di Link allinizio attraverso il Concretizator per cercare una soluzione ottima. (Link di tutti i servizi) Ricerca del servizio e operazione di Link quando incontro la prima operazione del servizio. Link di un servizio per volta

97 B. Pernici, Milano, Maggio 2004 - 97 - Architettura funzionale MAIS

98 B. Pernici, Milano, Maggio 2004 - 98 - MAIS Reflective Architecture Rappresenta il punto di accesso allo strato riflessivo della piattaforma MAIS. Attraverso di essa è possibile: Osservare e modificare il contesto di esecuzione. Intercettare gli eventi generati dalla piattaforma MAIS. Il contesto di esecuzione è composto da: Canale distributivo (device, network, network interface, protocols). Modello utente (profilo statico, profilo dinamico, localizzazione).

99 B. Pernici, Milano, Maggio 2004 - 99 - User Environment Rappresenta lambiente attraverso il quale lutente dialogherà con la piattaforma MAIS. E caratterizzata dallessere adattiva rispetto al contesto. Attraverso lo user environment è possibile: Ricercare i MAIS Service. Invocare i MAIS Service. Controllare le user activity assegnate allutente dal sistema. Gestire le user activity assegnate.

100 B. Pernici, Milano, Maggio 2004 - 100 - Platform Invocator Rappresenta il punto di accesso della piattaforma MAIS. Attraverso il platform invocator la piattaforma può: Assegnare user activity agli utenti. Essere notificata sullo stato delle user activity assegnate. Attraverso questo modulo, lo user environment può: Ricercare i MAIS Service. Invocare i MAIS Service. Controllare le user activity assegnate allutente dal sistema. Gestire le user activity assegnate.

101 B. Pernici, Milano, Maggio 2004 - 101 - Concrete Service Invocator Rappresenta il modulo che si occupa delle attivazioni dei servizi e dellinvocazione delle loro operazioni. Le funzionalità di questo modulo consentono di: Avviare un MAIS Service. Invocare unoperazione di un servizio concreto. Invocare unoperazione di un servizio astratto. Loperazione più complessa è linvocazione di unoperazione di un servizio astratto poiché comporta una fase preventiva di ricerca di un servizio concreto compatibile.

102 B. Pernici, Milano, Maggio 2004 - 102 - Process Orchestrator Questo modulo possiede la visione complessiva del processo e ne orchestra lesecuzione. Il processo è composto da una serie di operazioni astratte ed è descritto da un opportuno linguaggio nel quale viene specificato il flusso delle informazioni. Una volta decisa loperazione astratta da invocare, il process orchestrator utilizza il concrete service invocator per portare a termine la chiamata. Prima della fase di invocazione è necessaria loperazione di link che permette di associare un servizio astratto ad un servizio concreto.

103 B. Pernici, Milano, Maggio 2004 - 103 - Concretizator Permette di ottimizzare lesecuzione del processo. Prima di iniziare lesecuzione del processo, il concretizator si occupa di selezionare i servizi concreti che verranno utilizzati a run-time. La selezione dei servizi concreti avviene tendo conto di vincoli globali sulle proprietà che devono essere rispettate dal processo.

104 B. Pernici, Milano, Maggio 2004 - 104 - Process Evolution Rappresenta il modulo utilizzato per la modifica dinamica del processo. Le funzionalità di questo modulo permettono di: Partizionare un processo. Sostituire un servizio astratto con la composizione di altri due o più servizi astratti. La composizione di servizi ottenuta modificherà la topologia del processo ma non il suo comportamento.

105 B. Pernici, Milano, Maggio 2004 - 105 - Transaction Manager Questo modulo assiste il process orchestrator nella gestione delle transazioni. Il funzionamento di questo modulo si basa sul protocollo 2PC (Two Phase Commit) proposto nel campo delle basi di dati.

106 B. Pernici, Milano, Maggio 2004 - 106 - Recommender Permette di stimare il grado di affinità di un servizio rispetto alle preferenze e i gusti dellutente che lo ha invocato relativamente ai parametri extra- funzionali. Il suo funzionamento è basato sullinterpretazione delle informazioni contenute nel profilo utente (statico e dinamico). E di supporto al concrete service invocator nella scelta dei servizi concreti compatibili rispetto ad un servizio astratto. Riceve in ingresso la lista dei servizi concreti trovati e la restituisce ordinata in base al valore di affinità che i singoli servizi hanno rispetto ai gusti dellutente.

107 B. Pernici, Milano, Maggio 2004 - 107 - Catcher Permette di modificare dinamicamente il profilo utente. Le modifiche vengono fatte analizzando le richieste di invocazioni dei servizi fatte da ogni singolo utente. Le richieste sono analizzate catturando gli eventi generati dal concrete service invocator durante la fase di invocazione dei MAIS Service o delle operazioni dei servizi.

108 B. Pernici, Milano, Maggio 2004 - 108 - Negotiator Questo modulo permette di gestire la fase di negoziazione dei servizi concreti. Fornisce un supporto al concrete service invocator ogni volta che linvocazione di unoperazioni su di un particolare servizio concreto richiede una fase iniziale di negoziazione.

109 B. Pernici, Milano, Maggio 2004 - 109 - MAIS Registry – Le informazioni contenute E il registry allinterno del quale sono contenute tutte le informazioni necessarie al funzionamento della piattaforma MAIS. Le principali informazioni contenute riguardano: I servizi astratti. I servizi concreti semplici. I servizi concreti complessi. Ontologia dei servizi. Ontologia di dominio. Si compone di diversi moduli.

110 B. Pernici, Milano, Maggio 2004 - 110 - MAIS Registry – I moduli (1) Semantic Publisher: Utilizzato per gestire la pubblicazione dei MAIS Service. Aggiorna automaticamente lontologia di dominio e quella dei servizi. Match Maker: Utilizzato per ricercare MAIS Service compatibili rispetto ad un servizio astratto. La compatibilità viene calcolata analizzando aspetti funzionali e comportamentali. Gli aspetti comportamentali sono valutati utilizzando il behavioral compatibility engine.

111 B. Pernici, Milano, Maggio 2004 - 111 - MAIS Registry – I moduli (2) Behavioral Compatibility Engine: Permette di verificare se il protocollo (sequenze di messaggi) supportato da un servizio astratto è supportato anche da altri servizi candidati alla sua sostituzione. Supporta il match maker nelle sue ricerche. Service Ontology: contiene lontologia dei servizi. Domain Ontology: contiene lontologia del dominio.

112 B. Pernici, Milano, Maggio 2004 - 112 - Wrapper Il process orchestrator formatta i parametri delle operazioni secondo le specifiche astratte mentre il concrete service invocator usa le formattazioni descritte nelle specifiche dei servizi concreti. I wrapper sono utilizzati dal concrete service invocator per trasformare i parametri astratti in parametri concreti e viceversa.

113 B. Pernici, Milano, Maggio 2004 - 113 - Web Service Implementations Rappresentano le implementazioni concrete dei servizi. Ogni servizio è teoricamente disponibile allinterno della piattaforma MAIS ma non è detto che al momento della sua invocazione sia realmente disponibile.

114 B. Pernici, Milano, Maggio 2004 - 114 - Attivazione e utilizzo di un servizio concreto semplice

115 B. Pernici, Milano, Maggio 2004 - 115 - Attivazione e utilizzo di un servizio concreto complesso

116 B. Pernici, Milano, Maggio 2004 - 116 - Invocazione di unoperazione di un servizio astratto

117 B. Pernici, Milano, Maggio 2004 - 117 - Invocazione di unoperazione di un servizio astratto con attività

118 B. Pernici, Milano, Maggio 2004 - 118 - I linguaggi della piattaforma MAIS Allinterno della piattaforma MAIS sono presenti due tipologie di linguaggi. Linguaggi per la descrizione dei servizi nel repository: utilizzati per descrivere gli aspetti dei servizi presenti allinterno del MAIS Registry. Linguaggi per la composizione dei servizi: utilizzati per descrivere il processo (flusso informativo, sostituzione servizi, scomposizione processo).

119 B. Pernici, Milano, Maggio 2004 - 119 - Linguaggi per i servizi Linguaggio per linterfaccia funzionale (astratto–concreto) (Lif-Lf). Linguaggio per la qualità del servizio (astratto-concreto) (Liq- Lq). Linguaggio per le pre-post condizioni del servizio (astratto- concreto). Linguaggio per la negoziazione del servizio (astratto- concreto). Linguaggio per il behavior del servizio (astratto). Linguaggio per la descrizione semantica del servizio (astratto) (Lo). Linguaggio per la descrizione dei canali di un servizio (astratto).

120 B. Pernici, Milano, Maggio 2004 - 120 - Ereditarietà dei linguaggi per i servizi Relazioni tra due servizi astratti: Un servizio astratto A può essere messo in relazione con un servizio astratto B. Il servizio A può avere funzionalità analoghe a quelle del servizio B ed eventualmente aggiungerne altre. Relazioni tra un servizio astratto ed uno concreto: Un servizio concreto A può implementare un servizio astratto B. Il servizio A eredita quanto definito per il servizio B e specifica ulteriormente la descrizione del servizio aggiungendo descrizioni riferite ad aspetti concreti.

121 B. Pernici, Milano, Maggio 2004 - 121 - Linguaggi per il processo Linguaggio per la descrizione del flusso del processo (BPEL-MEL) (Lwf). Linguaggio per la descrizione della composizione- decomposizione del processo. Linguaggio per descrivere le proprietà transazionali del processo. Linguaggio per descrivere le modalità di selezione dei servizi concreti (MEL).

122 B. Pernici, Milano, Maggio 2004 - 122 - Caratteristiche di MEL Attraverso questo linguaggio deve essere possibile indirizzare il funzionamento del concrete service invocator per: Selezionare i servizi concreti da sostituire ai servizi astratti. Decidere le politiche di link-unlink. Questo linguaggio deve essere integrato con il linguaggio per il controllo del flusso.

123 B. Pernici, Milano, Maggio 2004 - 123 - Sostituzione dei servizi Ad ogni servizio astratto sono associati dei vincoli che indirizzano la scelta del servizio concreto da parte del concrete service invocator. I vincoli fanno riferimento a quanto specificato attraverso i linguaggi di descrizione dei servizi. Mediante questo linguaggio è possibile: Selezionare direttamente uno o più servizi concreti. Esprimere vincoli sulla qualità dei parametri dei servizi concreti (localizzazione, banda di comunicazione, ecc...). Esprimere vincoli sui valori di affinità tra le interfacce funzionali dei servizi. Esprimere vincoli sulle pre-post condizioni. Esprimere vincoli sui meccanismi di negozione e sicurezza supportati. Esprimere vincoli sulle tipologie di canali utilizzati.

124 B. Pernici, Milano, Maggio 2004 - 124 - Politiche di link-unlink Loperazione di link può essere fatta in due modi: Per ogni servizio, prima di iniziare lesecuzione del processo (Concretizator). Durante lesecuzione del processo. Un servizio astratto viene legato ad un servizio concreto quando ne viene invocata la prima operazione. prima dellinvocazione Loperazione di unlink può avvenire avvenire : Su richiesta del process orchestrator. Alla fine dellesecuzione per i servizi astratti non ancora scollegati.

125 B. Pernici, Milano, Maggio 2004 - 125 - Esempi Set di servizi concreti Gestione link globale Trenitalia FerrovieNord prenotazioneTreni...

126 B. Pernici, Milano, Maggio 2004 - 126 - Esempi Gestione link singola con unlink prenotazioneTreni...............

127 B. Pernici, Milano, Maggio 2004 - 127 - Old wine in new bottles? … An interesting paper by van der Aalst, Dumas and ter Hofstede Very often, the proposed languages recall concepts of WfMSs In some cases, composition languages are more expressive than traditional WfMSs Explicit support for basic communication patterns Correlation sets Exception handling Context awareness … Little efforts have been however devoted to evaluating their real advantages and limitations

128 B. Pernici, Milano, Maggio 2004 - 128 - What to investigate for Some aspects need to be systematically investigated: Expressiveness Adequacy Orthogonality Formal characterization (reachability) Design methods

129 B. Pernici, Milano, Maggio 2004 - 129 - References – part 1 G. Alonso, F. Casati, H. Kuno, V. Machiraju. Web Services. Concepts, Architectures and Applications. Springer Verlag, 2003. BPEL4WS. www-106.ibm.com/developerworks/webservices/ library/ws-bpel/ W.M.P. van der Aalst, M. Dumas and A.H.M. ter Hofstede. Web service composition languages: Old Wine in New Bottles? Proc, of EuroMicro03 Conference R. Khalaf, F. Leymann, On Web Services Aggregation, Proceedings of VLDB-TES 2003 Workshop. B. Benatallah, F. Casati, F. Toumani, and R. Hamadi, Conceptual Modeling of Service Conversation, Proceedings of CAiSE 2003, LNCS 2681, pp-449-467 C. Peltz, Web services orchestration and choreography, Computer, Oct. 2003

130 B. Pernici, Milano, Maggio 2004 - 130 - References – part 2 F. Curbera, R. Khalaf, N. Mukhi, S. Tai, and S. Weerawarana, The Next Step in Web Service, Communications of the ACM, October 2003, vol. 46, no. 10 M.P. Papazoglou, D. Georgakopoulos, Service-oriented computing, CACM, Oct. 2003 F. Casati, E. Sham, U. Dayal, M-C. Shan, Business-oriented management of web services, CACM, Oct. 2003 T. Freund and T. Storey, Transactions in the world of Web services, Part 1: An overview of WS-Transaction WS-Coordination. www- 106.ibm.com/developerworks/library/ws-wstx1/ John Krogstie, Kalle Lyytinen, Andreas Opdahl, Barbara Pernici, Keng Siau, Kari Smolander, Research Areas and Challenges for Mobile Information Systems, accettato per la pubblicazione su International Journal of Mobile Communication F. Leymann, D. Roller, and M.-T. Schmidt, Web services and business process management, IBM Systems Journal, 2001

131 B. Pernici, Milano, Maggio 2004 - 131 - References – part 3 Enzo Colombo, Chiara Francalanci, Barbara Pernici, Pierluigi Plebani, Massimo Mecella, Valeria De Antonellis, Michele Melchiori: Cooperative Information Systems in Virtual Districts: the VISPO Approach. IEEE Data Engineering Bulletin 25(4): 36-40 (2002) M. Mecella, B. Pernici: Designing Wrapper Components for e-Services in Integrating Heterogeneous Systems. VLDB Journal, Special Issue on e-Services 2-15 (2001) L. Baresi, D. Bianchini, V. De Antonellis, M.G. Fugini, B. Pernici, and P. Plebani, Context-aware Composition of E-Services, TES workshop, Berlin, Sept. 2003 Andrea Maurino, Stefano Modafferi, Barbara Pernici, Reflective architectures for adaptive information systems, ICSOC 2003:115-131 Massimo Mecella and Barbara Pernici, Building Flexible and Cooperative Applications, Based on e-Services, subm. IEEE TSE Devis Bianchini, Valeria De Antonellis, Pierluigi Plebani, Barbara Pernici, Ontology based methodology for e-Service discovery, subm. Information Systems

132 B. Pernici, Milano, Maggio 2004 - 132 - Credits Parte del materiale e stato elaborato da L. Baresi, M. Matera, P. Plebani, E. Mussi, M. Mecella