Service Oriented Architectures eWeb Services

Corso di Applicazioni TelematicheA.A. 2009-10

Prof. Simon Pietro Romano

Università degli Studi di Napoli Federico II

Facoltà di Ingegneria

Cos’è un Web Service?

• L’evoluzione delle tecnologie Internet ha due obiettivi principali:• soddisfare i bisogni degli utenti• integrare sistemi informativi eterogenei e sempre più

complessi• Web Service:• Web Service:

• componenti software distribuiti ed accoppiati in modo lasco

• forniscono un servizio ben definito• servizio inteso non necessariamente come un servizio finale,

ma come un componente indipendente che può essere usato per fornire un servizio finale

• sono accessibili da programmi mediante protocolli Internet standard

Web Services secondo il W3C

“Software applications identified by a URI, whose interface and bindings are capable ofbeing identified , described and discovered

“Software applications identified by a URI, whose interface and bindings are capable ofbeing identified , described and discoveredbeing identified , described and discoveredby XML artifacts and supports directinteractions with other software applicationsusing XML based messages via Internet-based protocls” (W3C).

being identified , described and discoveredby XML artifacts and supports directinteractions with other software applicationsusing XML based messages via Internet-based protocls” (W3C).

Web Service: definizioni

• Componenti per la programmazioneweb:• auto-contenuti, auto-descrittivi, modulari• possono essere, sempre tramite• possono essere, sempre tramite

interazioni basate sul web:• pubblicati• localizzati• invocati

Caratteristiche dei Web Service

• Riutilizzabili• Indipendenti da:

• piattaforma (Unix, Windows, Mac, …)

