Corso di Applicazioni TelematicheA.A. 20010-11

Prof. Simon Pietro Romano

Università degli Studi di Napoli Federico II

Facoltà di Ingegneria

Service Oriented Architectures e

Web Services

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:• 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 of

being identified, described and discovered

by XML artifacts and supports direct

interactions with other software applications

using XML based messages via Internet-

based protocls” (W3C).

Web Service: definizioni

• Componenti per la programmazione

web:

• auto-contenuti, auto-descrittivi, modulari

• 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, …)

• 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 Broker

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

servizio compatibile

3. Service Registry o Broker• fornisce informazioni al consumer riguardo quale

servizio utilizzare (ivi compresa la sua localizzazione)

Ricerca di un servizio

Client

Service

RegistroRichiesta al registro

Link verso il servizio

Descrizione

Richiesta della descrizione del servizio

Descrizione del servizio

Invocazione del servizio

Chiamate

Risposte

Scenario di richiesta di un servizio

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

software ampiamente diffusi

• parser XML

• server HTTP

ServiceRegistry

ServiceUser

ServiceProvider

Find

Service

Web Services: ruoli ed interazioni

ServiceBroker

ServiceUser

ServiceProvider

UDDI/WSDL

Find

Comunicazione: HTTP

Dati: XML

Interazione: SOAP

Web Services: architettura

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 ilprotocollo 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 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

UDDI

Emerging layers

Discovery

Let me talk to you (SOAP)

Web Services: protocolli

How do we talk? (WSDL)

Web Service

WebService

Consumer

UDDI

Find a Service

return service response (XML)

http://yourservice.com/svc1

return service descriptions (XML)

http://yourservice.com/?WSDL

HTML with link to WSDL

http://yourservice.com

http://www.uddi.org

Link to discovery document

Servizi di comunicazione e trasporto

SOAP

HTTP

TCP/IP

Transport

• Strato di trasporto:

• XML è usato per descrivere la struttura dei

messaggi scambiati tra servizi Web

• Il messaggio è costituito da:

• 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

• 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

• come processare il messaggio

• un insieme di regole di codifica

• per rappresentare istanze di tipi di dati definiti a livelloapplicativo

• 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

Server SOAP

XML API HTTP API

Applicazione

Server

Schema della comunicazione SOAP

Chiamata al metodo remoto

CLIENT

Stack

a=5

b=6

SOAP

SERVER

Stack

a=5

b=6

SOAP

HTTP

XML

<a>5 </a>

<b>6 </b>

Invio del messaggio di risposta

CLIENT

Stack

Result=30

SOAP

SERVER

Stack

Result = 30

SOAP

HTTP

XML

<Result>

30

</Result>

Esempio di richiesta SOAP

POST /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: 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"?>

<soapenv:Envelope

xmlns: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)• 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:definition>

<wsdl:Service>

…

</wsdl:Service>

<wsdl:Service>

…

</wsdl:Service>

<wsdl:Service>

…

</wsdl:Service>

<wsdl:Types>

…

</wsdl:Types>

<wsdl:Message>

…

</wsdl:Message>

<wsdl:PortType>

…

</wsdl:PortType>

<wsdl:Service>

…

</wsdl:Service>

<wsdl:Message>

…

</wsdl:Message>

<wsdl:Message>

…

</wsdl:Message>

<wsdl:PortType>

…

</wsdl:PortType>

<wsdl:PortType>

…

</wsdl:PortType>

<wsdl:Service>

…

</wsdl:Service>

<wsdl:Binding>

…

</wsdl:Binding>

• 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

• 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>

operazioni

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 codifica

• 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 bianche

Pagine gialle

Pagine verdi

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

industriali standard

La descrizione dei servizi offerti

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

Le specifiche UDDI definiscono le tre parti costituenti il registry

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 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 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

ebXMLRosettaNet

tpaML

Servizi Business

BizTalk

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

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

• 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

pubblicati in un JNDI ENC (Environment

Naming 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 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 InvocationInterface

• 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

• 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)

4444

Domande?