Post on 02-May-2015
Università degli Studi di Bologna FACOLTA’ DI INGEGNERIA
Corso di Laurea in Ingegneria Informatica
I web services come soluzione per l’interoperabilità e l’interazione automatica
fra sistemi software
I web services come soluzione per l’interoperabilità e l’interazione automatica
fra sistemi software
Tesi di Laurea di: STEFANO RICCIARELLI
Relatore: Prof. ANTONIO NATALI
Correlatori:Prof. ENRICO DENTI
Ing. LUCA BICCI
Anno Accademico 2001-2002
ObiettiviObiettivi
Analisi delle tecnologie dei Web Services
Comprensione del loro impatto nello sviluppo del software
Valutazione di costi e benefici dell’esposizione di un componente come Web Service
Sperimentazione su un case study reale (progetto EBroker)
IntroduzioneIntroduzione
• Forte esigenza di integrazione fra sistemi software:– Adozione pervasiva dell’information tecnology
(contesti EAI e B2B)– Passaggio da una elaborazione confinata ad
una esigenza di comunicazione fra sistemi
• Obiettivi:– Eterogeneità dei sistemi– Contesto distribuito e globale – Semplicità
I WEB SERVICES
Nascita e standardizzazioneNascita e standardizzazione
• Storia:– Inizialmente insieme di specifiche
proprietarie a partire dal 1999– Dal 2001 specifiche raccolte dal W3C:
inizia un processo di standardizzazione – Consenso allargato da parte delle più
importanti aziende dell’IT
• Obiettivi della standardizzazione:– Definizione coerente dell’architettura
complessiva– Affermazione di un unico standard
globalmente condiviso – Standard Royalty-Free
I WEB SERVICES
Cos’è un Web ServiceCos’è un Web Service
• Un Web Service:– E’ un sistema software identificato da un URI– E’ descritto da un documento XML rintracciabile
mediante discovery– Interagisce con altri sistemi attraverso scambio di
messaggi XML veicolati da protocolli internet-based
• Architettura– Modello service-oriented – Insieme di specifiche organizzate a Stack
I WEB SERVICES
Service Oriented ArchitectureService Oriented Architecture
Service Requestor
Discovery Agency
Service Provider
Service
Service Description
Client
Publish
Interact
Find
Service Description
Wire Stack
Description Stack
Discovery Agency Stack
Sec
uri
ty
Man
agem
ent
QoS
HTTPSOAP
XML SchemaWSDL
Quadro generaleQuadro generale
X languageSW Component
X languageSW Component
XML
WS
DL
Y languageSW Component
X interface
WS
DL
WS
DL
XML
X interface
X language
1. Analisi delle problematiche e delle soluzioni per adattare il componente agli standard dei web services
3. Nuovi scenari per i web services e limiti di WSDL
2. Verifica dell’effettiva interoperabilità con linguaggi diversi
Progettare un Web ServiceProgettare un Web Service
• Analisi del contesto di sviluppo
New Service Interface
Existing Service Interface
New Web Service
green field top-down
Existing Application
bottom-up meet-in-the-middle
Pattern di progettazione
Esposizione di un componente “legacy” secondo gli standard dei web services
(case study EBroker)
Esposizione di un componente “legacy” secondo gli standard dei web services
(case study EBroker)
Definizione del servizioDefinizione del servizio
• Individuazione delle funzionalità da esportare– Semplice codifica secondo le regole di
WSDL
• Definizione delle strutture dati– Estrazione della semantica dei dati– Trade off fra fruibilità e costi implementativi– Utilizzo di XML Schema per la descrizione
dei dati
Pattern di progettazione
Definizione delservizio
Stesura del documento WSDL Stesura del documento WSDL
(in un contesto bottom-up)
Implementazione del servizioImplementazione del servizio
• Realizzazione dei binding fra applicazione e descrizione WSDL– Mapping fra metodi del componente e
funzionalità esportate– Mapping fra dati applicativi e dati XML Schema
• Gestione operativa del binding:– istanziazione del componente– invocazione dei metodi – marshalling/unmarshalling dei dati – gestione della messaggistica SOAP– gestione della comunicazione di basso livello
• Deployment del servizio
Pattern di progettazione
Implementazionedel servizio
Definizione delservizio
(in un contesto bottom-up)
Utilizzo di una infrastruttura di supporto Utilizzo di una infrastruttura di supporto
Piattaforma di supportoPiattaforma di supporto
• Scopo– Fattorizzare molte delle problematiche comuni
all’implementazione di servizi– Fornire dei tool semiautomatici di supporto
anche per la fase di definizione del servizio– Abbattere i costi e i tempi di sviluppo
• Aspetti negativi– la scelta della piattaforma costituisce uno step
del workflow di progettazione dipendenza della soluzione dalla piattaforma scelta
Realizzazione dell’interazioneRealizzazione dell’interazione
Y PlatformRuntime
SOAP
HTTP
Y Service
Ser./Deser.Service
Ties
WSDLdescription
Ser./Deser.
1
X PlatformRuntime
X Client
Ser./Deser. Client
StubsSer./
Deser.
22
JAX-RPC compliantRuntime
Java Class
Serializzatori/DeserializzatoriSerializzatori/Deserializzatori1. Scrittura di serializzatori ad hoc per ogni classe
Non richiede alcuna modifica alle classi del componente Alti costi e tempi di sviluppo Richiede competenze adeguate sulla specifica SOAP e sulla
piattaforma adottata Produce una soluzione specifica per la piattaforma di supporto
scelta
2. Utilizzo dei serializzatori previsti dalle specifiche JAX-RPC Tempo di sviluppo nullo (per i serializzatori) Nessuna competenza richiesta Soluzione riutilizzabile con qualunque piattaforma JAX-RPC Dipendentemente dalla ingegnerizzazione del componente può
richiedere nessuna o molte modifiche ai sorgenti
Le classi da esportare devono essere dei JavaBean Le classi da esportare devono essere dei JavaBean
Sviluppo della prima soluzioneSviluppo della prima soluzione
1. Individuazione delle classi da esportare2. Modifica delle classi per renderle dei
JavaBean (le modifiche non devono influenzare il comportamento del componente)
3. Generazione automatica del WSDL4. Scelta della piattaforma di supporto Apache
Axis, compatibile JAX-RPC5. Utilizzo dei serializzatori di Axis per i JavaBean6. Deployment del servizio con Axis su Tomcat7. Sviluppo di un client Java8. Testing e analisi dei messaggi SOAP
TestingTesting
Java ClientJava Client EBrokerEBroker
Localhost – JVM 1.4
Tomcat Application Server
Axis Pacakge
Bean Ser/Deser
Client Stubs
Axis Runtime
Bean Ser/Deser
Ebroker Ties
Java
JavaTcpMonitorTcpMonitor
SOA
PSOAP
La soluzione funziona, ma…
WSDLdescription ?
Modellazione del case study EBrokerModellazione del case study EBroker
DBRecordVect
DBRecordVect()getFieldSetString()print()readExternal()writeExternal()
(from sql)
Vector(from util)
Externalizable
(from io)
DBRecord
DBRecord()DBRecord()get()getBigDec()getBool()getInt()getLong()getS()getTableRef()print()put()
(from sql)
Hashtable(from util)
#rec
DBFieldStruct
type : intkey : booleannullable : booleansize : intidentity : boolean
DBFieldStruct()DBFieldStruct()getName()getSkel()getType()isKey()parseQuotes()setName()setType()toSQL()
(from sql)DBStruct
dbType : int
DBStruct()DBStruct()getDbType()getName()getSkel()getTbl()getTbls()setDbType()setName()setTbls()
(from sql)
#dbRef
#tbls
DBTableStruct
DBTableStruct()DBTableStruct()getFld()getFldName()getFldNames()getFlds()getKEYFlds()getName()getSkel()searchKeyByName()setFlds()setName()
(from sql)#tableRef
#dbRef
#flds
String(from lang)
+name#name
#name
Modello delle classi da esportare dello EBroker
Alcune classi non vengono incluse nella generazione del WSDL in quanto non raggiungibili attraverso un legame statico
Carenze semanticheCarenze semantiche
<complexType name="Map"> <sequence> <element maxOccurs="unbounded" minOccurs="0" name="item"> <complexType> <all> <element name="key" type="xsd:anyType"/> <element name="value" type="xsd:anyType"/> </all> </complexType> </element> </sequence></complexType>
Inoltre si ha la stessa definizione di tipo Map per dati che modellano entità diverse!
Descrizione XML Schema della classe Hashtable
!
La descrizione XML Schema dei dati contenuta nel WSDL non rispecchia l’effettiva struttura dei dati, così come emerge dal
modello delle classi dello EBroker
Problema concettualeProblema concettuale
• I Web Services sono significativi in contesti di:
Integrazione fra sistemi disaccoppiati senza
pregressa conoscenza
La descrizione WSDL deve esplicitare la semantica del servizio
La descrizione WSDL deve esplicitare la semantica del servizio
??
Per il momento “semantica di tipo di dato”Per il momento “semantica di tipo di dato”
Nuova descrizione WSDLNuova descrizione WSDL
• Occorre:– Diversificare le Hashtable – Esplicitare il tipo di chiavi e valori – … altre operazioni di analoga natura
Realizzazione di appositi serializzatori
Realizzazione di appositi serializzatori
Reingegnerizzazione del componenteReingegnerizzazione del componente
Nuova descrizione WSDLNuova descrizione WSDL
!Le modifiche alle classi di interfaccia non devono implicare altre modifiche nel componente
ReingegnerizzazioneReingegnerizzazione
Hashtable(from util)
RecMap
RecMap()
(from map)
TblsMap
TblsMap()
(from map)
DBRecord
DBRecord()DBRecord()DBRecord()get()getBigDec()getBool()getInt()getLong()getS()print()put()getTableRef()getRec()setRec()setTableRef()
(from sql)
#rec
FldsMap
FldsMap()
(from map)
DBFieldStructBeanInfo
DBFieldStructBeanInfo()getPropertyDescriptors()getIcon()
(from sql)
DBRecordBeanInfo
DBRecordBeanInfo()getPropertyDescriptors()getIcon()
(from sql)
DBStructBeanInfo
DBStructBeanInfo()getPropertyDescriptors()getIcon()
(from sql)
DBFieldStruct
type : int = - 1key : boolean = falsenullable : boolean = falsesize : int = - 1identity : boolean = false
DBFieldStruct()DBFieldStruct()DBFieldStruct()getSkel()parseQuotes()toSQL()getName()setName()getType()setType()isKey()getDbRef()setDbRef()setKey()
(from sql)
DBStruct
dbType : int = DBMSType.NULL
DBStruct()DBStruct()getSkel()getTbl()getDbType()setDbType()getName()setName()getTbls()setTbls()
(from sql)
#dbRef
#tbls
DBTableStructBeanInfo
DBTableStructBeanInfo()getPropertyDescriptors()getIcon()
(from sql)
DBTableStruct
DBTableStruct()DBTableStruct()getFld()getFldName()getFldNames()getKEYFlds()getSkel()searchKeyByName()getFlds()setFlds()getName()setName()getDbRef()setDbRef()
(from sql)
#tableRef #flds
#dbRef
String(from lang)
+name#name #name
Nuova soluzione sviluppataNuova soluzione sviluppata Completa e corretta descrizione dei dati nel WSDL
ottima fruibilità del componente Contenimento dei costi di reingegnerizzazione grazie
all’ampio uso dell’ereditarietà Necessario realizzare appositi serializzatori per le
nuove classi introdotte, ma… … si eredita dai serializzatori di Axis per le Hashtable
apportando modifiche minime per la generazione automatica del WSDL
org.apche.axis.encoding.ser.MapDeserializer
it.capecod.sql.map.RecMapDeserializer
onStartElement()
it.capecod.sql.map.TblsMapDeserializer
onStartElement()
it.capecod.sql.map.FldsMapDeserializer
onStartElement()
Integrazione con Microsoft .NETIntegrazione con Microsoft .NET
• Scopo: realizzare un client .NET capace di consumare il web service EBroker
• Problemi: la descrizione XML Schema dei dati, sebbene valida, non è riconosciuta dai tool automatici di Visual Studio .NET
• Vincoli sulla soluzione:– Nessun onere deve ricadere sullo sviluppatore del
client realizzazione del client mediante tool automatici
– Nessuna modifica radicale alla struttura interna dello EBroker
Integrazione con Microsoft .NETIntegrazione con Microsoft .NET
• Nuova descrizione WSDL compatibile con i tool automatici di .NET
• Sviluppo di appositi serializzatori lato server per il mapping fra i dati dello EBroker e la nuova descrizione WSDL
newWSDL
description
Ser./Deser.
ClassiEBroker
ClassiEBroker
Costi di sviluppoCosti di sviluppo
Sviluppo di serializzatori ad hoc richiesta comprensione approfondita del meccanismo di serializzazione di Axis (non esiste documentazione!)
Rilevanti problemi implementativi Discreto livello di riuso dei serializzatori esistenti Costi e tempi di sviluppo del web service
complessivamente elevati
ma lato client…ma lato client…
Sviluppo di un client .NET capace di interagire con il web service Java a costi irrisori e tempi record
Sviluppo di un client .NET capace di interagire con il web service Java a costi irrisori e tempi record
Il processo di standardizzazione e le migliorie ai tool automatici possono portare ad un rapido cambiamento dell’attuale situazione dei costi
Il processo di standardizzazione e le migliorie ai tool automatici possono portare ad un rapido cambiamento dell’attuale situazione dei costi
(in un contesto bottom-up)
Web client
Soluzione finale con client .NETSoluzione finale con client .NET
Node B – JVM 1.4
EBrokerEBroker
Node A – Win2k OS
Tomcat Application Server
Internet Information Services (IIS)
.NET Framework
C# Code BehindC# Code Behind
Autogenerated ProxyAutogenerated Proxy
ASP.NET PageASP.NET Page
SOAP
C#
Internet Explorer
HTML Client PageHTML Client Page
TcpMonitorTcpMonitor
ISA
PI/.N
ET
Axis Runtime
EBroker TiesBean Ser/Deser
RecMap Ser/Deser
….. Ser/Deser
SO
AP
Java
HTTP
WSDLdescription
Discovery AgencyDiscovery Agency
Service Requestor
Discovery Agency
Service Provider
Service
Service Description
Client
Publish
Interact
Find
Service Description
Obiettivo: interazione dinamica in un contesto B2B globale
Web Service Architecture
WSDL non basta. Servono delle metainformazioni di categorizzazione
Discovery Agency come punto di incontro fra domanda e offerta di servizi
Registri UDDI – Modello d’usoRegistri UDDI – Modello d’uso
UDDI Business Registry
I motori di ricerca e le diverse applicazioni interrogano il registro alla ricerca dei servizi desiderati
3.
Service TypeReistrations
Le compagnie software e gli organismi di standardizzazione popolano il registro con la descrizione di differenti tipi di servizi
1.
BusinessRegistrations
Le aziende popolano il registro con la descrizione dei servizi che offrono
2.
Avviene l’integrazione vera e propria fra le diverse aziende che operano sul web
4.
Semantica per una interazione automatica
Semantica per una interazione automatica
Interazione automatica fra sistemi senza reciproca conoscenza
Interazione automatica fra sistemi senza reciproca conoscenza
Formalizzazione di concetti ed entitàFormalizzazione di concetti ed entità
Standardizzazione globalmente condivisaStandardizzazione globalmente condivisa++
Nuovo contesto di sviluppo: non più esposizione di un componente come web service (bottom-up) ma implementazione di un’interfaccia standard definita da appositi enti
Una semantica più evolutaUna semantica più evoluta
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/"> <rdf:Description rdf:about="http://www.example.org/index.html"> <dc:creator> <rdf:Description rdf:about="http://www.example.org/staffid/85740" /> </dc:creator> </rdf:Description></rdf:RDF>
E’ possibile una semantica che non sia semplice associazione concetto-standard?
http://www.example.org/index.html
http://www.example.org/staffid/85740
http://purl.org/dc/elements/1.1/creator
RDFRDF OWLOWL
Web Services e Business Process
Web Services e Business Process
Service Level Agreement
Composition
Business Level Agreement
Orchestration
Interface Description
Implementation Description
Policy
Presentation
XML Schema} WSDL
WSCI
BPEL4WS
Description Stack
Interfaccia dinamica e statefull del web service
Realizzazione di un web service come composizione di altri web service
Interfaccia statica e stateless del web service
BPEL4WSBPEL4WS
BPEL4WS
MicrosoftXLANG
IBMWSFL
BEA
BPELengine
BPELprocess
Ser
vice
Client Service
Service
Service
Business Process Execution Language for Web Services è una specifica eseguibile di un processo
Implementazione BPWS4J di IBMImplementazione BPWS4J di IBM
Progettare in modo nuovoProgettare in modo nuovo
• Applicazione come logica di flusso che coordina un insieme di web services:– Elevato riuso dei componenti– Produzione di applicazioni più comprensibili e
facilmente gestibili– Rapida modificabilità delle applicazioni– Realizzazione di applicazioni mediante
utilizzo di tool grafici
Standard?Standard?
ConclusioniConclusioni
• Si è acquisito il know-how necessario per esporre con successo un componente come web service, garantendo per esso una reale interoperabilità cross-platform
• Si sono compresi i nuovi scenari e le potenzialità dei web services nell’ambito della interazione automatica o guidata che potranno coinvolgere i progetti futuri
Università degli Studi di Bologna FACOLTA’ DI INGEGNERIA
Corso di Laurea in Ingegneria Informatica
I web services come soluzione per l’interoperabilità e l’interazione automatica fra
sistemi software
I web services come soluzione per l’interoperabilità e l’interazione automatica fra
sistemi software
Tesi di Laurea di: STEFANO RICCIARELLI
Relatore: Prof. ANTONIO NATALI
Correlatori:Prof. ENRICO DENTI
Ing. LUCA BICCI
Anno Accademico 2001-2002
FINEFINE