La composizione dei servizi rappresenta una combinazione di invocazioni dei servizi che consente all’utilizzatore del servizio di raggiungere un determinato obiettivo (goal). Per
poter combinare i servizi è necessaria l’interoperabilità di essi.
Adattare i servizi vuol dire far incontrare le richieste formulate dall’utilizzatore con i ser- vizi forniti dal produttore, rendere cioè trasparenti al richiedente, le differenze delle in- terfacce che i servizi reali presentano nello scambio di messaggi, in quanto diversi agenti, possono cooperare scambiandosi messaggi per completare un task ma molto spesso l’etero- geneità a livello business e l’elevato numero di fornitori, ognuno dei quali può supportare differenti interfacce e protocolli, portano ad uno scostamento molto ampio tra risultato ottenuto e quello sperato.
Nel paper[7], viene proposto un approccio per poter adattare un servizio richiesto, con uno disponibile basandosi su tre elementi:
• Mismatches (disaccoppiamento): una serie di accoppiamenti non esatti tra il servizio astratto e concreto.
• Mapping functions: un numero componibile di funzioni di mapping che organizzate in script permettono di risolvere i mismatches identificati.
• Runtime platform: una piattaforma runtime che supporta il binding dinamico e l’adattamento interpretando lo script che è stato definito tra due servizi.
L’approccio prende in considerazione due servizi web e classifica due tipologie di disaccoppiamenti:
• Mismatches livello-interfaccia: riguarda le differenze tra i nomi delle operazioni tra servizio richiesto e disponibile e i parametri di queste operazioni. La classificazione include:
– Differenze nei nomi delle operazioni: la richiesta formulata sul primo servizio prevede di invocare una certa operazione, ma il servizio invocato realmente ha un nome differente per questa operazione.
– Differenze nei dati: i nomi dei parametri di input/output del servizio invoca- to dall’utilizzatore differiscono dal servizio reale, le differenze dei parametri (nome, tipo, numero, ordine).
• Mismatches livello-protocollo: riguarda le differenze nell’ordine in cui le opera- zioni del servizio astratto sono effettivamente invocate nel servizio concreto. Si distinguono in:
– binding da uno a molti: caso in cui una operazione del servizio astratto può essere mappata in due o più operazioni del servizio concreto;
– binding da molti a uno: due o più operazioni del servizio concreto possono essere mappate in una operazione del servizio astratto.
Sempre in [7] viene introdotto un linguaggio di mapping che consente di raggrup- pare tutte le informazioni permettendo di risolvere i Mismatch sopracitati. Questo Map- ping Script viene creato sfruttando tutte le informazioni disponibili per attuare le seguenti funzioni:
ParameterMapping
Risolve mismatches relativi ai dati. Questo operatore mappa un dato astratto ad uno concreto, in modo che il dato concreto possa essere usato invece del dato astratto quando vengono invocate operazioni equivalenti. Il mapping ovviamente è eseguito sia sul nome che sul tipo del dato.
ReturnParamenterMapping
Stabilisce un collegamento tra i parametri di ritorno di una operazione del servizio astratto e concreto. Applicare questo operatore significa che nome, tipo e valore del parametro di ritorno dell’operazione concreta, sono mappati ai loro corrispettivi parametri di ritorno nella operazione reale.
OperationMapping
Costruisce un collegamento tra una sequenza di operazioni astratte con una sequen- za di operazioni concrete, considerate equivalenti.
StateMapping:
Collega uno stato astratto con uno stato concreto. Effettuare questo collegamento significa che i due stati sono stati considerati equivalenti, laddove per equivalenza si può intendere, per esempio, che i due stati abbiano lo stesso nome.
TransitionMapping:
Collega una transizione nel protocollo astratto ad una transizione nel protocollo concreto. Una transizione avviene se si ha a disposizione una coppia formata da uno stato e da una operazione da eseguire. Applicare questo operatore significa collegare la coppia stato-operazione del servizio astratto alla sua corrispondente nel servizio concreto.
Un progetto europeo denominato SeCSE (Service Centric System Engineering)[35], ha come obiettivo quello di realizzare una infrastruttura predisposta nel gestire l’ambiente dei servizi e per sostenere e gestire la composizione dinamica dei servizi che espongono interfacce sintatticamente non compatibili tra di loro, puntando sopratutto nell’effettuare l’adattamento in fase di runtime.
All’interno di questo progetto viene presentato e introdotto un framework denominato SCENE[10] che prevede la gestione dei servizi consentendo il discovery e la selezione di servizi compatibili con quello richiesto che, per esempio, potrebbe non essere disponibile
per ragioni, quali il livello di performance o altre definite negli SLA e consente il binding dinamico dal servizio richiesto al servizio compatibile disponibile.
Il progetto SeCSE ha realizzato una piattaforma in grado di gestire diverse fasi coinvolte con la gestione dei servizi Web. La fase dell’adattamento dei servizi, che è stata chiamata adattamento sintattico, si compone di una sequenza di operazioni:
1. Analisi dei mismatches esistenti tra le interfacce dei servizi; 2. Classificazione dei mismatches;
3. Realizzazione linguaggio di mapping; 4. Implementazione linguaggio di mapping;
Come punto di partenza si analizzano le interfacce dei servizi attraverso il WSDL degli stessi, si classificano i possibili mismatches e viene realizzato un linguaggio di mapping de- scritto in dettaglio in[7], che gestisce l’adattamento delle interfacce. Infine si passa all’im- plementazione del linguaggio di mapping, che viene realizzato nel componente chiamato ServiceAdapter, che è parte integrante della piattaforma SCENE realizzata nel progetto per la gestione dei servizi Web.
Un approccio di adattabilità a livello di interfaccia può avvenire anche a livello semanti- co, come mostrato in[9] e lo stesso approccio viene esteso con altre caratteristiche come descritto in[17]. Questo approccio introduce il SAWSDL, un estensione del linguaggio WSDL che include annotazioni semantiche per poter aumentare la precisione dell’adatta- bilità oltre al livello sintattico.
Lo strato semantico inserito, rispetto a quanto descritto in [9], subisce il rispetto dei vincoli per consentire la generazione dinamica diMapping Script:
• Ogni operazione deve essere annotata con un attributo modelReference • Lo schema WSDL deve essere annotato con un attributo modelReference • Non deve essere usato l’attributo loweringSchemaMapping
• L’attributo liftingSchemaMapping può essere utilizzato in maniera opzionale • Vengono utilizzati i tipi di dati definiti nell’XML Schema per definire tipi semplici