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

Coordinamento di e-serviceCoordinamento di e-serviceArgomenti di ricercaArgomenti di ricerca

B. PerniciB. Pernici

Politecnico di MilanoPolitecnico di MilanoDipartimento di Elettronica e Dipartimento di Elettronica e

InformazioneInformazione

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

OutlineOutline

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


GESTIONE DI E-SERVICEGESTIONE DI E-SERVICE


Extended SOAExtended SOA

Papazoglou, CACM ott. 2003


Managed servicesManaged services

Casati et al, 2003, CACM


New interfaces for e-servicesNew interfaces for e-services

E-service e port type funzionali

Port type di gestione

Leymann, 2004


ALTRI LINGUAGGIALTRI LINGUAGGI


Further dimensionsFurther 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


Technology stackTechnology stack


How many standards do we need?How many standards do we need?

WSCIBPEL4WS

WS-Transaction

WS-Security

BPMLDAML-S

WSXLWS-Coordination

WS-I

WSFL

XLANG

WS-Policy

WSLA

WSRP

WSCL


APPROCCI ALLA PROGETTAZIONEAPPROCCI ALLA PROGETTAZIONE


CollaborationCollaboration

Orchestrazione e coreografia Protocolli di coordinamento


Composition modelsComposition models

Orchestration Intra-process Process controlled by one

party

Choreography Inter-processes Sequence of observable

messages Conversation among equals


ExampleExample

Casati et al., CACM 2003


Conversation or choreography?Conversation or choreography?

Peltz, Computer 2003


Modeling conversationsModeling conversations

State diagrams Interaction diagrams Sequence diagrams Activity diagram

Rif. Alonso et al, 2004


Come progettare un processoCome progettare un processo

Viste sui processi Progettazione bottom-up e top-down


Vista privata e vista pubblica dei Vista privata e vista pubblica dei processiprocessi

Leymann, 2001


Activities and servicesActivities 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)


Bottom-upBottom-up

Where does the

travel take place?

ACMETravel Agency

US Hotel Reservation

European Hotel Reservation


Top downTop down

Where does the

travel take place?

ACMETravel Agency

US Hotel Reservation

European Hotel Reservation


Associations depend onAssociations 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


Back-tracking planningBack-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


Service directoryService 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


Service modelsService models

Matchmaking mechanism necessarily relies on a specific service models

A classical model involves Interface Behavior Quality


InterfaceInterface

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


BehaviorBehavior

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


Order really mattersOrder really matters

Leymann et al, 2001


ConversationConversation

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


Conversation aspectsConversation 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


Conversation meta-modelConversation meta-model

Transition

NameSourceTarget

Activation

ModeEventDomain Specific Extension

Compensation

TypeDomain Specific Extension

Locking

TypeL-ResourcesTL-ResourcesCostDomain Specific Extension

Pre-conditions

O-ConditionU-ConditionT-ConditionDomain Specific Extension

Compensation-Transition

NameCostDomain Specific Extension

B. Benatallah, F. Casati, F. Toumani, and R. Hamadi, Conceptual Modeling of Service Conversation, Proceedings of CAiSE 2003


TRANSAZIONITRANSAZIONI


TransazioniTransazioni

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.


Transactional behaviorTransactional 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


Supporting reliable transactionsSupporting 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


WS-CoordinationWS-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


Web service Web service Web service

coordinator coordinator coordinator

Web service Web service Web service

coordinator

(a) central coordination

(b) distributed coordination

Copyright Springer Verlag Berlin Heidelberg 2004

Alonso et al 2004


ServicesServices

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 relationshipbetween 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


CreateCoordinationContext - ... - coordination type - current context CreateCoordinationContextResponse

- ... - coordination context - identifier - coordination type - registration service - ...ActivationCoordinatorPortType

coordinator

ActivationRequestorPortType

Web service


Alonso et al 2004


register - ... - protocol identifier - participant protocol service

registerResponse - ... - coordinator protocol service

RegistrationCoordinatorPortType

coordinator

RegistrationRequestorPortType

Web service


Alonso et al 2004


Coordination contextCoordination 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 ina coordination protocol for determining the outcome of the activity

