Tecnologia dei Servizi Grid e cloud computing - Lezione 004b 0 Lezione 4b - 5 novembre 2009 Il...

Tecnologia dei Servizi “Grid e cloud computing” - Lezione 004b 1

Lezione 4b - 5 novembre 2009

Il materiale didattico usato in questo corso è stato mutuato da quello utilizzato da Paolo Veronesi per il corso di Griglie Computazionali per la Laurea Specialistica in Informatica tenuto nell’anno accademico 2008/09 presso l’Università degli Studi di Ferrara.

Paolo [email protected], [email protected]://www.cnaf.infn.it/~pveronesi/unife/

Università degli Studi di Bari – Corso di Laurea Specialistica in Informatica

“Tecnologia dei Servizi “Grid e cloud computing” A.A. 2009/2010

Giorgio Pietro Maggi [email protected], http://www.ba.infn.it/~maggi


SOA…overview

La parola d’ordine delle situazioni di sviluppo applicativo odierne è integrazione.

Le applicazioni sviluppate si trovano a condividere flussi di dati già realizzati in diverse altre applicazioni esistenti.

La prima questione è lo scambio di informazioni strutturate tra diversi ambienti applicativi… Necessità di definire un formato comune di scambio di dati.

La seconda questione è il riutilizzo delle componenti software... Gli sviluppi di nuove applicazioni richiedono funzionalità sempre più

complesse da integrare con i sistemi operativi. La pressione sui costi e sul ritorno d’investimento.

Da queste osservazioni si avverte la necessità… Uno standard indipendente dalla piattaforma applicativa. Protocollo di dialogo tra chiamante e componente applicativa indipendente

dal trasporto, dal punto di vista semantico completo, e sicuro. Seguendo le linee di questa evoluzione, oggi nelle architetture

applicative si ragiona in termini di componenti che offrono servizi applicativi, sia verso l’interfaccia utente sia verso altre componenti e applicazioni.


GLI OBIETTIVI

L’introduzione dei servizi nelle architetture odierne

Quali sono i principi che regolano SOA Cosa rappresentano i Web Service per SOA


GLI OBIETTIVI


Quali sono i principi che regolano SOA Cosa rappresentano i Web Service per SOA


Tecniche di design

Design e analisi orientate a oggetti… considerare un problema di dominio e una soluzione logica dalla

prospettiva di oggetti.

Design basato a componenti… un’evoluzione del paradigma a oggetti; forniscono funzionalità ben definite da un insieme coesivo di oggetti; sono un meccanismo per impacchettare, gestire e esporre servizi;

Design orientato a servizi… servizio è implementato come un’entità software a granatura fluibile; esiste come una singola istanza e interagisce con applicazioni ed altri

servizi attraverso un modello di comunicazione debolmente accoppiata, basata sui messaggi.


…perché SOA L’idea fondamentale è che nelle architetture a servizi il

patrimonio informativo di un’azienda non è più un insieme di applicazioni tra loro isolate e che comunicano attraverso tecnologie di integrazione di applicazioni.

E’ invece organizzato in una collezione di servizi pubblicati su un’infrastruttura di comunicazione (enterprise service bus (ESB)) e che, quando ce n’è bisogno, possono essere utilizzati da più applicazioni.

I web services sono un fattore chiave per la pubblicazione dei servizi in modo standard.

Riusabilità, integrazione dei sistemi, flessibilità e sviluppo incrementale, sono questi i benefici maggiormente percepiti dalle aziende che cominciano a utilizzare tecnologie e metodologie che si richiamano a SOA.


GLI OBIETTIVI


Quali sono i principi che regolano SOA

Cosa rappresentano i Web Service per SOA


SOA… LA TEORIA

L’architettura service oriented è un’architettura software con diverse caratteristiche.

Il più importante aspetto è la separazione del servizio dalla sua interfaccia.

Si divide il “cosa” dal ”come”. SOA consiste delle seguenti sei entità configurate

insieme per supportare il paradigma ‘find, bind, e execute’.


1 Service Consumer 2 Service Provider 3 Service Registry 4 Service Contract 5 Service Proxy 6 Service Lease


…PIU’ DA VICINO 1 Service Consumer localizza il servizio nel registro. 2 Service Provider accetta, esegue le richieste del

consumer. 3 Service Registry directory contenente i servizi

disponibili. 4 Service Contract specifica il formato di richiesta e

risposta. 5 Service Proxy Il service provider fornisce un service

proxy al service consumer. Il service consumer esegue la richiesta. Il service proxy cerca un contratto e un riferimento nel registro. Si forma il messaggio di richiesta. Si esegue la richiesta per conto del consumer.

6 Service Lease specifica il tempo per cui il contratto è valido.


CARATTERISTICHE DI SOA

I servizi devono essere: Ricercabili e dinamicamente legati: il service

consumer non conosce il formato del messaggio di richiesta e/o di risposta, o la locazione del servizio finché il servizio risulta utile.

Auto-contenuto e modulare: la modularità è associata alla progettazione di servizi, quindi i servizi possono essere più facilmente aggregati in un’applicazione con dipendenze note.

Interoperabilità: la capacità del sistema di usare diverse piattaforme e linguaggi per comunicare.


…e ancora…

Debolmente accoppiati: il consumer di un servizio non ha dettagliate conoscenze del servizio prima di invocarlo, perciò il consumer e il provider sono debolmente accoppiati.

Interfaccia di rete indirizzabile: un consumer su una rete deve essere capace di invocare un servizio attraverso la rete.

Interfacce a grana grossa: un metodo di servizio che

ritorna più dati, meno specifici.


…infine