• implementazione (VB, C#, Java, ...)• architettura sottostante (.NET, J2EE, …)• architettura sottostante (.NET, J2EE, …)

• Accessibili mediante un’interfaccia standard auto-descrittiva

• Combinano opportunamente:• lo sviluppo basato sui componenti• gli standard web

Service Oriented Architecture (SOA)

• I WS si basano sulla cosiddetta Service Oriented Architecture (SOA)

• Tre componenti principali:1. Service Provider

• rende disponibile il servizio e pubblica il contratto che ne descrive l’interfaccia, tramite un’apposita entità detta ne descrive l’interfaccia, tramite un’apposita entità detta Broker

2. Service Requestor o Consumer• invia richieste al service broker; quest’ultimo cerca il

servizio compatibile3. Service Registry o Broker

• fornisce informazioni al consumer riguardo quale servizio utilizzare (ivi compresa la sua localizzazione)

Ricerca di un servizio

RegistroRichiesta al registro

Link verso il servizio

Descrizione

Scenario di richiesta di un servizio

Client

Service

Descrizione

Richiesta della descrizione del servizio

Descrizione del servizio

Invocazione del servizio

Chiamate

Risposte

WS: non così nuovi…

• Sun RPC (Remote Procedure Call) �1985

• CORBA (Common Object Resource Broker) �1992

• DCE/RPC �1993

• Microsoft COM �1993

• Microsoft DCOM �1996

• Java RMI (Remote Method Invocation) � 1996

…ma comunque diversi!

• Neutrali rispetto alla piattaforma• Basati su standard aperti• Interoperabili• Basati sull’impiego di componenti• Basati sull’impiego di componenti

software ampiamente diffusi• parser XML• server HTTP

ServiceProvider

Service

Web Services: ruoli ed interazioni

ServiceRegistry

ServiceUserFind

ServiceProvider

Comunicazione: HTTP

Dati: XML

Interazione: SOAP

Web Services: architettura

ServiceBroker

ServiceUser

UDDI/WSDL

Find

Web Services: scenario tipico di interazione

• Il Provider crea e definisce il servizio utilizzando illinguaggio WSDL (Web Services Description Language)

• Il Provider registra il servizio tramite UDDI (Universal Description Discovery and Integration)

• L’utente ‘trova’ il servizio effettuando una ricercanel registro UDDI

• L’applicazione utente:• si collega (‘binding’) al Web Service• invoca le operazioni da esso definite, tramite il

protocollo SOAP (Simple Object Access Protocol)

Stack di tecnologie per i web services

• UDDI (Universal Description, Discovery and Integration):

• le ‘pagine gialle’ dei servizi Web

• WSDL (Web Services Description Language):

• descrizione dei messaggiWSDL

UDDI

Emerging layers

• descrizione dei messaggi

• SOAP (Simple Object Access Protocol):

• protocollo per lo scambio di messaggi

• XML (eXtensible Markup Language):

• formato per lo scambio dei dati

Internet Protocols(HTTP, FTP, ...)

SOAP

WSDL

DiscoveryDiscovery

Web Services: protocolli

WebWeb

UDDIUDDI

Find a ServiceFind a Service

http://yourservice.com

http://www.uddi.org

Link to discovery documentLink to discovery document

Let me talk to you (SOAP)Let me talk to you (SOAP)

How do we talk? (WSDL)How do we talk? (WSDL)

Web Web

ServiceService

WebWeb

Service Service

ConsumerConsumer

return service response (XML)return service response (XML)

http://yourservice.com/svc1

returnreturn serviceservice descriptionsdescriptions (XML)(XML)

http://yourservice.com/?WSDL

HTML with link to WSDLHTML with link to WSDL

Servizi di comunicazione e trasporto

SOAP

• Strato di trasporto:• XML è usato per descrivere la struttura dei

messaggi scambiati tra servizi Web

• Il messaggio è costituito da:• l’identificativo SOAP

HTTP

TCP/IP

Transport

• l’identificativo

• il destinatario

• una lista di argomenti eventuali

• il nome dell’operazione invocata

• una lista di valori di ritorno attesi

• altri parametri

Trasporto

• HTTP, con il metodo POST, è il più comune…

• …ma è possibile:• utilizzare HTTP, con il metodo GET

• adoperare altri protocolli ‘classici’• FTP• FTP

• SMTP

• adoperare altri protocolli di nuova generazione:• Jabber (XMPP)

• BEEP

SOAP

• Un protocollo basato su XML e tipicamenteincapsulato in HTTP

• Costituito da:• un ‘involucro’ esterno per descrivere:

• ciò che c’è in un messaggio• ciò che c’è in un messaggio• come processare il messaggio

• un insieme di regole di codifica• per rappresentare istanze di tipi di dati definiti a livello

applicativo

• una convenzione per rappresentare chiamate a procedure remote, insieme alle relative risposte

Messaggio SOAP

• La struttura dei messaggi SOAP• la busta

• l’header

• Il corpo del messaggio

Busta SOAP <SOAP:Envelopexmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

</SOAP:Envelope>

Header SOAP <SOAP:Header><example:header xmlns:example="www.y.com"></example:header>

</SOAP:Header>

Corpo del messaggio SOAP

<SOAP:Body><example:body xmlns:example="www.y.com"></example:body>

</SOAP:Body>

Applicazione Client

Client SOAP

XML API HTTP API

HTTP

Schema della comunicazione SOAP

HTTP

Server SOAP

XML API HTTP API

Applicazione Server

Chiamata al metodo remoto

CLIENT

Stack

a=5

b=6

SERVER

Stack

a=5

b=6

SOAP SOAP

HTTP

XML

<a>5 </a>

<b>6 </b>

Invio del messaggio di risposta

CLIENT

Stack

Result=30

SERVER

Stack

Result = 30

SOAP SOAP

HTTP

XML

<Result>30

</Result>

Esempio di richiesta SOAPPOST /AT-WebServicesSample2/services/DayOfWeekPort HTTP/1.0

Content-Type: text/xml; charset=utf-8

Accept: application/soap+xml, application/dime, multipart/related, text/*

User-Agent: Axis/1.4

Host: localhost:8080

Cache-Control: no-cache

Pragma: no-cache

SOAPAction: "getdayofweek"

Content-Length: 304Content-Length: 304

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<soapenv:Envelopexmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<soapenv:Body>

<date xsi:type="xsd:date">2010-04-12</date>

</soapenv:Body>

</soapenv:Envelope>

Esempio di risposta SOAP

HTTP/1.1 200 OK

Server: Apache-Coyote/1.1

Content-Type: text/xml;charset=utf-8

Date: Mon, 12 Apr 2010 08:56:35 GMT

Connection: close

<?xml version="1.0" encoding="utf-8" standalone="no"?><?xml version="1.0" encoding="utf-8" standalone="no"?>

<soapenv:Envelopexmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<soapenv:Body>

<dayOfWeek>OK ciccio...the day is a : Monday</dayOfWeek>

</soapenv:Body>

</soapenv:Envelope>

WSDL• Documento XML che contiene la descrizione

dell’interazione client-server• Un documento WSDL completo deve dare due tipi

di informazioni:• Descrizione del servizio di livello applicativo (interfaccia

astratta)astratta)• Vocabolario• Messaggi• Interazioni

• Dettagli dipendenti dal protocollo specifico• quale protocollo di comunicazione usare:

• es. SOAP su HTTP• tipi di interazione su questo protocollo• endpoint (indirizzo di rete)

WSDL: struttura

<wsdl:definition>

<wsdl:Types>…</wsdl:Types><wsdl:Message>…</wsdl:Message>

<wsdl:PortType>

<wsdl:Message>…</wsdl:Message>

<wsdl:Message>…</wsdl:Message>

<wsdl:PortType><wsdl:PortType>

• Tipi:• definizione dei tipi di dati del Web Service (uso di

XMLSchema)

• Messaggio:• definizione dei messaggi che fanno riferimento ai

tipi

• Tipo di porta:• insieme di operazioni (action) implementate da un

Web Service

</wsdl:definition>

<wsdl:Service>…</wsdl:Service>

<wsdl:Service>…</wsdl:Service>

<wsdl:Service>…</wsdl:Service>

<wsdl:PortType>…</wsdl:PortType>

<wsdl:Service>…</wsdl:Service>

<wsdl:PortType>…</wsdl:PortType>

<wsdl:PortType>…</wsdl:PortType>

<wsdl:Service>…</wsdl:Service>

<wsdl:Binding>…</wsdl:Binding>

Web Service• una porta è un punto di terminazione identificato in

maniera univoca da:• un identificativo (ad es: URL)• un binding

• Binding WSDL/SOAP:• un protocollo concreto d’accesso a una porta e un

formato dei messaggi e dei dati per questa porta

• Servizio:• una collezione di porte (le instanze delle porte

WSDL)

WSDL in sintesi

Types Definizioni tipi di dati

Message Firme di richesta e risposta per ogni metodo (≈ IDL)

Port Type <servizio, protocollo> �operazionioperazioni

Operation metodo � messaggi

Binding Specifica del Protocollo e del formato dei dati

Service { Port � binding }

Port Indirizzo (≈ URL)

WSDL: un esempio

UDDI• Universal Description, Discovery and Integration

• insieme di specifiche che definiscono un modo per pubblicare e cercare servizi attraverso una repository centralizzata

• Obiettivo:• fornire un catalogo mondiale che permetta di ricercare i Servizi Web

in base allo stesso principio delle pagine gialle• Definizione delle informazioni da fornire per ciascun servizio e del tipo di

codificacodifica• API di ricerca ed aggiornamento che descrivono come si può accedere

alla repository ed aggiornare le informazioni

• La riuscita di UDDI richiede che i diversi fornitori di Servizi Web si accordino sulla definizione di criteri comuni e di determinate categorie di servizi• Operatori: Microsoft, IBM, SAP e HP

• Problematico…cfr. slide seguente!

UDDI: un registro pubblico?

UDDI: un sito di esempio ancora “vivo”

http://www.xmethods.com/ve2/index.po

Discovery – UDDI

UDDI RegistryInquiry

Publish

Discovery – UDDI

UDDI RegistryInquiry

Publish

UDDI

Pagine biancheIdentità del fornitore, indirizzo fisico ed elettronico, qualificazioni che fanno riferimento a tassonomie

industriali standard

Le specifiche UDDI definiscono le tre parti costituenti il registry

Pagine gialle

Pagine verdi

La descrizione dei servizi offerti

Informazioni sui modelli di accesso al servizio e i differenti modelli di dati sottostanti

Servizi Business

• Si tratta generalmente di funzioni legate al commercio elettronico

• Riproduzione in un mondo virtuale delle transazioni commerciali del mondo reale• transazioni, contratti, fatturazione, pagamenti, ecc.

• I servizi Web Business mettono a disposizione • I servizi Web Business mettono a disposizione degli sviluppatori un insieme di specifiche che facilitano lo sviluppo di applicazioni Web per settori applicativi specifici

• Per quanto riguarda gli aspetti tecnici, la specifica di alcuni Servizi Business è iniziata prima delle attività di standardizzazione del W3C

Servizi Business

� ebXML e RosettaNet:

� per formalizzare un’infrastruttura completa per l’e-commerce

� BitzTalk di Microsoft:

� formalizzazione dello scambio elettronico dei documenti professionali (fatture, ordini, ecc.) tra applicazioni Web distribuite

� WSFL (Web Services Flow Language) di IBM, XLANG di Microsoft e WSCL (Web Services Conversation Language) di HP

� per la specifica della composizione di un’applicazione Web per

ebXMLRosettaNet

tpaML

ebXMLRosettaNet

tpaML

BizTalkBizTalk

� per la specifica della composizione di un’applicazione Web per l’esecuzione di processi business

� BPML (Business Process Modeling Language) e BPQL del consorzio BPMI:

� una parte delle specifiche copre la sincronizzazione dei processi business in diverse aziende (es: gestione delle relazioni con i clienti, logistica, ecc.)

� WSUI (Web Service User Interface) di Epicentric, WSXL (Web Services Experience Language) di IBM e WSIA (Web ServicesInteractive Applications) di OASIS:

� Gestione dell’accesso ai servizi Web

WSFL – XLANGBPMLBPQL

WSFL – XLANGBPMLBPQL

Servizi Business

WSUIWSXLWSIA

WSUIWSXLWSIA

Piattaforme di sviluppo e esercizio

• Web Service su piattaforma leggera• Server HTTP e Parser XML• Esempi: Apache SOAP, Apache Axis, SOAP::Lite (Perl),

PHPSOAP (PHP), WhiteMesa SOAP (C++), SOAP for ADA, Smalltalk Web Services

• Web Service su Application Server• Valori aggiunti: gestione dell’accesso concorrente, gestione delle • Valori aggiunti: gestione dell’accesso concorrente, gestione delle

transazioni, sicurezza e autenticazione, infrastrutture, tool di sviluppo

• Classificazione dei fornitori:• Basi di dati: DBMS tradizionale + infrastruttura XML per integrare

l’architettura UDDI/WSDL/SOAP: Oracle, IBM, Sybase• Middleware: BEA, Vitia, IBM, Progress• Sistemi operativi: SUN, IBM, Microsoft

Supporto Java per Web Services

• JAX-RPC (Java API for XML-RPC):

• è di fatto Java RMI (Remote Method Invocation) su SOAP

• fornisce un’interfaccia remota per lo scambio di messaggi SOAP in stile RPC

• SAAJ (SOAP API with Attachments for Java):

• è un’API che modella la struttura di un messaggio SOAP ed implementa alcune funzionalità del protocollo per la comunicazione

• JAXM (Java API for XML Messaging):

• è simile a JMS (Java Message Service)

• fornisce un’infrastruttura di messaging per spedire e ricevere messaggi SOAP

SOAP Toolkit: API- vs Stub-based

• Un toolkit SOAP è un’API usata per spedire e ricevere messaggi SOAP

• Ci sono dozzine di SOAP toolkit in molti linguaggi:• Java, C e C++, C#, VB.NET, Perl, ecc.

• Un toolkit stub-based usa il tradizionale modello di programmazione basato su RPC:

• uno stub RPC per comunicare con un Web service• uno stub RPC per comunicare con un Web service• client-side si modella un Web service come un oggetto

(remoto) che espone dei metodi• JAX-RPC è lo standard stub-based di EJB 2.1

• Un toolkit API-based è usato per costruire messaggi SOAP (Envelope, Header, Body, ecc.) esplicitamente

• SAAJ è lo standard SOAP API in EJB 2.1

Modelli di programmazione JAX-RPC

1. Generated Stub

2. Dynamic Proxy

3. DII (Dynamic Invocation Interface)

Generated Stub

• Il toolkit JAX-RPC genera, in accordo con la descrizione WSDL:• l’interfaccia java RMI

• il relativo stub

• Interfaccia RMI e stub possono poi essere • Interfaccia RMI e stub possono poi essere pubblicati in un JNDI ENC (EnvironmentNaming Context)

• In questo modello lo stub è generato a deployment time

Dynamic Proxy

• Un dynamic proxy è usato nello stesso modo di generated stub, ma:• l’implementazione dello stub e l’interfaccia remota

sono generati dinamicamente, a run-time

• Come per il caso precedente, la generazione • Come per il caso precedente, la generazione dell’interfaccia remota avviene in accordo con il documento WSDL che descrive le interfacce come porte• ogni porta può avere una o più operazioni• Porte e operazioni sono analoghe, rispettivamente,

ad interfacce e metodi Java

DII (Dynamic Invocation Interface)

• JAX-RPC supporta un’ulteriore API, ancora più dinamica, chiamata DII (Dynamic InvocationInterface)• DII permette di assemblare chiamate a metodi SOAP

dinamicamente, a run time• L’idea è la stessa di CORBA Dynamic Invocation

InterfaceInterface• JAX-RPC DII permette di:

• creare oggetti che rappresentano singole operazioni di Web Service, altrimenti modellati come metodi di un’interfaccia remota

• invocare tali operazioni senza la necessità di accedere ad una service factory o di usare uno stub e un’interfaccia remota

AXIS: Apache eXtensible Interaction System

• Un SOAP Engine open source, caratterizzato da:• configurazione/deployment molto flessibili (file “.wsdd”)

• supporto per drop-in deployment (Java Web Service, JWS)

• supporto per tutti i tipi base• supporto per tutti i tipi base

• serializzazione/deserializzazione automatica di Java Bean e possibilità di definire serializer/deserializer“custom”

• RPC e message-based provider

• Supporto per WSDL (WSDL2Java, Java2WSDL)

• Trasporto: HTTP, JMS (stabili)

Domande?

4444