Extensibility element: provides for optional implementation-specific extensions


ServicesServices

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 applicationto direct completion (that is, commit and rollback)

The participant provides an interface to the coordinatorto direct agreement (that is, prepare, commit, rollback)


protocol-specific messagesfrom participant to coordinator

protocol-specific messagesfrom coordinator to participant

XCoordinatorPortType

coordinator

XParticipantPortType

Web service


Alonso et al 2004


Coordinating servicesCoordinating services

1. Activating a coordination2. Creating a Coordination Context

<GlobalID, ExpirationDate, RegistrationService Port,... >

3. Propagating context when a service is invoked4. Registering an invoked service to the coordination protocol

by means of the Registration Service located at the port specified within the Coordination Context

<Request>Coordination Client

Activation Service

<Context>

Coordinator

RegistrationService<Registration>

<Context>

2

1

3

4


Web service A

activation

participant registratio

nparticipan

t

protocolparticipa

nt

coordinator C

activationcoordinator

registrationcoordinator

protocolcoordinator

Web service B

activationparticipant

registrationparticipant

protocolparticipant

1. create CC

2. X1

3. register

4. protocol coordinator

5. operational message

6. register

7. protocol coordinator8. protocol-specific message

9. protocol-specific message

Web service implementat

ion

Web service implementat

ion


Alonso et al 2004


Web service A coordinator Ca Web service B coordinator Cb

1. create CC

2. X1

3. register


5. operational message

6. create CC

7. X2

8. register

9. register



12. protocol message13. protocol message

14. protocol message

15. protocol message


Alonso et al 2004


WS-TransactionWS-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


Protocols for atomic transactionsProtocols for atomic transactions

Handle activities that are short-lived Atomic transactions are often referred to as

providinga 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


Protocols for business transactionsProtocols 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


atomic transactioncoordinator

CompletionCoordinatorPortType

CompletionWithAckCoordinatorPortType

PhaseZeroCoordinatorPortType

2PCCoordinatorPortType

OutcomeNptificationCoordinatorPortType

CompletionParticipantPortType

CompletionWithAckParticipantrPortType

PhaseZeroParticipantrPortType

2PCParticipantPortType

OutcomeNptificationParticipantPortType

ActivationCoordinatorPortTypeRegistrationCoordinatorPortType

RegistrationParticipantPortType

WS-Coordination interfaces

WS-Coordination interfacesneeded for chaining

WS-Transaction interfaces

WS-Transaction interfacesneeded for chaining



Web service A coordinator Ca Web service B coordinator Cb

create CC

T1

register for Completion

completion coordinator

operational message

create CC

T2

register for PhaseZero

register for PhaseZero

PhaseZero coordinator

PhaseZero coordinator

completePhaseZero

PhaseZero

register for 2PC

2PC coordinator

2PC coordinator

register for 2PC

PhaseZeroComplete

PhaseZeroComplete

prepare

prepare

prepared

prepared

commit

Cop

yrig

ht

Sp

rin

ger

Ver

lag

Ber

lin

Hei

del

ber

g 20

04


business activitycoordinator

BusinessAgreementCoordinatorPortType

BusinessAgreementWithCompleteCoordinatorPortType

BusinessAgreementParticipantPortType

BusinessAgreementWithCompleteParticipantrPortType

ActivationCoordinatorPortTypeRegistrationCoordinatorPortType

RegistrationParticipantPortType

WS-Coordination interfaces

WS-Coordination interfacesneeded for chaining

WS-Transaction interfaces

WS-Transaction interfacesneeded for chaining



Research at Politecnico di MilanoResearch at Politecnico di Milano

Information systems area

VISPO project: e-services in virtual districts MAIS project: e-services in multichannel adaptive

information systems


