1. Evoluzione dei Web Services
per l’interoperabilità:
approcci a supporto della
dinamicità e flessibilità
nell’integrazione EAI
di infrastrutture IT
Emanuele Della Valle
Area Middleware - CEFRIEL
email:dellavalle@cefriel.it
Web:www.cefriel.it/~dellavalle
-1-
Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

2. Sommario
C’era una volta …
Service Oriented Architecture basata su Web Services
discovery
 UDDI
 Casi d’uso e limiti
Composizione
 Una nesessità
 BPEL4WS, WSCI, BPML, …
… e fu così che si affermarono le SOA basate su WS
Limiti degli approcci attuali in contesti caratterizzati da alta dinamicità
 mancanza di di semantica elaborabile dalle macchine
 Semantic-based service discovery
Semantic Web Services
 Le iniziative in corso
 WSMO all’opera
Conlusioni
-2-
Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

3. C’era una volta …
… ma l’organizzazione non era certo
…, in un’organizzazione felice,
l’unica. Altre organizzazioni avevano
un’applicazione con tanti utenti
applicazione con utenti soddisfati e …
soddisfatti, ma …
[…] […]
[…]
applicazione applicazione
applicazione Confine tra le due
organizzazioni
… e, per esigenze di business, le due Pensando alla contingenza
organizzazioni sentirono l’esigenza di l’organizzazione felice decise di
integrare le due applicazioni. addossarsi lo sforzo di integrazione, …
!
[…]
[…] […]
[…]
? adapter
applicazione applicazione
applicazione applicazione
Confine tra le due Confine tra le due
organizzazioni organizzazioni
-3-
Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

4. … ma gestire la contingenza …
… quando il problema di integrazione coinvolge molte organizzazioni autonome
ma interdipendenti non paga sul lungo periodo
[…]
[…]
Legenda
! OK
!
[…]
!! Bene
!
!
! !
! !!! Ottimo
!?! Ottimo, ma …
!?!
[…]
??
?
!?
!
?!? Avrò fatto la
cosa giusta?
!!
! ??? Che senso ha?
?#@ Perché lo
!
!?! stiamo facendo?
!!
##! …
??
!
[…]
[…]
[…]
!
!
!
-4-
Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

5. … fu così che …
… nacquero le soluzioni di Enterprise Application Integration e iniziò il
processo di maturazione delle tecnologie per l’integrazione
[…]
[…]
2010
SOA over WS
[…]
2005
WS-* 1.x
(SOAP1.1, WSDL1.2,
UDDI, BPEL4WS…)
[…]
CORBA 2.4 2000
WS-* 0.x
XML-RPC
EAI
CORBA2.0
1995
CORBA1.0
1990
EDIFACT
RPCs
[…]
1985
[…]
Sockets
ANSI X12 1980
[…]
TDCC 1970
Tecnologie per EAI
-5-
Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

6. Service Oriented Architecture
basata su Web Services
Il concept di Service Oriented Architecture (SOA) abilita flessibilità e dinamismo
tramite una descrizione ricca del servizio e un meccanismo di
pubblicazione/scoperta di tali descrizioni che permette a richiedenti occasionali
di interagire con il servizio senza (o con limitate) conoscenze a priori.
Una discovery agency può
essere realizzata in diversi Service
Descriptio
modi
n
Registro
 i service provider
Discovery
richiedono al registro di
Agencies
essere rendere disponibili
sul mercato i proprio
servizi
Discover
 Accordo esplicito tra service
Publish
provider e registro
Indice
 i service provider rendono
disponibile la descrizione Service
per una indicizzazione
Descriptio
esterna (es. Google)
n
 Nessun accordo esplicito tra
Service Service
provider e indice
P2P requester provider
Interact
 Service provider e service
requester hanno anche il
ruolo di discovery agency
source: http://www.w3.org/TR/2002/WD-ws-arch-20021114/
-6-
Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

7. Tecnologie che abilitano la discovery
Lo standard UDDI
Un registro UDDI (v 3.0) contiene: Business Entity
Pagine Bianche
Pagine Bianche Nome, Indirizzo, Contatti
 Nome del service provider, identificativo, Pagine Gialle
Identificativo
indirizzo e altre informazioni per
contattare la società ABN, CAN, DUNS, …
Pagine Verdi
Pagine Gialle Classificazione
Standard
 Sistemi di classificazione di service Geografica, tipo di industria, …