Allocazione trasparente: riducono le dipendenze attraverso l’utilizzo di legami dinamici, per cui l’allocazione del servizio irrilevante; quindi il service consumer non ha dirette dipendenze sul service contract, l’implementazione del contratto può muoversi da locazione in locazione.

Componibilità: è correlato alla sua struttura modulare, che abilita il servizio ad essere assemblato in applicazioni, lo sviluppatore non ha nozione di quando progettare il servizio.

Auto-riparazione: capacità realizzabile solo se il client interagisce con le interfacce dei servizi e non con la sua implementazione.


GLI OBIETTIVI


Quali sono i principi che regolano SOA Cosa rappresentano i Web Service

per SOA


WEB SERVICE

I web service sono una tecnologia ben soddisfatta implementando un’architettura service oriented.

I web service sono applicazioni auto-descrittivi e modulari. Espone nella logica di business come i servizi che possono

essere pubblicati, scoperti e invocati. Basato su standard XML. I web service possono essere sviluppati come applicazione

debolmente accoppiate usando alcuni linguaggi di programmazione, protocolli, o piattaforme.

Questo facilita il rilascio di applicazioni di business e la consegna di un servizio accessibile da chiunque, ogni qualvolta necessario e usando qualsiasi piattaforma.


Caratteristiche i web service sono auto contenuti…

Dal lato client non è richiesto software addizionale. Dal lato server, sono richieste solo web service e ingegneria a servlet.

i web service sono auto descritti… Né il client né il server conoscono o si preoccupano di nulla al di là del formato e del

contenuto di richieste e i messaggi di risposta (integrazione di applicazioni debolmente accoppiate). La definizione del formato dei messaggi viaggia con il messaggio. Non sono richiesti repository di metadati esterni o tool di generazione di codice.

i web service sono modulari… I web service sono una tecnologia per spiegare e fornire accesso alle funzioni di

business sul web. i web service sono linguaggi indipendenti e interoperabili…

L’interazione tra un service provider e un service consumer è progettato per essere completamente indipendente dalla piattaforma e dal linguaggio. Questa interazione richiede un documento WSDL per definire l’interfaccia e descrivere il servizio, solo con un protocollo di rete (solitamente HTTP). Poiché il service provider e il service consumer non hanno idea di quale piattaforma o linguaggio si sta usando, l’interoperabiltà è un dato di fatto.


…e ancora

I web service sono aperti e basati sugli standard. Un larga parte delle tecnologie web service sono state costruite

utilizzando progetti open source. I web service sono dinamici. I web service sono componibili. I web service possono essere pubblicati, allocati, e invocati attraverso il

web. Gli standard richiesti per fare questo sono:

Web Service Description Language (WSDL) Simple Object Access Protocol (SOAP) Universal Description, Discovery, and Integration (UDDI)


Introduzione ai Web Service

Un Web Service è un sistema software progettato per supportare l'interoperabilità tra diversi elaboratori su di una medesima rete.

L’architettura dei Web Service mira a sfruttare le potenzialità di Internet fornendo un meccanismo di comunicazione tra applicazioni(application-to-application).



I Web Service consentono una comunicazione fra programmi, database, componenti software sfruttando XML come “lingua franca”: utilizzando un documento XML come messaggio, un programma può spedire una richiesta ad un altro Web Service sulla rete (ed eventualmente ottenere risposta). Lo standard dei Web Service definisce:

• Il formato del messaggio;

• Specifica l’interfaccia verso la quale il messaggio deve essere spedito;

• Definisce meccanismi per pubblicare e rintracciare le interfacce Web Service;



I Web Service forniscono quindi un meccanismo standard per interfacciare la rete con sistemi software di back-end ( ad esempio database management system, J2EE, .NET, CORBA, Enterprise Resource Planning –ERP). Le interfacce Web Service ricevono messaggi XML dalla rete, trasformano i dati secondo le esigenza delle applicazioni back-end, ed eventualmente forniscono dei messaggi di risposta.

Servizio back-end

Messaggio XML di richiesta servizio

Trasformazione della richiesta secondo applicazione back-end

Messaggio XML di risposta al servizio

Trasformazione del risultato secondo il formato del messaggio

Esecuzione servizio


Interazione con Web Service

Lo standard e la tecnologia Web Service in generale forniscono 2 principali modalità di interazione fra applicazioni:

Remote Procedure Call (online). In questa caso, una richiesta verso un WS ha la forma di chiamata a metodo o a procedura remota, con ben specificati parametri di input e output. La richiesta e la risposta sono disposte come scambio di messaggi in maniera sincrona, cioè l’applicazione che invia il messaggio rimane in attesa della risposta

Document Oriented (batch). In questo caso la richiesta verso un WS ha la forma di un documento XML completo che deve essere processato. Il messaggio inviato viene accodato e processato in maniera asincrona. Successivamente chi fornisce il servizio comunica una risposta (ad esempio via email)


I vantaggi nell’utilizzo dei Web Service sono molteplici:• Permettono la comunicazione in modo semplice ad applicazioni

diverse, residenti su piattaforme hardware diverse;• Utilizzano standard e protocolli "open"; i protocolli ed il formato dei

dati è in formato testuale, cosa che li rende di più facile comprensione ed utilizzo da parte degli sviluppatori

• Possono essere facilmente utilizzati, in combinazione l'uno con l'altro (indipendentemente da chi li fornisce e da dove vengono resi disponibili) per formare servizi "integrati" e complessi.

• Consentono il riutilizzo di infrastrutture ed applicazioni già sviluppate e sono (relativamente) indipendenti da eventuali modifiche delle stesse

Vantaggi dei Web Service


Requisiti dei Web Service