VISPO VISPO (Virtual district Internet-based Service (Virtual district Internet-based Service PlatfOrm)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


MAIS ProjectMAIS ProjectMultichannel Adaptive Information Multichannel Adaptive Information SystemsSystems 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/ WP2: e-service composition

Multicanalita’ Specifica dei servizi Qualità del servizio Invocazione dinamica


An approach to Web Service An approach to Web Service compatibility in cooperative compatibility in cooperative processesprocessesSubstitutabilitySubstitutability


Cooperative process definitionCooperative process definition

UDDI

Analysis of the available Web Services

xxxx

xxxx

xxx

xxxxxx

Cooperative process

Cooperative process specification

Abs1

Abs2

Abs3 Abs4


Compatibility classCompatibility 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


Web Service specificationWeb 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


Service DescriptorService 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


From WSDL to DescriptorFrom WSDL to Descriptor

WSDL File<wsdl>…<portType DeliveringGoods>

<operation name=“ReceiveOrder”><input message=“orderId”/><input

message=“orderDetails”/></operation><operation name=“Monitor”>

<input message=“orderId”/><output message=“status”/>

</operation></portType>…</wsdl>

Service DescriptorSERVICE DeliveringGoodsOPERATION ReceiveOrder

INPUT orderIdINPUT orderDetails

OPERATION MonitorINPUT orderIdOUTPUT status


Our approachOur 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


High level analysis (1)High level analysis (1)

UDDIAbs1

Abs2

Abs3 Abs4

Abs1

Abs2Abs3

Abs4


The RegistryThe Registry

businessentity

businessservice

bindingtemplate

tModel

tModel

tModel

WSDLService Implementation

descriptor

WSDL(abstract service)

descriptor

WSDLService Interface

UDDIRegistry

Descriptorbase

refers to

generates

generates

e-Service


ARTEMIS

High level analysis (2)High level analysis (2)

C1.1

Abs1

Servicedescriptor

Servicedescriptor

Similarityevaluation

C1.3

Servicedescriptor

Compatibility class (Abs1)

Concrete Service GSim

C1.3 1

C.1.1 0.9

C.1.2 0.88

C.1.4 0.75

… …

tc= 0.80


Structural analysisStructural analysis

C1.1

Abs1

Servicedescriptor

Servicedescriptor

WSDL

WSDL

Compatibility class (Abs1)

Abstract C1.1

Operation Corres-pondent

Affinity

ReceiveOrder

Receive 0.9

Monitor Monitor 1

… …ARTEMIS

Similarityevaluation


AdaptationAdaptation


Mapping informationMapping 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


BehaviorBehavior

A service execution requires a correct exchange of messages

The process has to satisfy the constraints on the external behavior

state machine model


Compatible behaviorCompatible behavior


VISPO ArchitectureVISPO Architecture

CompatibilityModule

CompatibleServiceProvider

Registry

OrchestrationEngine

populate

control

Processinstance data

e-Servicesinstance data

publish

e-Services

invoke, use

InvocationModule

adapt

exception

find

CooperativeProcess

Specifications

TermsOntology

retrieve

retrieve

retrieve

DomainService

Ontology


AdaptationAdaptation

•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 l’utente

•Riconoscimento di servizi comuni a una categoria sulla base di dizionari dei termini (es. orari ferrovari) e costruzione di servizi astratti generici


Progettazione in VISPOProgettazione in VISPO

Progettazione del servizio (include wrapper) Progettazione del processo orchestrato Delega del coordinamento


E-service net e orchestration net E-service net e orchestration net


E-service in MAISE-service in MAIS


MULTI-CHANNELMULTI-CHANNELinformation systemsinformation systems

Today the services are usually provided by a single-channel

We want to provide services through different channels


Multi-channel ADAPTIVE information Multi-channel ADAPTIVE information systemssystems



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


M come MOBILEM come MOBILE

Il contesto nel SI non e’ piu’ solo concettuale Non solo web-based Nuovi requisiti, nuove dimensioni progettuali


E-service composition platform

Interaction enabling platform

Reflective Architecture

User access E-service providers

E-servicedirectory

i cMa

Mapping rules

E-Servicecomposition

Adaptation rules

event

MAIS General architectureMAIS General architecture


MAIS - Enhanced service modelMAIS - 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


e-Service modele-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


e-Service provisioninge-Service provisioning

FunctionalDescription

1..n

1..n

1

PQualityDimension

ServiceProvider

Channel

CQualityDimension

CompositeEService

EService

AbstractEService

CompatibilityClass

has associated1

1..n1..n

1..n

1..n

1..n

Provisioning Functional decomposition

Post-Condition

Pre-condition

Operation

OutputInput

Event

1..n

1..n

1..n

1..n

1

1

1

1

1..n

1..n

1..n 1..n

1 1

input output

1

1

1..n

1

1


Compatibility classesCompatibility 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


Service OntologyService Ontology

GENERALIZATION

ASSOCIATIONS

EQUIVALENCE

UNSPSC category

AbstractService

Concrete Service Cluster

DISJUNCTION

UDDI registries

Standard taxonomy(UNSPSC )

AbstractService

ConcreteService

xxxxxx

bbbbbbbb

Flight ReservationFlight Reservation

Guides and interpretersRestaurant and catering

Travel agents

Travel facilitationTravel , Food, Lodging and Entertainment Services

a1a2a1a2

Hotel ReservationHotel Reservation

cccccccc

USHotelItalianHotel

EuropeanHotel

USHotelItalianHotel

EuropeanHotel

AlitaliaLufthansa

AirContinental

AlitaliaLufthansa

AirContinental

cc1ccc2cc1ccc2

zzzzzz

yyyyyy aaa

aaa

xx1xx2

xxxx3

xx1xx2

xxxx3


e-Service requeste-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


e-Service requeste-Service request

UserProfileUser

preference

RoleExpertiseGeneric

preference

e-Service

Context

Channel

NetworkDeviceApplication

Protocol

1

1 1

1..n1..n

1..n

1..n

1..n

current

1..n

1

is in

1..n

1..n

1..n1..n

11..n

1..n


ContextContext

Channel

InputDevice

Memory

Device

Application

DisplayCPU

OperatingSystem

Network

ApplicationProtocol

1..n

1..n1..n

1

1

1

1..n

1

1..n 1..n

1..n 1

Context

CountryDistrict

Town

PropertyLocation

GeoPosition

Time Zone

1..n

1

1..n

1..n

11..n

1..n

0..n

0..n

0..n

0..n

1..n

1..n



t

QoS

Accepted quality threshold


I Processi – Esempio di strutturaI 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


I Process – Operazione di LinkI Process – Operazione di Link

S1.op1

S1.op2

S1.op3

S2.op1

S2.op2

S2.op3

Ricerca dei servizi e operazione di Link all’inizio 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


Architettura funzionale MAISArchitettura funzionale MAIS


MAIS Reflective ArchitectureMAIS 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).


