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

B. Pernici, Milano, Maggio 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

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

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

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

B. Pernici, Milano, Maggio

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

B. Pernici, Milano, Maggio ALTRI LINGUAGGI

B. Pernici, Milano, Maggio 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

B. Pernici, Milano, Maggio Technology stack

B. Pernici, Milano, Maggio 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

B. Pernici, Milano, Maggio APPROCCI ALLA PROGETTAZIONE

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

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

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

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

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

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

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

B. Pernici, Milano, Maggio 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)

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

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

B. Pernici, Milano, Maggio 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

B. Pernici, Milano, Maggio 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

B. Pernici, Milano, Maggio 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

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

B. Pernici, Milano, Maggio 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

B. Pernici, Milano, Maggio 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

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

B. Pernici, Milano, Maggio 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

B. Pernici, Milano, Maggio 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

B. Pernici, Milano, Maggio 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

B. Pernici, Milano, Maggio TRANSAZIONI

B. Pernici, Milano, Maggio 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.

B. Pernici, Milano, Maggio 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

B. Pernici, Milano, Maggio 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

B. Pernici, Milano, Maggio 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

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

B. Pernici, Milano, Maggio 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

B. Pernici, Milano, Maggio 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

B. Pernici, Milano, Maggio 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

B. Pernici, Milano, Maggio 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

B. Pernici, Milano, Maggio 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)

B. Pernici, Milano, Maggio 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

B. Pernici, Milano, Maggio 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

B. Pernici, Milano, Maggio 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

B. Pernici, Milano, Maggio 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

B. Pernici, Milano, Maggio 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

B. Pernici, Milano, Maggio 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

B. Pernici, Milano, Maggio 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

B. Pernici, Milano, Maggio 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

B. Pernici, Milano, Maggio 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

B. Pernici, Milano, Maggio 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

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

B. Pernici, Milano, Maggio VISPO (Virtual district Internet-based Service PlatfOrm) Italian applied project that aims at proposing an architecture supporting the dynamic execution of cooperative processes ( ) 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

B. Pernici, Milano, Maggio 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 ( ) Web Site: WP2: e-service composition Multicanalita Specifica dei servizi Qualità del servizio Invocazione dinamica

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

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

B. Pernici, Milano, Maggio 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

B. Pernici, Milano, Maggio 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

B. Pernici, Milano, Maggio 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

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

B. Pernici, Milano, Maggio 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

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

B. Pernici, Milano, Maggio The Registry

B. Pernici, Milano, Maggio 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 C C …… t c = 0.80

B. Pernici, Milano, Maggio 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

B. Pernici, Milano, Maggio Adaptation

B. Pernici, Milano, Maggio 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

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

B. Pernici, Milano, Maggio Compatible behavior

B. Pernici, Milano, Maggio 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

B. Pernici, Milano, Maggio 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

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

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

B. Pernici, Milano, Maggio

B. Pernici, Milano, Maggio

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

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

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

B. Pernici, Milano, Maggio 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

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

B. Pernici, Milano, Maggio

B. Pernici, Milano, Maggio

B. Pernici, Milano, Maggio 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

B. Pernici, Milano, Maggio 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

B. Pernici, Milano, Maggio 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

B. Pernici, Milano, Maggio e-Service provisioning

B. Pernici, Milano, Maggio 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

B. Pernici, Milano, Maggio 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

B. Pernici, Milano, Maggio 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

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

B. Pernici, Milano, Maggio Context

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

B. Pernici, Milano, Maggio 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

B. Pernici, Milano, Maggio 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

B. Pernici, Milano, Maggio Architettura funzionale MAIS

B. Pernici, Milano, Maggio 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).

B. Pernici, Milano, Maggio 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.

B. Pernici, Milano, Maggio 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.

B. Pernici, Milano, Maggio 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.

B. Pernici, Milano, Maggio 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.

B. Pernici, Milano, Maggio 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.

B. Pernici, Milano, Maggio 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.

B. Pernici, Milano, Maggio 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.

B. Pernici, Milano, Maggio 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.

B. Pernici, Milano, Maggio 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.

B. Pernici, Milano, Maggio 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.

B. Pernici, Milano, Maggio 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.

B. Pernici, Milano, Maggio 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.

B. Pernici, Milano, Maggio 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.

B. Pernici, Milano, Maggio 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.

B. Pernici, Milano, Maggio 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.

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

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

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

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

B. Pernici, Milano, Maggio 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).

B. Pernici, Milano, Maggio 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).

B. Pernici, Milano, Maggio 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.

B. Pernici, Milano, Maggio 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).

B. Pernici, Milano, Maggio 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.

B. Pernici, Milano, Maggio 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.

B. Pernici, Milano, Maggio 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.

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

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

B. Pernici, Milano, Maggio 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

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

B. Pernici, Milano, Maggio References – part 1 G. Alonso, F. Casati, H. Kuno, V. Machiraju. Web Services. Concepts, Architectures and Applications. Springer Verlag, 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 C. Peltz, Web services orchestration and choreography, Computer, Oct. 2003

B. Pernici, Milano, Maggio 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 F. Casati, E. Sham, U. Dayal, M-C. Shan, Business-oriented management of web services, CACM, Oct 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

B. Pernici, Milano, Maggio 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): (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 Andrea Maurino, Stefano Modafferi, Barbara Pernici, Reflective architectures for adaptive information systems, ICSOC 2003: 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

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