La sezione dedicata all‘integrazione è ricca di informazioni utili per aiutare ad affrontare il difficile e importante mondo dell‘Integrazione. Quest‘ultimo articolo di Stefano Rossini rappresenta il culmine di un lungo cammino e parlerà di Semantic Integration, il cosiddetto “SOA Nirvana”.
Introduzione
Da quando ho iniziato a collaborare con Mokabyte (nel lontano 2000…), occupandomi della sezione di Integrazione, ho sempre cercato di trattare argomenti attuali e “promettenti” (tre su tutti: JCA, JBI e ESB).
Inizilmente mi sono occupato delle diverse tecniche di integrazione point-to-point [MOKA_INT].
Ho trattato di EAI parlando di JCA [MOKA_JCA], Integration Middleware [MOKA_IM], [MOKA_PIS]e di Architetture d‘Integrazione [MOKA_ARCHINT].
Ho scritto di ESB e JBI appena usciti [MOKA_ESB], [MOKA_JBI] per poi dedicarmi a SOA a 360 gradi [MOKA_SOA].
La track tecnica del Semantci Web mi ha permesso di introdurre argomenti quali RDF, RDFS,OWL e SWED.
Che dire: la sezione dedicata all‘integrazione è ricca di informazioni utili (spero!) per aiutare ad affrontare il difficile e importante mondo dell‘Integrazione.
Quest‘ultimo articolo rappresenta il culmine di questo mio lungo cammino e parlerà di Semantic Integration, il cosiddetto “SOA Nirvana”.
Figura 1 – L‘iter concettuale proposto nella sezione Integrazione di MokaByte
WS: stato dell‘arte
Un Web Service è un servizio di business riutilizzabile che può essere richiamato attraverso tecnologie Internet e che dialoga in XML [MOKA_WS].
La rappresentazione dei dati nei Web Services (WS) avviene mediante il linguaggio XML e per questo sono definiti “language-neutral”. Come protocollo di comunicazione i WS non utilizzano protocolli proprietari bensì i protocolli standard Internet (es: HTTP) e per questo sono definiti “platform-neutral”.
Figura 2 – Architettura Web Services
Sul piano architetturale dunque possono essere paragonati ad altri sistemi di elaborazioni distribuita con la differenza che hanno grande attenzione alla standardizzazione e all‘interoperabilità : sono applicazioni di rete che sfruttano SOAP e WSDL per scambiare informazioni espresse in forma di documenti XML; la loro caratteristica fondamentale è la capacità di far interoperare applicazioni eterogenee (applicazioni Java EE, .Net, CORBA, legacy, C/C++, …) tramite un protocollo XML based e “firewall friendly” come SOAP.
Figura 3 – Le principali specifiche WS
Il Web Service Definition Language [MOKA_WS], [MOKA_SOA] ricopre un ruolo importante nell‘architettura dei web service perché descrive il contratto tra il Service Consumer (l‘entità che richiede il servizio) ed il Service Provider (l‘entità che fornisce il servizio) in modalità indipendente dal linguaggio di sviluppo e dalla piattaforma utilizzata.
In pratica, il WSDL descrive come interagire con il servizio, definendo le operazioni e i messaggi relativi e specificando i “binding” delle operazioni sui protocolli esposti. Partendo dal documento WSDL è possibile generare le classi stub da usare lato client utilizzando l‘opportuno tool WSDL-to- che permette di semplificare notevolmente lo sviluppo di un client riducendo la quantità di codice da scrivere e senza fare riferimento diretto alle API di basso livello di gestione dati/protocollo [MOKA_INT].
Ad esempio in Java è possibile utilizzare il tool Axis WSDL2Java, mentre per C# l‘eseguibile Microsoft wsdl.exe. Le classi generate automaticamente dal tool possono essere utilizzate dal client per invocare in modo facile ed agevole il servizio.
Combinando un Design SOA con la tecnologia Web Services possiamo abbattere le barriere tecnologiche tra le varie piattaforme grazie ad una esposizione dei servizi omogenea e interoperabile. Ovviamente i servizi devono avere un‘interfaccia chiara e comprensibile. Capire il significato di un servizio e dei suoi dati non è così banale come potrebbe sembrare. Ad esempio, un servizio con una signature criptica come questa è praticamente inutilizzabile:
che in Java equivarrebbe a dire:
interface MyWS
{
public Object myOperation (Object param1, Object param2, Object param3);
}
Non si capisce a cosa serva, che dati di input richiede e che risultato restituisce. Utilizzando nomi più significativi e tipizzando un minimo i dati già le cose migliorano:
interface MokabyteBooks
{
public double getPrice (String ISBN, String title, int year);
}
Tipizzando ulteriormente i dati dell‘interfaccia il tutto diventa ancora più comprensibile:
interface MokabyteBooks2
{
public double getPrice (BookID isbn, BookTitle title, Date year);
}
Ovviamente è sempre fondamentale fornire l‘opportuna documentazione; ad esempio utilizzando il comando javadoc (o Maven!) che può generare automaticamente a partire dal codice (scritto bene) una buona documentazione in modo comodo ed immediato.
Figura 4 – JavaDoc del servizio
Anche le stesse ricerche UDDI [MOKA_WS] ad oggi devono prevedere un intervento umano per decidere effettivamente quale servizio utilizzare nel proprio business process visto che generalmente le ricerche avvengono mediante criteri di identità (nome del servizio o una parola chiave).
D‘altro canto solo un operatore umano che consulta un registro UDDI sa andare “oltre” la descrizione formale per capire, magari provandolo direttamente, se un Web Service fa quello che sta cercando.
UDDIProxy proxy = new UDDIProxy();
Vector names = new Vector();
names.add(new Name("CheckEmail"));
. . .
FindQualifiers findQualifiers = new FindQualifiers();
Vector qualifier = new Vector();
qualifier.add(new FindQualifier("caseSensitiveMatch"));
findQualifiers.setFindQualifierVector(qualifier);
. . .
// Find businesses by name. Setting the maximum rows to be returned as 5.
BusinessList businessList = proxy.find_business(names, null, null,
null,null,findQualifiers,5);
Vector businessInfoVector = businessList.getBusinessInfos().getBusinessInfoVector();
for( int i = 0; i < businessInfoVector.size(); i++ ){
. . . . .
}
La situazione è “analoga” a una ricerca sintattica mediante un motore di ricerca Web dove una volta effettuata una ricerca e ottenuto il risultato, l‘informazione deve essere interpretata scorrendo una lunga quantità di elenchi. Ad oggi quindi è necessaria una forte “human interaction” per potere fare interagire tra di loro le applicazioni perché si necessita di capire, da parte di un essere umano, i dati e le funzionalità delle entità coinvolte nell‘integrazione.
La problematica della semantica dei dati di un servizio, cioè di avere informazioni che siano “machine understandable” in realtà è sempre stata presente, ma di solito risultava “mascherata” da problemi di integrazione più contingenti di natura prettamente architetturale / tecnologica. Abbattute le barriere tecnologiche con SOA ed i WS, il problema della semantica del significato dei dati esce prepotentemente allo scoperto con tutta la sua importanza e complessità .
Diventa prioritario avere a disposizione non solo la descrizione sintattica dei dati (WSDL) ma anche la relativa semantica! Nel WSDL però si descrive il servizio (operazioni ed i relativi dati) in modo prettamente sintattico, ma non si esplicita alcuna semantica degli stessi.
Come fare quindi ad affiancare alla attuale descrizione sintattica dei dati una definizione semantica degli stessi in modo tale che il WS non solo sia fruibile da un essere umano ma anche da una macchina ?
Lo scopo della Semantic Integration è aggiungere informazioni semantiche ai servizi (Semantici Web Services) mediante un meccanismo di tagging e l‘introduzione di Ontologie: correlare quindi, mediante un‘opportuna “annotazione semantica” i dati (la cui descrizione sintattica risiede nel WSDL) al loro significato (descritto nella relativa ontologia).
Unendo le tecnologie interoperabili dei Web Services alla potenza semantica tipiche delle Ontologie si aprono nuove strade all‘orizzonte nel mondo dell‘integrazione.
Non esiste ad oggi uno standard unico riconosciuto per associare contenuto semantico ai servizi applicativi ed in un contesto più generale ai Web Services.
I principali candidati in tale area sono: OWL-S, SWSF, WSDL-S, WSMO e SAWSDL.
Figura 5 – Semantic Web Services
Un esempio di Semantic Web Service
Una delle Recommendation più interessanti in questo ambito è la Semantic Annotations for WSDL (SAWSDL), che ad oggi è un Working Draft del W3C [SAWSDL]. SAWSDL nasce come evoluzione del precedente WSDL-S (Semantic Web Service – SWS), proposto al W3C dal Large Scale Ditributed Information Systems (LSDIS) dell‘Università della Georgia negli Stati Uniti.
Ad esempio, il seguente WSDL descrive un Web service che gestisce un ordine: dato in ingresso una richiesta d‘ordine (OrderRequest), restituisce il relativo stato dell‘ordine (OrderResponse).
Si aspetta in input il numero dell‘account del cliente e la lista degli item da ordinare, ciascuno dei quali comprende l‘informazione relativa alla quantità da comprare e l‘identificativo del prodotto (UPC-Universal Product Code). Il servzio ritorna lo stato dell‘ordine che può essere rifiutato, accettato o in elaborazione.
Figura 6 – Il WSDL d‘esempio
Il tipo di dato OrderRequest è un tipo complesso che ha al suo interno il numero del cliente (“customerNo”) di tipo intero (xs:integer) ed una lista (minOccurs=”1″ maxOccurs=”unbounded”) di prodotti da ordinare (orderItem) di tipo Item. Item a sua volta è costituito da un identificativo (UPC) di tipo stringa (xs:string)
e da una quantità (xs:integer).
La risposta è OrderResponse, un tipo di dato di tipo stringa (xs:string) che può assumero i valori Confirmed, Pending o Rejected ().
Utilizzando SAWSDL si annota il WSDL con il metadata modelReference. Questo permette di descrivere le operazioni e i dati corredandoli di informazioni contenute in ontologie.
Figura 7 – Annotazione semantica del WSDL
Di fatto il tag modelReference permette di correlare il WSDL (descrizione sintattica del servizio) con ontologie (descrizione semantica del servizio). Aggiungiamo al WSDL precedente il tag SAWSDL modelReference:
. . .
sawsdl:modelReference
="http://www.w3.org/2002/ws/sawsdl/spec/ontology/purchaseorder#OrderRequest"
. . .
In questo modo associamo all‘elemento OrderRequest il riferimento alla classe OrderRequest appartenente all‘ontologia http://www.w3.org/2002/ws/sawsdl/spec/ontology/purchaseorder [SAWSDL-OWL-EX].
Figura 8 – L‘Ontologia dell‘esempio visualizzata con il tool Protègè [SAWSDL-OWL-EX]
La classe è in relazione con la classe LineItem attraverso la proprietà hasLineItems e
con la classe Customer attraverso la proprietà hasCustomer.
Analoga annotazione semantica è possibile farla sia per l‘OrderResponse che per l‘operazione order. Il file WSDL annotato [SAWSDL-EX] risulta essere:
Figura 9 – Il WSDL annotato d‘esempio
Di seguito si mostra il file [SAWSDL-EX] aperto con l‘editor SAWSDL di WSMO [WSMO].
Figura 10 – SAWSL Editor WSMO [WSMO]
Eseguendo il parsing in modo programmatico (p.e.: mediante le API SAWSDL4J [SAWSDL4J]) è possibile analizzare le parti semantiche.
La pubblicazione di servizi semantici, gioverà anche al meccanismo di discovery potendo realizzare degli algoritmi di ricerca che permettano il Dynamic Service discovery se non addirittura l‘invocazione trasparente di uno o più WS (Dynamic Service Composition) attraverso un binding dinamico a “run time” (just in time).
Avendo a disposizione servizi la cui descrizione non è ambigua ed è comprensibile anche a una macchina si potranno effettuare una serie di operazioni, ricerche e correlazioni che ad oggi è possibile effettuare solo con intervento umano.
Innanzitutto i servizi potranno essere pubblicati secondo determinate categorie. Questo agevolerà le operazioni di discovery e renderanno possibili operazioni di matchmaking tra richiesta e offerta basato sulle descrizioni semantiche dei servizi.
Formalizzando le relazioni tra i WS e le ontologie si creerà uno “strato” semantico che potrebbe permettere l‘utilizzo di “Agenti Software” in grado di analizzare i contenuti semantici ed automatizzare (rendendole particolarmente efficienti ed evitando ambiguità sintattiche) una serie di attività ,ricerche e correlazioni che ad oggi è possibile effettuare solo con intervento umano.
Diventerà inoltre ipotizzabile la composizione dinamica dei servizi.
In [SAWDL-UG] si mostra un esempio in cui un WS di nomePartNumber2SKULookup (Fig.10(A)) ed un WS di nome CheckInventoryService (fig. 10(B)) vengono composti automaticamente sfruttando le relative annotazioni semantiche per concorrere alla realizzazione della funzionalità CheckAvailability.
Figura 11 – Esempio di composizione di SWS [SAWDL-UG]
I Semantic Web Services sono un importante tassello per arrivare all‘ultimo passo della SOA roadmap: la Semantic Integration, il cosidetto “SOA Nirvana”.
Il Nirvana dell‘integrazione è ancora lontano e la sua attuabilità dipenderà dal successo finale che otterrà il Semantic Web, a mio avviso una precondizione necessaria.
Figura 12 – Il “SOA Nirvana” [MOKA_SOA]
Conclusione
I Semantic Web Servcies rappresentano il punto di incontro tra i Web Services e il Semantic Web. Si è cercato di mostrare come, introducendo la semantica (machine understandable) nei WS, l‘integrazione potrà avvenire in modo più efficace e più automatizzato richiedendo sempre meno l‘intervento umano.
Portare semantica ai WS vuole dire fornire l‘opportuna marcatura dei documenti di un linguaggio gestibile da tutte le applicazioni e dell‘introduzione di vocabolari specifici, ossia insiemi di frasi alle quali possano associarsi relazioni stabilite fra elementi marcati. Gli standard dei SWS devono tendere a incastrarsi e non a sovrapporsi o a divergere soprattutto tenendo conto che ad oggi il tutto è tecnologicamente immaturo.
Personalmente credo che si potrà parlare di Semantic Web Services in modo più maturo e concreto a seconda del successo che otterrà nel breve e medio termine il Semantic Web. In questo articolo ho anticipato alcuni importanti sviluppi che si potrebbero avere a medio e lungo termine nel mondo dell‘integrazione: la Semantic Integration.
Con quest‘ultimo articolo termina la mia lunga “serie” (ben 41 dei 92 articoli che ho scritto per MokaByte) relativa all‘Integrazione nell‘ambito Enterprise. Ringrazio moltissimo i tanti lettori che mi hanno seguito ed incoraggiato aiutandomi a portare avanti questo lavoro con costanza ed entusiasmo.
Riferimenti
[W3CSA] W3C Publishes Semantic Annotations for WSDL and XML Schema Recommendation.
http://xml.coverpages.org/ni2007-08-28-a.html
[SAWSDL-REC] SAWSDL Recommendation – Semantic Annotations for WSDL and XML Schema (Recommendation, 28 August 2007)
http://www.w3.org/TR/sawsdl/
[SAWSDL-UG] Semantic Annotations for WSDL and XML Schema – Usage Guide (Working Group Note, 28 August 2007)
http://www.w3.org/TR/sawsdl-guide/
[W3C_WSDL_PRIMER] WSDL 2.0 Infoset Diagram
[USFSS] K. Verma – A. Sheth (Kno.e.sis), “Using SAWSDL for Semantic Service”
http://www.semantic-conference.com/2007/handouts/2-UpBW/T10_Sheth_Amit_Verma_Kunal_2UpBW.pdf
[OWL-S] OWL-S: Semantic Markup for Web Services
http://www.w3.org/Submission/OWL-S/
[OWLS_SEI] Ontology Web Language fro Services (OWL-S)
http://www.sei.cmu.edu/isis/guide/technologies/owl-s.htm
[OWLS_WP] OWL-S 1.0 White paper
http://www.daml.org/services/owl-s/1.0/owl-s.html
[SWSF] http://www.w3.org/Submission/SWSF/
[WSDL-S]
http://www.w3.org/Submission/WSDL-S/
[WSMO]
http://www.w3.org/Submission/2005/06/
[SAWSDL4J]
http://knoesis.wright.edu/opensource/sawsdl4j/index.html
[SMW-SOA] Semantic Web Services – State of Affairs
http://www.wsmo.org/TR/d17/tutorials/aswc06-swstutorial.html
[SAWSDL] Semantic Annotations for WSDL and XML Schema
http://www.w3.org/TR/sawsdl/
[MS-SWSAP] METEOR-S: Semantic Web Services and Processes
http://lsdis.cs.uga.edu/projects/meteor-s/
[SEI] Software Enginnering Institue – Carnegie Mellon
http://www.sei.cmu.edu/isis/guide/technologies/owl-s.htm
[SWST] Semantic Web Services Tools
http://www.daml.ri.cmu.edu/tools/
[IBMSTFWS] Semantic Tools for Web Services
http://www.alphaworks.ibm.com/tech/wssem
[SAWSDL-EX] WSDL file including SAWSDL annotation
http://www.w3.org/2002/ws/sawsdl/spec/wsdl/order
[SAWSDL-OWL-EX] Purchase order ontology
http://www.w3.org/2002/ws/sawsdl/spec/ontology/purchaseorder
Articoli della sezione di Integrazione a cura di Stefano Rossini, cui si fa riferimento nel testo, raggruppati per argomento (cfr. figura 1).
[MOKA_SOA]
S. Rossini – M. Piraccini, “SOA. I parte: Introduzione”, MokaByte 100, Ottobre 2005
S. Rossini – M. Piraccini, “SOA. II parte: Metodologia”, MokaByte 101, Novembre 2005
S. Rossini – M. Piraccini, “SOA. III parte: Il SOA Maturity Model”, MokaByte 102, Dicembre 2005
S. Rossini – M. Piraccini, “SOA. IV parte: La SOA Roadmap”, MokaByte 103, Gennaio 2006
S. Rossini – M. Piraccini, “SOA. V parte: Integrazione a servizi (SOI)”, MokaByte 104, Febbraio 2006
S. Rossini – M. Piraccini, “SOA. VI parte: Il Service Bus (I)”, MokaByte 105, Marzo 2006
S. Rossini – M. Piraccini, “SOA. VII parte: Il Service Bus (II)”, MokaByte 106, Aprile 2006
S. Rossini – M. Piraccini, “SOA. VIII parte: Strategie di adozione”, MokaByte 107, Maggio 2006
S. Rossini – M. Piraccini, “SOA. IX parte: Esempio Pratico (I)”, MokaByte 108, Giugno 2006
S. Rossini – M. Piraccini, “SOA. X parte: Esempio Pratico (II)”, MokaByte 109, Luglio 2006
S. Rossini, “SOA: Riuso e granularità dei servizi SOA”, MokaByte 116, Marzo 2007
[MOKA_INT]
S. Rossini, “Integrazione di Applicazioni Enterprise. I parte”, MokaByte 73, Aprile 2003
S. Rossini, “Integrazione di Applicazioni Enterprise. II parte”, MokaByte 74, Maggio 2003
S. Rossini – A. D‘Angeli, “Integrazione di Applicazioni Enterprise. III parte”, MokaByte 75, Giugno 2003
S. Rossini, “Integrazione di Applicazioni Enterprise. IV parte”, MokaByte 76, Luglio/Agosto 2003
S. Rossini – A. D‘Angeli, “Integrazione di Applicazioni Enterprise. V parte”, MokaByte 77, Settembre 2003
S. Rossini, “Integrazione di Applicazioni Enterprise. VI parte”, MokaByte 83, Marzo 2004
[MOKA_IM]
S. Rossini, “Integrazione di applicazioni Enterprise. VII parte: l‘Integration Middleware”, MokaByte 88, Settembre 2004
[MOKA_JCA]
S. Rossini – G. Morello, “JCA. I parte: La teoria”, MokaByte 66, Settembre 2002
S. Rossini, “JCA. II parte: CCI – La teoria”, MokaByte 67, Ottobre 2002
S. Rossini, “JCA. III parte: CCI – La pratica”, MokaByte 68, Novembre 2002
S. Rossini, “JCA. IV parte: Il Resource Adapter e i System Contracts”, MokaByte 69, Dicembre 2002
S. Rossini, “JCA. V parte: il Resource Adapter MokaConnector”, MokaByte 70, Gennaio 2003
S. Rossini, “JCA . VI parte: Resource Adapter per accedere a CICS”, MokaByte 89, Ottobre 2004
[MOKA_PIS]
Stefano Rossini “EAI. VIII parte: L‘Enterprise Integration Component Server di Librados”, MokaByte 99, Settembre 2005
[MOKA_WS]
S. Rossini – R. Spazzoli, “Web Services: il punto sulla standardizzazione. I parte”, MokaByte 97, Giugno 2005
S. Rossini – R. Spazzoli, “Web Services: il punto sulla standardizzazione. II parte”, MokaByte 98, Luglio/Agosto2005
[MOKA_EIP]
S. Rossini, “Integration Patterns. I parte: la teoria”, MokaByte 100, Ottobre 2005
S. Rossini, “Integration Patterns. II parte: la teoria”, MokaByte 101, Novembre 2005
S. Rossini, “Integration Patterns. III parte : la pratica”, MokaByte 102, Dicembre 2005
[MOKA_JBI]
S. Rossini, “JBI. II parte: Sviluppo di un componente JBI”, MokaByte 101, Novembre 2005
S. Rossini, “JBI. I parte: Introduzione Java Business Integration”, MokaByte 100, Ottobre 2005
S. Rossini, “JBI. III parte: Service Unit & Service Assembly”, MokaByte 102, Dicembre 2005
[MOKA_ESB]
S. Rossini, “Enterprise Service Bus”, MokaByte 96, Maggio 2005
[MOKA_ARCHINT]
S. Rossini – M. Piraccini, “Architetture di Integrazione. I parte”, MokaByte 105, Marzo 2006
S. Rossini – M. Piraccini, “Architetture di Integrazione. II parte”, MokaByte 106, Aprile 2006
[MOKA_SEMW]
S. Rossini – A. Rocca, “Semantic Web. I parte: Introduzione a RDF, principi e Data Model”, MokaByte 119, Giugno 2007
S. Rossini – A. Rocca, “Semantic Web. II parte: RDFS e vocabolari controllati”, MokaByte 120, Luglio/Agosto 2007
S. Rossini – A. Rocca, “Semantic Web. III parte : Web Ontology Language (OWL)”, MokaByte 121, Settembre 2007
S. Rossini – A. Rocca, “Semantic Web. IV parte : Esempio pratico”, MokaByte 122, Ottobre 2007