I WS sono quindi programmi che interagiscono tra di loro attraverso messaggi, ma per fare questo devono essere in grado di: Trovare sul web il WS che fornisce il servizio che gli

interessa. Capire quali informazioni scambiare per poter comunicare

con il WS.(Formato della richiesta del servizio, formato della risposta del servizio)

Negoziare il livello della qualità del servizio, i meccanismi di sicurezza o di affidabilità, ecc.


Ruoli nella architettura WS All’interno dell’architettura WS possono essere

individuati 3 ruoli principali nell’ambito del suo funzionamento:

Il fornitore di un servizio, che espone un’interfaccia e mette a disposizione un insieme di operazioni che possono invocate da client.

Il consumatore del servizio, che inoltra delle richieste ad un fornitore per avere un determinato servizio.

Un servizio di registrazione che mette a disposizione un meccanismo per consentire a fornitore e consumatore di trovarsi e comunicare(paginegialle).

Servizio di registrazioneServizio di

registrazioneUDDI

ConsumatoreConsumatore FornitoreFornitore

WSDL WSDL

SOAP


Tecnologie dei Web Service

L’infrastruttura dei WS si basa su diverse tecnologie XML per il trasporto, lo scambio e la trasformazione dei dati tra programmi e applicazioni:

XML (Extensible Markup Language), la base sulla quale sono fondati i Web Service, fornisce un linguaggio per definire e processare i dati.

SOAP (Simple Object Access Protocol), un formato XML che fornisce un meccanismo di packaging dei messaggi, attraverso la definizione di una “busta” per la creazione e trasmissione dei messaggi XML.

WSDL (Web Services Description Language), un formato XML per definire le interfacce dei WS.

UDDI (Universal Description, Discovery and Integration), un meccanismo per il registry (registrazione) e il discovery (ritrovamento) dei WS, utilizzato per registrare, categorizzare, ritrovare le interfacce WS.


registrazioneUDDI


WSDL WSDL

SOAP


Scenario d’uso

Un fornitore che deve pubblicare il proprio servizio deve come prima cosa descriverlo attraverso un documento WSDL;

Deve pubblicarlo attraverso UDDI in un contenitore di servizi che prende il nome di UDDI repository. Per semplificare l'individuazione del servizio lo stesso dovrà essere organizzato per categorie.

Un consumatore dovrà invece utilizzare i servizi UDDI per cercare, in base ad alcuni criteri di ricerca, l'insieme dei servizi a cui è interessato.

Ottenuto il relativo documento WSDL, potrà effettuare richieste ed avere risposte dal fornitore, attraverso gli strumenti SOAP.


registrazioneUDDI


WSDL WSDL

SOAP


SOAP - introduzione Il Simple Object Access Protocol (SOAP) è una delle specifiche più

importanti nelle tecnologie WS. L’ultima reccomendation del W3C è del Giugno 2003 e fornisce la versione 1.2.

SOAP: Definisce un meccanismo di packaging per il trasporto dei dati da

un punto all’altro della rete. Rappresenta una estensione del protocollo HTTP per lo scambio di

messaggi XML: consente la spedizione di messaggi XML su HTTP e la relativa ricezione di una risposta.

Per gestire correttamente tali messaggi, un server HTTP (Apache o IIS) deve disporre di un SOAP processor.


registrazioneUDDI


WSDL WSDL

SOAP


SOAP - introduzione

La reccomendation del W3C definisce: Come deve essere strutturato il messaggio SOAP Cosa rappresentano i dati contenuti nel messaggio Le regole di Binding verso un protocollo di trasporto ( ad esempio

HTTP) Come eseguire attraverso SOAP una chiamata a procedura remota

(RPC)

I messaggio SOAP utilizzano una sintassi XML, quindi: I SOAP Processor deve qualificare elementi e attributi utilizzando i

namespace nei messaggi generati I messaggi SOAP non contengono DTD, né Processing Instruction


SOAP per scambiare messaggi

Lo scambio di messaggi tramite SOAP è fondamentalmente una trasmissione da un mittente ad un destinatario attraverso zero o più intermediari, anche se, a seconda della natura dell’operazione che si vuole effettuare, spesso è necessaria anche una risposta da parte del destinatario.

Un intermediario SOAP è un’applicazione capace sia di ricevere che di inoltrare messaggi SOAP


SOAP e protocolli di trasporto

SOAP abilita una connessione application-to-application e può potenzialmente essere utilizzato con una vasta gamma di protocolli di trasporto; per ovviare a problemi con firewall o proxy tra due applicazioni, si è comunque soliti utilizzare SOAP mediante HTTP.

Questo significa che un messaggio SOAP viene spedito come parte di una richiesta (o risposta) HTTP. Un’altra ragione che porta a questa scelta nell’utilizzo di SOAP è che praticamente ogni computer connesso ad una rete supporta traffico HTTP. Utilizzando quindi HTTP e XML, SOAP cerca di garantire una comunicazione semplice e leggera, in termini computazionali, tra due applicazioni eseguite indipendentemente dalla piattaforma e connesse mediante una infrastruttura già esistente.


SOAP – elaborazione dei messaggi

Un’applicazione SOAP che riceve un messaggio deve elaborare il messaggio compiendo in ordine le seguenti azioni: Identificare tutte le parti del messaggio; Verificare che tutte le parti identificate nel passo precedente siano

supportate dall’applicazione alla quale è rivolto il messaggio ed elaborarle. L’applicazione può ignorare le parti identificate come opzionali nel primo passo senza compromettere l’elaborazione del resto del messaggio;

Se l’applicazione SOAP alla quale è arrivato il messaggio non è la destinazione finale del messaggio stesso, elabora il messaggio aggiungendo od eliminando informazioni in modo da inoltrare soltanto i dati significativi per il destinatario successivo.