provider e servizi su base geografica, tipo
di industri, etc.
Business Service
Pagine Verdi
Nome, descrizione
 Descrizione tecnica delle interfacce del
servizio (es. Acquisto libri) e del punto di Classificazione
accesso (URL, e-mail, ecc.) utilizzando Tipo di processo, ruolo, …
opportuni “tModel”
tModel
Binding Template
 Definizione tecnica di un tipo di servizio
Descrizione, URL, …
tipicamente emessa da enti di
standardizzazione di specifici domini (es. tModel
EAN/UCC*) per essere utilizzata dai Descrizione dell’interfaccia,
service provider. trasport, protocollo, sintassi, …
Oggetti nel repository
 Tutti gli oggetti descritti sopra sono
tModel
immagazzinati come metadati nel registro
UDDI prevede API per scrivere e cercare nel Nome, descrizione, URL, …
repository
XML
Classificazione
* EAN.UCC System standardizza bar codes, insiemi di transazioni EDI Tipo, namespace, processo, ruolo, tipo
objects
transactions sets, schemi XML, e altre soluzioni per rendere più efficiente di industria, geografia, riferimenti ad
l’e-business
altri tModels
repository
-7-
Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

8. Tecnologie che abilitano la discovery
Casi d’uso e limiti di UDDI
Si iniziano a registrare casi d’uso reali In ambienti caratterizzati da alto
interessanti di UDDI dinamismo in cui numerose
BizDex Registry organizzazione autonome gestiscono un
 L’Australian National B2B Registry fa insieme di servizi eterogenei, ma
leva su UDDI per ridurre il costo di fortemente interdipendenti, UDDI
setup di infrastrutture B2B anche per mostra limiti di flessibilità.
piccoli business e con piccoli volumi In particolare, il meccanismo di ricerca
di transazioni. effettua un matching sintattico (senza
30 Gennaio 2004
considerare il significato delle
Picture Services Network
descrizioni) con conseguente:
 Il Common Picture Exchange
basso recall:
Environment dell’International
 a causa di termini semanticamente
Imaging Industry Association's utilizza
simili ma sintatticamente diversi
UDDI per ridurre i costi di
(sinonimi)
integrazione di differenti prodotti
esempio: “sagra” e “manifestazione
per la fotografia digitale.
folkloristica”
10 Giugno 2003
bassa precisione:
 a causa di termini con uguale sintassi
Altri casi d’uso
ma differente semantica (omonimi)
 http://www.uddi.org/casestudies.html
esempio: “grana”, si intende il formaggio o
il tipo di pasta?
-8-
Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

9. Composizione: una necessità
In un mercato dinamico e Esempio di composizione del contesto del
aggressivo, l’estrema turismo
specializzazione è una
necessità, ma le esigenze dei
consumatori restano trasversali
e per soddisfarle occorre la
collaborazione di molti attori.
Nel caso del turismo, ad
esempio, è normale che chi
offre viaggi aerei, non offra
pacchetti vacanza completi
(cosa che, invece, fanno le
agenzie di viaggio).
La composizione di servizi
cross-organizzazione è una
delle possibili vie per offrire
servizi ad alto valore aggiunto
per l’utente finale integrando i
servizi di molte realtà
settoriali. Fonte: W3C Note: WSCI http://www.w3.org/TR/wsci/
-9-
Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

10. Tecnologie che abilitano la composizione
BPEL4WS, WSCI, BPML, …
La composizione abilita la creazione Standard in competizione
BPEL4WS
di nuovi servizi a partire da servizi
 è un linguaggio per la specifica formale di
esistenti.
processi di business e protocolli per
Molti dei convenzionali middleware di
l’interazione tra business.
composizione (es. WfMS) non sono stati Web Service Choreography Interface (WSCI)
in grado di garantire un sufficiente  è un linguaggio per la descrizione del flusso di
grado di interoperabilità e i relativi messaggi scambiati da Web Services che
processi di standardizzazione si sono in collaborano per esibire un servizio composto.
Business Process Modeling Language
parte “arenati” (es. gli standard
(BPML)
proposti dalla WfMC sono scarsamente
 è un modello di esecuzione astratto per
supportati)
processi di business collaborativi e
Le opportunità per i Web Services transazionali
Gli standard disponibili (SOAP e
WSDL) sono largamente impiegati e
garantiscono coerenza nei meccanismi
di invocazione e nella descrizione
dell’interfaccia dei servizi
Molti tools (per discovery e
invocazione) sono già disponibili e,
pertanto, sviluppare un ambiente di
composizione di Web Services è “poco”
costoso
- 10 -
Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