User EnvironmentUser Environment

Rappresenta l’ambiente attraverso il quale l’utente dialogherà con la piattaforma MAIS.

E’ caratterizzata dall’essere adattiva rispetto al contesto.

Attraverso lo user environment è possibile:

Ricercare i MAIS Service. Invocare i MAIS Service. Controllare le user activity assegnate

all’utente dal sistema. Gestire le user activity assegnate.


Platform InvocatorPlatform 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 all’utente dal

sistema. Gestire le user activity assegnate.


Concrete Service InvocatorConcrete Service Invocator Rappresenta il modulo che si

occupa delle attivazioni dei servizi e dell’invocazione delle loro operazioni.

Le funzionalità di questo modulo consentono di:

Avviare un MAIS Service. Invocare un’operazione di un servizio

concreto. Invocare un’operazione di un servizio

astratto.

L’operazione più complessa è l’invocazione di un’operazione di un servizio astratto poiché comporta una fase preventiva di ricerca di un servizio concreto compatibile.


Process OrchestratorProcess Orchestrator

Questo modulo possiede la visione complessiva del processo e ne orchestra l’esecuzione.

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 l’operazione astratta da invocare, il process orchestrator utilizza il concrete service invocator per portare a termine la chiamata.

Prima della fase di invocazione è necessaria l’operazione di link che permette di associare un servizio astratto ad un servizio concreto.


ConcretizatorConcretizator

Permette di ottimizzare l’esecuzione del processo.

Prima di iniziare l’esecuzione 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.


Process EvolutionProcess 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.


Transaction ManagerTransaction 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.