SOAP – elaborazione dei messaggi

CLIENT APPLICAZIONE

Spedizione messaggio

Identificazione e verifica delle parti del messaggio

Spedizione Risposta

Caso in cui l’applicazione soap è il destinatario finale

Inoltro del messaggio

Elaborazione del messaggio da inoltrare

DESTINAZIONE FINALE

Caso in cui l’applicazione non e’ il destinatario finale

Spedizione Risposta


SOAP – formato dei messaggi Per rendere più semplice e leggibile un messaggio SOAP si è

deciso di costruirlo in modo da somigliare, logicamente, ad una lettera. Si può quindi schematizzare un documento SOAP come una lettera composta da:

Una busta (Envelope); Informazioni varie per la spedizione del messaggio (Header); Un documento da spedire (Body).

Busta contenente le informazioni da spedire

Documento con le informazioni richieste

Informazioni sulla spedizione (a differenza di una vera lettera con SOAP queste informazioni sono opzionali)


SOAP – formato dei messaggi Più formalmente un messaggio SOAP è un documento XML consistente in:

Un elemento SOAP Envelope (obbligatorio) che rappresenta la radice del documento XML; tale elemento DEVE essere presente nel documento, PUO’ contenere un Header, DEVE contenere un BODY.

Un elemento SOAP Header (opzionale) contenente informazioni aggiuntive per la comprensione e la spedizione del messaggio; è il primo figlio dell’envelope; può avere elementi figli.

Un elemento SOAP Body (obbligatorio) contenente le informazioni che si intendono far giungere al destinatario. Al suo interno viene inoltre definito l’elemento Fault usato per la gestione degli errori; viene come primo figlio dopo Header

Busta contenente le informazioni da spedire

Documento con le informazioni richieste

Informazioni sulla spedizione (a differenza di una vera lettera con SOAP queste informazioni sono opzionali)


SOAP – formato dei messaggi

<?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/

soap-envelope" soap:encodingStyle="http://www.w3.org/

2001/12/soap-encoding"> <soap:Header>

... </soap:Header> <soap:Body> ... <soap:Fault>

... </soap:Fault> </soap:Body> </soap:Envelope>

SOAP Envelope

SOAP Header

Parti dell’Header

SOAP Body

Dati da spedire

SOAP Fault


SOAP – envelope

L’elemento envelope identifica l’inizio e la fine del messaggio, in maniera tale che il ricevente sappia quando l’intero messaggio è stato ricevuto. Si risolve in questo modo il problema di sapere quando la ricezione è completata e si può iniziare a processare il messaggio. Agisce come meccanismo di packaging.

V 1.2:

<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle=http://www.w3.org/2001/12/soap-encoding>

…

</soap:Envelope>


SOAP – header

Nel messaggio SOAP può nascere l’esigenza di inserire informazioni non facenti parte del messaggio ma fondamentali per la spedizione del messaggio stesso (legati ad esempi a aspetti di sicurezza, transazioni, ecc.). Esistono alcuni attributi standard che non necessitano di nessun previo accordo fra le parti.

SOAP consente inoltre l’estensione delle informazioni del messaggio: è possibile definire, oltre agli attributi standard, dei propri attributi.

Gli elementi figli dell’header sono definiti da un nome composto da URI di namespace e nome locale.


SOAP – header

Le informazioni contenute nell’header: possono essere utilizzate da intermediari SOAP identificati da URI in

un qualunque punto del cammino seguito dal messaggio. non devono essere indirizzate necessariamente al destinatario finale.

L’attributo role (il cui valore è un URI) viene utilizzato per indicare il destinatario dell’elemento dell’header con tale attributo (se l’elemento non è presente il destinatario è il destinatario finale del messaggio). SOAP fornisce tre predefiniti ruoli per un nodo :

next: identifica tutti i nodi intermediari e il destinatario finale. none: dichiara che il contenuto dell’elemento non deve essere

processato da nessun nodo. ultimateReceiver: identifica il destinatario finale (di default se non è

specificato nessun ruolo).

SOAP non specifica come un nodo può assumere un particolare ruolo.


SOAP – header

L’attributo mustUnderstand è usato per indicare se una voce dell’Header debba essere elaborata dal destinatario o meno. Il valore dell’attributo può essere “true” o “false”. L’assenza di questo attributo è semanticamente equivalente alla sua presenza con valore “false”.

Se un elemento dell’Header possiede quest’attributo con valore “true”, il destinatario deve elaborarlo correttamente oppure restituire un errore

<SOAP-ENV:Header>

<t:Transaction xmlns:t="http://example.org/2001/06/tx" SOAP-ENV:mustUnderstand="true">5 </t:Transaction>

</ SOAP-ENV :Header>


SOAP – body

Il Body di un messaggio SOAP può essere visto come il documento vero e proprio che si vuole spedire: questa parte contiene infatti i dati (che possono essere della più svariata natura) che si intendono mandare al destinatario.

L’elemento fault del body trasporta informazioni riguardanti gli errori occorsi durante la spedizione di un messaggio. Nel caso sia presente, fault deve apparire come una voce del Body e non può comparire più di una volta.

All'intero di Body ogni elemento deve essere definito da un namespace poiché SOAP prevede al suo interno solamente l’elemento fault.

Gli elementi che si trovano all'interno del Body, sono tipicamente quelli definiti dal WSDL del WS a cui è inviato il messaggio.


SOAP – body. Elemento fault

Sono definiti cinque sottoelementi per l’elemento Fault: env:Code: è un elemento obbligatorio e definisce un codice per