11. … e fu così che
si affermarono le SOA basate su WS
Il continuo processo di maturazione delle tecnologie ha portato negli ultimi
anni all’affermazione dei Web Services come potenziale base tecnologica di
soluzioni per EAI che ambiscono a supportare scenari ad alta dinamicità con il
dovuto grado di flessibilità.
2010
[…]
[…]
SOA over WS
2005
WS-* 1.x
[…] (SOAP1.1, WSDL1.2,
UDDI, BPEL4WS…)
SOAP CORBA 2.4 2000
[…]
WS-* 0.x
XSD WSDL XML-RPC
CORBA2.0
EAI
UDDI 1995
WSCI CORBA1.0
1990
WS-* EDIFACT
BPEL
RPCs 1985
Sockets
[…]
ANSI X12
[…] 1980
TDCC
[…] 1970
Tecnologie per EAI
- 11 -
Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

12. Limiti degli approcci attuali in contesti
caratterizzati da alta dinamicità
È semplice gestire pochi servizi Gestirli diventa difficile quanto i servizi
all’interno di un unica sono numerosi e occorre comporli in
organizzazione da utilizzare in complessi business process cross-
workflow poco complessi organizzazione
Pochi servizi Numerosi servizi
All’interno di un’organizzazione
Tra molteplici organizzazioni
A1
B3 A1 B3
B8 A1
A4 B3
B3 A1
A1 A1
A1
A1
A1 A4 A2
A1 A4 A2 A4 A1 A2
A4 A1 A2
B3 A2 A1 A2
A5
A4 A1
B3 A1
B3 A1
A1
B3 B3 A1 A1
A1 A1
A4 A6 A1
A4
A1
A1 A1 A1 A4 A1 A2 A1
B3
A4 A1
A1 B3
A4 A1
A2 A1 A1 A4 A1 A2 A1
A2
A4 B3 A4 A1
A1 A4 A1 A2
B3 A2
A1 A1 A1 A1 A1
A1A1
A2 A4 A1 A2
A4 A1 A1
1
A
A1 A1
B3 A4 A1 A2
A1 A2
A1 A2 A1 A2 A1 A1 A4A4 1 A2
A1 A4 B3 A2 A4 A2
A4 A1 4
A1 A1 A A4 B3 A2
A4 A1 A
A2
A4 A1 A1 A1 A1 A1
B3 A4 A1 A2
B3 A4A1 A1 A2
B3 A4 A1 B3 A2 A4
A2
A1 A4 A1 A2 A1
A1 A1
A1
A1 A1 A4
B3 B3 A1 A1
A1 A1 A1A4 A2
Workflow A1A1
A2 A1 A2 A1 A1
A4
A4 A1 A2 A4
A1 A1A4 A1 A2
A1 A4
A4
A1 B3
B3 A1
A1
A1 B3B3 A1A1
poco complessi B3
?
E
A N1 N2 F
C D
Complessi Business Process
Inspired by: J. Cardoso, C. Bussler, A. Sheth1, D. Fensel,
Semantic Web Services and Processes, October 2002
- 12 -
Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

13. Il principale limite è la mancanza di di
semantica elaborabile dalle macchine
quot;Semantic differences remain the primary roadblock to smooth
application integration, one which Web Services alone won't over-come.
Until someone finds a way for applications to understand each other, the
effect of Web services technology will be fairly limited. When I pass
customer data across in a certain format using a Web Services interface,
the receiving program has to know what that format is. You have to agree
on what the business objects look like. And no one has come up with a
feasible way to work that out yet ...“
“L’eterogeneità semantica rimane il principale intoppo alla
integrazione di applicazioni, un intoppo che i Web Services da soli non
risolveranno. Finchè qualcuno non troverà un modo di per far si che le
applicazioni si capiscano, gli effetti dei Web Services resteranno limitate.
Quando si passano i dati di un utente in un certo formato usango un Web
Services come interfaccia, il programma che li riceve deve comunque
sapere in che formato sono. Occorre comunque accordarsi sulla struttura
di ciascun business object. Fino ad ora nessuno ha ancora trovato una
soluzione attuabile …”
Oracle Chairman and CEO Larry Ellison
- 13 -
Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