RecommenderRecommender

Permette di stimare il grado di affinità di un servizio rispetto alle preferenze e i gusti dell’utente che lo ha invocato relativamente ai parametri extra-funzionali.

Il suo funzionamento è basato sull’interpretazione 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 dell’utente.


CatcherCatcher

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.


NegotiatorNegotiator

Questo modulo permette di gestire la fase di negoziazione dei servizi concreti.

Fornisce un supporto al concrete service invocator ogni volta che l’invocazione di un’operazioni su di un particolare servizio concreto richiede una fase iniziale di negoziazione.


MAIS Registry – Le informazioni MAIS Registry – Le informazioni contenutecontenute

E’ il registry all’interno 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.


MAIS Registry – I moduli (1)MAIS Registry – I moduli (1)

Semantic Publisher: Utilizzato per gestire la pubblicazione

dei MAIS Service. Aggiorna automaticamente

l’ontologia 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.


MAIS Registry – I moduli (2)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 l’ontologia dei servizi.

Domain Ontology: contiene l’ontologia del dominio.


WrapperWrapper

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.


Web Service ImplementationsWeb Service Implementations

Rappresentano le implementazioni concrete dei servizi.

Ogni servizio è teoricamente disponibile all’interno della piattaforma MAIS ma non è detto che al momento della sua invocazione sia realmente disponibile.


Attivazione e utilizzo di un servizio Attivazione e utilizzo di un servizio concreto sempliceconcreto semplice


Attivazione e utilizzo di un servizio Attivazione e utilizzo di un servizio concreto complessoconcreto complesso


Invocazione di un’operazione di un Invocazione di un’operazione di un servizio astrattoservizio astratto


Invocazione di un’operazione di un Invocazione di un’operazione di un servizio astratto con attivitàservizio astratto con attività


I linguaggi della piattaforma MAISI linguaggi della piattaforma MAIS

All’interno 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 all’interno del MAIS Registry.

Linguaggi per la composizione dei servizi: utilizzati per descrivere il processo (flusso informativo, sostituzione servizi, scomposizione processo).


Linguaggi per i serviziLinguaggi per i servizi

Linguaggio per l’interfaccia 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).


Ereditarietà dei linguaggi per i serviziEreditarietà 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.


Linguaggi per il processoLinguaggi 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).


Caratteristiche di MEL 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.


Sostituzione dei serviziSostituzione 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.


Politiche di link-unlinkPolitiche di link-unlink

L’operazione di link può essere fatta in due modi: Per ogni servizio, prima di iniziare l’esecuzione del

processo (Concretizator). Durante l’esecuzione del processo. Un servizio astratto viene legato ad un servizio concreto

quando ne viene invocata la prima operazione. prima dell’invocazione

L’operazione di unlink può avvenire avvenire : Su richiesta del process orchestrator. Alla fine dell’esecuzione per i servizi astratti non ancora

scollegati.


EsempiEsempi

Set di servizi concreti

Gestione link globale

<abstractService name=“prenotazioneTreni”> <concreteServiceList> <concreteService>Trenitalia</concreteService> <concreteService>FerrovieNord</concreteService> </concreteServiceList></abstractService>

<abstractService globalLink=“true”> <name>prenotazioneTreni</name> ...</abstractService>


EsempiEsempi

Gestione link singola con unlink<abstractService globalLink=“false”> <name>prenotazioneTreni</name> ...</abstractService>

<process>...<invoke operation=“login” link=“true”>...<invoke operation=“prenota” link=“false”>...<invoke operation=“loguout link=“false” unlink=“true”/>...</process>


Old wine in new bottles?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


What to investigate forWhat to investigate for

Some aspects need to be systematically investigated:

Expressiveness

Adequacy

Orthogonality

Formal characterization (reachability)

Design methods


References – part 1References – 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 EuroMicro’03 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



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



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


CreditsCredits

Parte del materiale e’ stato elaborato da L. Baresi, M. Matera, P. Plebani, E. Mussi, M. Mecella

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

Documents

Transcript of Coordinamento di e-service Argomenti di ricerca B. Pernici Politecnico di Milano Dipartimento di...