l’identificazione automatica dell’errore. Ha due elementi figli di cui uno env:Value obbligatorio, l’altro env:SubCode opzionale.

env:Reason: fornisce una descrizione, comprensibile da un utente, del tipo di errore. Anche questo elemento deve essere presente all’interno di Fault. Ha uno o più elementi figli chiamati Text ognuno dei quali deve contenere un valore diverso nell’attributo obbligatorio xml:Lang.

env:Node: fornisce informazioni sul nodo che ha causato l’errore che viene identificato attraverso un URI.

env:Detail: fornisce informazioni specifiche riguardanti gli errori. Può avere un numero qualsiasi di figli.

env:Role: è opzionale ed indica il ruolo che ricopriva il nodo che ha causato l’errore


SOAP – body. Elemento fault<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"

xmlns:m="http://www.example.org/timeouts" xmlns:xml="http://www.w3.org/XML/1998/namespace">

<env:Body> <env:Fault>

<env:Code> <env:Value>env:Sender</env:Value>

<env:Subcode><env:Value>m:MessageTimeout</env:Value>

</env:Subcode> </env:Code> <env:Reason>

<env:Text xml:lang="en">Sender Timeout</env:Text> </env:Reason>

<env:Detail><m:MaxTime>P5M</m:MaxTime></env:Detail> </env:Fault>

</env:Body></env:Envelope>


SOAP con HTTP

Benché SOAP possa essere usato mediante una grande varietà di protocolli, HTTP è quello più comunemente usato.

Le richieste HTTP consistono in un comando http, come POST o GET, seguito dall’URL richiesto e dalla versione del protocollo (es. HTTP 1.1). Le risposte seguono la semantica di HTTP per fornire il codice dello stato della risposta; per esempio, uno status code del tipo 2xx indica che la richiesta è stata ricevuta, capita, accettata, ecc.


SOAP con HTTP Esistono 2 modelli per lo scambio di messaggi SOAP via HTTP:

il modello “SOAP request-response” in cui il metodo POST viene utilizzato per portare i messaggi SOAP nel Body delle richieste/risposte http;

il modello “SOAP response” in cui nelle richieste http viene usato il metodo GET per ottenere il messaggio SOAP ed inserirlo nel Body della risposta.

Utilizzando SOAP con HTTP ci si deve ricordare di settare l’header Content-Type come application/SOAP+xml; il parametro charset è opzionale e può assumere i valori utf-8 o utf-16.


SOAP con HTTP-GET(SOAP response)richiesta HTTP GET:

GET /travel.example.org/reservations?code=F3T HTTP/1.1Host: travelcompany.example.orgAccept: text/html;q=0.5, application/soap+xml

risposta HTTP GET:HTTP/1.1 200 OKContent-Type: application/soap+xml; charset="utf-8“Content-Length: 200 <?xml version='1.0' ?><env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">

<env:Header>…</env:Header> <env:Body>…</env:Body>

</env:Envelope>


SOAP con HTTP-POST(SOAP request-response)

richiesta HTTP POST:

POST /reservations HTTP/1.1

Host: travelcompany.example.org

Content-Type: application/soap+xml; charset="utf-8“

Content-Length: 230

<?xml version='1.0' ?>

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" > <env:Header>... </env:Header>

<env:Body>…</env:Body>

</env:Envelope>

risposta HTTP POST uguale al caso della GET


WSDL…UTILIZZO Il Web Service Description Language (WSDL)

costituisce una base per i web service.

La figura presenta l’utilizzo dei WSDL. I passi di fornitura e consumo dei servizi implicano…

1. il service provider descrive il suo servizio usando WSDL. Questa definizione viene pubblicata nella directory dei servizi.

2. un service consumer emette una o più query alla directory per localizzare un servizio e stabilire come comunicare con quel servizio.

3. Una parte del WSDL fornito dal service provider è passata al service consumer. La directory raccoglie le richieste e le risposte del service provider e le fornisce al service consumer.

4. Il service consumer utilizza il WSDL per mandare una richiesta al service provider.

5. Il service provider fornisce la risposta attesa al service consumer.


WSDL I Web Services Description Language è il formato utilizzato per descrivere le

interfacce dei web service. Rappresentano un modo di descrivere servizi e come questi sono limitati a

specifici indirizzi di rete. WSDL ha tre parti fondamentali:1. Definizioni…

generalmente espressi in XML includono sia le definizioni dei data type, che quelle dei messaggi.

2. Operazioni… descrivono le azioni per i messaggi supportati dai web service. Ci sono quattro tipi di operazioni:

2.1) One-way -> i messaggi vengono inviati senza una risposta di ritorno. 2.2) Request/response -> il sender invia un messaggio e quando lo riceve invia un risposta. 2.3) Solicit response -> si richiede una risposta. 2.4) Notification -> i messaggi inviati a più receiver.

Le operazioni sono raggruppate in port type, ovvero un insieme di operazioni supportate dai web service.

3. Legami tra i servizi… consente la connessione tra port type e port.


WSDL è stato sviluppato originariamente da Microsoft e IBM e sottomesso all’approvazione del W3C da 25 compagnie. WSDL fa parte del cuore dell’architettura WS: fornisce

un meccanismo comune per rappresentare le operazioni supportare dai WS.

la definizione dei tipi di dato da utilizzare nei messaggi. il meccanismo il binding dei messaggi con i protocolli di trasporto da

adottare.

WSDL è progettato per poter essere utilizzato sia nella modalità procedure-oriented (RPC) che document-oriented.

WSDL

Data Type

Operation

Binding


WSDL - caratteristiche Ciascun dei tre componenti di WSDL può essere specificato in file