14. Nell’implementazione di una SOA usando i WS,
dove sta la semantica dell’informazione scambiata?
In parte è codificata nella descrizione del servizio (WSD), ma quella che
abilita l’interazione resta nella testa delle persone …
Discovery
Discover Publish
Agencies WSD
Provider Entity
Requester Entity
? Sem
AGREE
Sem
Provider
Requester
Human
Human
+ Sem
+ WSD
Service
Service
provider
requester Interact
- 14 -
Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

15. Il Semantic Web sta rendendo disponibili meccanismi
per rendere la semantica elaborabile
La semantica può essere resa elaborabile dalle macchine tramite le
ontologie ( ) perchè abilitano la comprensione dei simboli da parte
delle persone e allo stesso tempo la loro elaborabilità
Discovery
Discover Agencies
+ Sem Publish
WSD
Ontology Provider Entity
Requester Entity
? Sem
Sem
Provider
Requester
Human
Human
AGREE
+ Sem
+ Sem WSD
WSD
Service
Service
provider
requester Interact
- 15 -
Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

16. Esempio di uso della semantica
Semantic-based service discovery
Un’ontologia permette di descrivere le relazioni tra Mentre nel keyword mathcing (es. in
i simboli in modo formale. La più semplice relazione UDDI) il matching è basato solo sulla
è quella di classificazione. sintassi della stringa, avendo a
Ad esempio, nel contesto del turismo le “sagre” e le disposizione un’ontologia si possono
“mostre” sono due tipi di “eventi culturali” che a utilizzare le relazioni tra i simboli per
loro volta sono “attrattive culturali” come i “beni “inferire” altre forme di matching.
culturali” I possibili mathcing abilitati dalla
relazione di classificazione sono:
Exact Mathcing ( )
Subsume
 Tutti i servizi classificati utilizzando
il simbolo richiesto
AttrattivaCulturale
Plug-in matching ( )
 Tutti i servizi classificati utilizzando
Exact
uno dei simboli che sono classificati
BeniCulturali
EventiCulturali
come tipi più specifici di quello
richiesto
Subsume matching ( )
Mostre
Sagre  Tutti i servizi classificati utilizzando
uno dei simboli di tipo più generico
Plug-in
di quello richiesto
Qui a fianco è illustrato un esempio di
Fotografica Pittura
mathcing nel caso in cui venga richiesto
“eventi culturali”
- 16 -
Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

17. Quale approccio ai Semantic Web Services?
In aggiunta ad un linguaggio per esprimere le ontologie, l’interoperabilità
semantica richiede la definizione di un modello concettuale per i Web Services.
OWL-S e WSMO sono le due principali iniziative attive nel contesto dei Semantic
Web Services,
OWL-S è un’ontologia dei servizi definita in OWL (Ontology Web Language)
 Mette a disposizione dei service providers un insieme di costrutti per descrivere le
proprietà e le funzionalità offerte dai loro Web Services in modo che tali descrizioni
siano “comprensibili” alle macchine.
 OWL-S è stato sottomesso al W3C nel Novembre del 2004.
http://www.daml.org/services/owl-s/1.1/ .
WSMO, Web Service Modeling Ontology,
 Prende il problema da un punto di vista più ampio introducendo quattro elementi:
Le ontologie che permettono di descrivere il significato dei simboli necessari a tutti gli altri
elementi,
I goal che descrivono le funzionalità richiesta da chi intendo utilizzare i Web Services disponibili,
Le descrizioni dei servizi vere e proprie, e
I mediatori per aggirare i problemi di interoperabilità
 La preparazione di una sottomissione al W3C è in corso ed è attesa per il giugno 2005
http://www.wsmo.org/ .
L’idea è “completare (gli standard esistenti), non competere”
- 17 -
Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

18. Le iniziative relative ai
Semantic Web Services in corso
ha preparato le basi per
DAML-S ha sviluppato
Compatibile con
Compatibile con
Sta sviluppando
Sta sviluppando
Contribuisce a Contribuisce a
OWL-S WSMO
Prossim
o Event
Sottomette Drafts a o
6 - 10 J
une 200
5
Innsbruc
k, Austr
ia
- 18 -
Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

