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