separati e combinato in vari modi per generare una descrizione finale di un WS.

La descrizione WSDL deve essere disponibile a entrambi gli attori (chi richiede il servizio e chi lo fornisce) di una transizione WS.

Il binding consente di associare a messaggi o operazioni uno o più meccanismi di trasporto.

WSDL è progettato come una piattaforma XML estensibile per gestire diversi tipi di dato, operazioni, protocolli di trasporto e definizione di messaggi.

WSDL “nasconde” dietro ad un formato comune la effettiva implementazione del servizio ( che può adottare, ASP, servlet per l’interfaccia per il Web, .NET, CORBA o altro per il sisteam di back.end)


WSDL - caratteristiche WSDL non è legato a nessun protocollo di trasporto particolare, ma può essere

utilizzato con protocolli differenti, fornendo un modo per specificare di volta in volta il protocollo utilizzato.

Con una descrizione WSDL un client può ottenere dinamicamente l’informazione sul protocollo utilizzato e adottarlo a runtime, rendendo più semplice adattamenti a protocolli diversi.

Detto questo, WSDL privilegia SOAP, indicando, in una delle sue specifiche (estensioni) le modalità di collegamento a questo standard.

L’utilizzo di WSDL con altri protocolli richiede la definizione di un’estensione WSDL specifica adatta e la conseguente costruzione di documenti WSDL conformi a tali specifiche. Questo procedimento, possibile grazie alla grande estensibilità di WSDL, può risultare però molto complesso.


WSDL – uso di tipi e messaggi

La definizione dei tipi in WSDL è basata su XML Schema. Tali parte di WSDL è completamente estensibile, e possono essere anche utilizzati altri meccanismi per la definizione di tipo.

I tipi possono essere definiti dentro un elemento WSDL o in altri file e poi referenziati. I tipi di dati possono essere quelli definiti da XMLSchema (integer, string…), o altri tipi complessi.

In genere nella implementazione dei WS si richiede un passaggio di trasformazione dei dati dal formato XML di scambio verso il formato gestito dall’applicazione di back-end che deve trattare i dati. Si richiede che la definizione WSDL sia sufficientemente espressiva per supportare la traduzione verso i dati dell’applicazione.

I singoli tipi di dati possono essere usati da più messaggi, e i messaggi possono essere usati da varie operazioni


WSDL – elemento radice

WSDL fornisce definizioni di servizi: l’elemento radice del documento è <definitions>.

ha un attributo name che contiene il nome del documento, come forma soprattutto di documentazione.

definisce i namespace utilizzati per consentire di fare riferimento alle estensioni di WSDL o ad altre specifiche.

può avere come figli 5 elementi: types;

message;

portType (definizioni astratte);

bindings;

service(definizioni concrete);


Elementi principali di WSDL Un documento WSDL utilizza i seguenti elementi per descrivere un servizio ( solo 5 figli

di definitions): types: rappresenta la sezione dove definire i tipi di dati attraverso un linguaggio

come XMLSchema. WSDL non si occupa di definire i tipi. message: contiene la dichiarazione dei messaggi (e i relativi tipi) che possono

essere utilizzati nelle operazioni. operation: rappresenta la descrizione astratta di un’azione supportata dal WS. portType: rappresenta un insieme di operazioni supportate dal WS. binding: definisce un protocollo da utilizzare per un particolare port type. port: definisce un singolo endpoint attraverso l’associazione di un binding e di un

indirizzo di rete. service: un insieme di endpoint correlati.


Documentazione in WSDL

WSDL utilizza l’elemento opzionale document per inserire una documentazione human-readable del documento.

Il contenuto di tale elemento può essere testo ed elementi arbitrari insieme.

L’elemento document può essere inserito in qualunque altro elemento WSDL.


L’elemento types

L’elemento types contiene dal definizione di tipi di dati rilevanti per i messaggi che devono essere scambiati. WSDL “preferisce” XSD(XML Schema Definition) come meccanismo di definizione dei tipi.

<types>

<xsd:schema .... />

<xsd:schema .... />

….

</types>


L’elemento message

Ogni messaggio è identificato da un nome unico tra tutti i messaggi del documento WSDL, specificato con l’attributo name.

L’elemento message consiste di una o più parti logiche. Ad ogni parte è associato un tipo definito secondo un sistema di tipi (ad esempio può essere stato definito nella sezione types). Per gestire questa associazione WSDL definisce due attributi:

element: fa riferimento a un elemento XSD usando un Qname. type: fa riferimento a un tipo XSD semplice o complesso usando un Qname Ogni parte è a sua volta identificata da un nome unico all’interno del messaggio

di cui fa parte. I messaggi possono essere definiti con più parti per distinguere unità logiche

distinte. In alternativa, si può ricorrere alla definizione di tipi complessi che racchiudano tutte le parti.


L’elemento messageEsempio di messaggio con più parti:

<types>…<element name="PO" type="tns:POType"/>

<element name="Invoice" type="tns:InvoiceType"/> … </types>

<message name="PO">

<part name="po" element="PO"/>

<part name="invoice" element="Invoice"/>

</message>

Esempio di messaggio con una parte sola:

<types>…<complexType name="Composite"> … </types>

<message name="PO">

<part name="composite" type="Composite"/> </message>


L’elemento portType

L’elemento portType rappresenta un insieme di operazione supportate dal servizio. Ad esempio

<wsdl:portType name=“myPortType">

<wsdl:operation name=“op1" .... />

<wsdl:operation name=“op2" .... />

….

</wsdl:portType>

L’attributo name identifica univocamente nel documento la portType definita.

A loro volta le operazione sono identificate univocamente nel documento dall’attributo name.