19. WSMO all’opera
Semantic Service Discovery - publishing time
Requester
Provider
Provider entity
entity
entity WSD
WSD
WS
WS
Execution Enviroment
Ontologies Mediators Web Services
WSD
+ WSD
+ WSD
+WSD
+
2. 3.
1.
1. i provider e i requester si accor-
dano sulle ontologie da usare
WS WS
1. Quando non si riesce a trovare un
Provider Provider
accordo si possono introdurre dei
entity entity
mediatori (es. Conversione €/$)
WSD
WSD
1. Ciascun provider descrive i
propri servizi usando i simboli
delle ontologie prescelte e, se
necessario i mediatori
- 19 -
Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

20. WSMO all’opera
Semantic Service Discovery - discovery time
4.
Requester
Provider Invoke Provider
entity
entity entity
WSD
G WSD
WS WS
3. 1.
Execution Enviroment
{ ● ● } Discovery engine 2.
Ontologies Mediators Web Services
WSD
+ WSD
+ WSD
+ WSD
+
1. I Requester descrivono i proprio goal usando i
simboli delle ontologie prescelte e, se necessario
i mediatori
1. Il meccanismo di discovery usa le ontologie e i
mediatori per scoprire quali descrizioni hanno WS
WS
una corrispondenza semantica con il goal
Provider
1. L’ execution environment returna una lista
Provider
entity
entity di Web Services
WSD WSD
1. Il requester seleziona il Web Services più
appropriato e lo invoca
- 20 -
Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

21. C’era una volta e un’altra volta non c’era più,
ma quella volta comunque c’era …
Nelle soluzioni di application-to- […]
[…]
application integration la semantica
rimane nella testa di chi scrive adapter
l’adapter
Sem
Sem Sem
Nelle soluzioni di EAI che usano i Web […]
[…]
Services come soluzione di integrazione
la semantica è in parte codificata
negli standard (XSD, SOAP, WSDL,
BPEL4WS, BPML, etc.) usati per definire
WS*
i formati dei dati scambiati e le EAI
modalità di scambio, ma buona parte
rimane della testa di chi realizza la
soluzione di integrazione. […]
[…]
Sem
Sem
- 21 -
Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

22. C’era una volta e un’altra volta non c’era più,
ma quella volta comunque c’era …
Le soluzioni di EAI del
Sem
futuro potrebbero essere Sem
basate sui risultati dei
working group che oggi
[…]
[…]
stanno lavorando per
aggiungere Semantica
SOA over SWS 2010
(direttamente elaborabile
dalle macchine) ai Web SOA over WS
Services. WS-* 1.x 2005
In questo modo la (SOAP1.1, WSDL1.2,
UDDI, BPEL4WS…)
semantica risulta
EAI
!
SWS CORBA 2.4
condivisa tra gli utenti e 2000
WS-* 0.x
le macchine XML-RPC
(direttamente disponibile CORBA2.0
alla soluzione di EAI) 1995
CORBA1.0
permettendo
1990
un’integrazione flessibile EDIFACT
[…]
RPCs
in grado di seguire le […]
1985
Sockets
esigenze di business di un ANSI X12
1980
mercato caratterizzato da
TDCC
forte specializzazione e 1970
Sem
dinamismo. Sem
- 22 -
Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

23. Opportunità, sfide e attività CEFRIEL
Opportunità: studiare soluzioni di EAI con elevato grado di flessibilità
per ambiti applicativi con elevato grado di dinamismo.
Sfida: impiegare in scenari reali l’approccio innovativo dei Semantic Web
Services attraverso un opportuno tuning che richiede la selezione delle
tecnologie abilitanti, l’uso di standard esistenti, la scelta dell’architet-
tura complessiva, la selezione degli ambiti applicativi più idonei, …
Es. COCOON: WSMO per e-Health [http://cocoon.cefriel.it]
- 23 -
Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL

24. Grazie mille dell’attenzione
Domande?
EAI
Evento
Contatto
ossimo
Pr
Emanuele Della Valle
Area Middleware - CEFRIEL
email:dellavalle@cefriel.it
2005
10 June ustria Web:www.cefriel.it/~dellavalle
6-
ck, A
Innsbru Tel: 02 23954-324
- 24 -
Evoluzione dei Web Services per l’interoperabilità © E. Della Valle - CEFRIEL