Possiamo pensare al portType come a una libreria di funzioni (specifica il tipo degli argomenti passati e dei dati che ritornano)


WSDL – operazioni

Definiti i formati di scambio, si passa a definire le operazioni che il WS implementa.

WSDL consente di definire 4 tipi di operazioni:

One-Way: il messaggio viene spedito senza obbligo di risposta

Request/Response: meccanismo simile alle RPC. Il mittente spedisce un messaggio e il destinatario invia in seguito un messaggio di risposta

Solicit response: viene inviato un messaggio di risposta senza dati di input. E’ la richiesta di avere un messaggio e non comporta l’invio di un messaggio.

Notification: questo tipo di operazione definisce molti destinatari per un messaggio (similmente al broadcast)


WSDL – operazioni

Il tipo di interazione request/response e solicit/response benchè siano modellabili utilizzando 2 volte il meccanismo one-way sono state definite per fornire dei meccanismi di scambio di messaggi molto comuni senza tuttavia dover ricorrere a linguaggi di definizione di workflow.

Per definire modelli di scambio di messaggi più complessi di quelli definiti precedentemente, WSDL non è più sufficiente e si deve ricorrere alla composizione di tali elementari operazioni utilizzando linguaggi per la definizione di workflow.

Il tipo di interazione adottata è implicitamente definita dalla presenza o meno dei parametri di input e output (e quindi dei relativi elementi).


WSDL – operazioni

La definizione delle operazioni deve specificare i messaggi che devono essere scambiati. Gli elementi input e output specificano i messaggi da utilizzare nelle fasi di request/response, rispettivamente. Per fare questo è definito un attributo message negli elementi input e output il cui valore fa riferimento a un messaggio precedentemente definito.

Esempio di operazione request/response:

<wsdl:portType .... >

<wsdl:operation name=“PO">

<wsdl:input name=“a" message=“PORequest"/>

<wsdl:output name=“" message=“POResponse"/>

<wsdl:fault name=“c" message=“POError"/>

</wsdl:operation>

</wsdl:portType >


WSDL – operazioni L’elemento fault specifica il messaggio da inviare in output come risultato in

caso di errore. L’attributo name degli elementi input, output e fault sono identificatori

univoci opzionali per tali elementi.

Tale definizione delle operazioni richiede ancora la specifica di un binding particolare per determinare come i messaggi devono realmente essere inviati: se utilizzando una singola connessione ( ad esempio una sessione HTTP request/response) oppure attraverso due distinte connessioni ( es. due session HTTP request).

Nella definizione di un’operazione, nel caso questa debba essere intesa come una RPC, si può specificare ( nel caso request-response o solicit-response) la lista dei parametri con l’attributo parameterOrder il cui valore è composto da un lista di nomi di parti di messaggio separate da spazi singoli. Questo parametro (opzionale) agisce come suggerimento nel caso di chiamate RPC.


WSDL – binding

Il binding fornisce i dettagli sul protocollo da usare per le operazioni e messaggi definiti da una particolare portType.

Il contenuto di questa sezione del documento WSDL dipende dal protocollo utilizzato e quindi dalle estensioni WSDL adottate.

Come al solito, l’attributo name identifica con un nome univoco tutti i binding che vengono definiti in un documento WSDL.

L’attributo type fa riferimento all’ elemento portType a cui il binding si riferisce. Possono essere specificate informazioni di binding sia su determinate operazioni che

su determinate portType. Nei bindings possono essere usati vari meccanismi di trasporto: HTTP GET, HTTP

POST, SOAP. Il binding per una operazione fa comunque sempre riferimento all’operazione

descritta dalla portType specificata nell’attributo type. In caso ci siano operazioni con lo stesso nome, quella corretta deve essere

identificata fornendo il nome degli attributi di input e output.


WSDL – service e portL’elemento service racchiude un insieme di porte per il servizio.

L’elemento port associa un indirizzo (endpoint) a un ben definito binding da utilizzare nella comunicazione. Cambia anch’esso in base all’estensione adottata.

<wsdl:service .... > *

<wsdl:port name="nmtoken" binding="qname"> *

<-- extensibility element (1) -->

</wsdl:port>

</wsdl:service>

name identifica in maniera univoca la porta nel documento WSDL.

binding fa riferimento a un elemento binding definito nel documento.

L’elemento di estensione serve per identificare l’indirizzo per la porta.


WSDL – port e service

Le porte definite per un servizio sono correlate fra di loro in questo modo: Nessuna delle porte comunica con le altre (i parametri di output di una non

possono essere usati come parametri di input di un’altra) Se un servizio ha varie porte, le quali tutte condividono una determinata

portType, specificando però diversi meccanismi di binding e indirizzi, le porte sono da considerarsi alternative fra di loro: ognuna di esse fornisce infatti servizi semanticamente equivalenti. Un client può scegliere quale porta utilizzare nella sua richiesta al servizio.

Dalla porta si può risalire alla relativa portType utilizzata. In questo modo il client di un servizio, dipendentemente dal fatto che possa utilizzare (tutti) i tipi di porta disponibili, può sapere se tale servizio è per lui realmente disponibile o no. Ciò specialmente nel caso di servizi che sfruttano varie porte.


WSDL – binding con SOAP WSDL fornisce delle estensioni che permettono di specificare il binding di un servizio

con i protocolli: una di queste estensioni descrive il binding con SOAP. Tale estensione definisce i seguenti elementi:

bindings: specifica che viene utilizzato il formato del protocollo SOAP: Envelope, Header e Body. L’attributo transport specifica il protocollo di trasporto, l’attributo style può assumere i valori rpc e document per identificare il paradigma di comunicazione

operation: fornisce informazioni su una determinata operazione: body: specifica come le parti del messaggio devono apparire nel corpo del

messaggio SOAP fault: specifica il contenuto dell’elemento fault del messaggio SOAP header: specifica il contenuto di un elemento header di un messaggio SOAP address: specifica la porta (URI) da utilizzare per la connessione


Riferimenti

SOAP: http://www.w3.org/2000/xp/Group/ WSDL: http://www.w3.org/TR/wsdl WEBService: http://www.w3.org/2002/ws/


UDDI

Un UDDI registry è utilizzato con il significato di scoperta dei web service descritti usando WSDL.

L’idea è che l’UDDI registry può essere cercato in vari modi per ottenere il contatto dell’informazione e la disponibilità dei web service per varie organizzazioni.

L’UDDI potrebbe essere un modo di tenere aggiornato il web service che l’organizzazione ha appena utilizzato.


UDDI


UDDI

UDDI=Universal Description, Discovery, and Integration

The definition of a set of services supporting the description and discovery of

businesses, Organizations and other Web services providers the Web services they make available the technical interfaces which may be used to access those services

To be interrogated via SOAP

Defined by OASIS, version 3 (2005)

http://www.uddi.org/


UDDI Accepts and organizes three types of information into three

broad categories:

White Pages — address, contact, and known identifiers

Yellow Pages — industrial categorizations based on standard taxonomies

Green Pages — technical information about services exposed by the business. including references and interfaces to the services a company can deliver.


UDDI

Often people identifies Web Services core technologies as WSDL + SOAP + UDDI

The real core is WSDL + SOAP

The Grid community did not adopt UDDI it relies on the Information Service

(to be explaine in a future lesson)


Web Services Interoperability


Web Services and Interoperability

WSDL + SOAP should provide the minimum abstraction layer to implement the SOA paradigm on top of WWW

Unfortunately, standards are complex and not always rigorous

The way you use them can lead to not interoperable Web Services


WS-I

WS-I = Web Services – Interoperability http://www.ws-i.org

an open industry organization

chartered to promote Web services interoperability across platforms, operating systems and programming languages


WS-I

It provides:

profiles

sample applications

testing tools


WS-I Profiles

A profile defines implementation guidelines for

how related Web services specifications should

be used together for best interoperability


WS-I Profiles To date, WS-I has finalized

Basic Profile Attachments Profile Simple SOAP Binding Profile Basic Security Profile Security Profile


WS-I example

6.2.1 Exactly One Created per Timestamp

The wsu:Created element represents the creation time of the security semantics.

R3203 A TIMESTAMP MUST contain exactly one CREATED.

This element is REQUIRED and can only be specified once in a Timestamp element. Within the SOAP processing model, creation is the instant that the Infoset is serialized for transmission.

6.2.2 Not More Than One Expires per Timestamp

R3224 Any TIMESTAMP MUST NOT contain more than one EXPIRES.

6.2.3 Created Precedes Expires in Timestamp

A timestamp may optionally contain an expires element.

R3221 Any TIMESTAMP containing an EXPIRES MUST contain a CREATED that precedes its sibling EXPIRES.

Preventing multiple expires elements and enforcing the order of elements reduces complexity.

http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html#Timestamps


INCORRECT:

<wsu:Timestamp wsu:Id="timestamp">

<wsu:Expires>2001-10-13T09:00:00Z</wsu:Expires>

</wsu:Timestamp>

CORRECT: <wsu:Timestamp wsu:Id="timestamp">

<wsu:Created>2001-09-13T08:42:00Z</wsu:Created> <wsu:Expires>2001-10-13T09:00:00Z</wsu:Expires>

</wsu:Timestamp>

WS-I example …


Web services in HEP

Distributed analysis (reconstruction) E.g. Clarens http://clarens.sourceforge.net/

CMS distributed data server for remote analysis Python with XML-RPC (and SOAP) Interfacing to Grid services

Similar activities at SLAC Using Java and Agents

Just starting … Web services is the “standard” technology retained for

all grid development


Conclusion

We have analized the reference model of the Service Oriented Architecture

We have seen a SOA instantiation built on top of WWW (the Web Services Architecture) Overview of the basic specifications:

WSDL and SOAP UDDI

The need for WS-I


References

Web Services Architecture (http://www.w3.org/TR/ws-arch/) Cap 1 (tutto) Cap 3.1.1., 3.1.2; Cap 3.2 (tutto) Cap 3.4

SOAP (http://www.w3.org/TR/soap/) SOAP Message Structure

Web Services Description Language (WSDL) 1.1 (http://www.w3.org/TR/wsdl) Cap 1 WSDL Document Structure WSDL Message Exchange Patterns

WS-I (http://www.ws-i.org/)


WSDL

Il Web Service Description Language (WSDL) è un formato XML che definisce il meccanismo, indipendente dalla piattaforma implementativa, per descrivere le interfacce dei Web Service. Un documento WSDL contiene sostanzialmente delle definizioni.

WSDL si propone per vari utilizzi base:

1. un documento WSDL fornisce ad un programmatore un descrizione di come può essere instaurata una comunicazione con un determinato servizio.

2. un sistema automatico potrebbe utilizzare questa descrizione per invocare dinamicamente un servizio Web.

3. generare automaticamente, a partire da una descrizione WSDL, il servizio stesso o il client per inoltrare delle richieste al servizio descritto.

Tecnologia dei Servizi Grid e cloud computing - Lezione 004b 0 Lezione 4b - 5 novembre 2009 Il...

Documents

Transcript of Tecnologia dei Servizi Grid e cloud computing - Lezione 004b 0 Lezione 4b - 5 novembre 2009 Il...