SOA…overview La parola d’ordine delle situazioni di sviluppo applicativo odierne è integrazione. Le applicazioni sviluppate si trovano a condividere flussi.

Presentazione sul tema: "SOA…overview La parola d’ordine delle situazioni di sviluppo applicativo odierne è integrazione. Le applicazioni sviluppate si trovano a condividere flussi."— Transcript della presentazione:

0 “Tecnologia dei Servizi “Grid e cloud computing”
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 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 Veronesi

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

2 GLI OBIETTIVI L’introduzione dei servizi nelle architetture odierne
Quali sono i principi che regolano SOA Cosa rappresentano i Web Service per SOA

3 L’introduzione dei servizi nelle architetture odierne
GLI OBIETTIVI L’introduzione dei servizi nelle architetture odierne Quali sono i principi che regolano SOA Cosa rappresentano i Web Service per SOA

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

5 …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.

6 Quali sono i principi che regolano SOA
GLI OBIETTIVI L’introduzione dei servizi nelle architetture odierne Quali sono i principi che regolano SOA Cosa rappresentano i Web Service per SOA

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

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

9 …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.

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

11 …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.

12 …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.

13 Cosa rappresentano i Web Service per SOA
GLI OBIETTIVI L’introduzione dei servizi nelle architetture odierne Quali sono i principi che regolano SOA Cosa rappresentano i Web Service per SOA

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

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

16 …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)

17 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).

18 Introduzione ai Web Service
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;

19 Introduzione ai 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. Trasformazione della richiesta secondo applicazione back-end Esecuzione servizio Messaggio XML di richiesta servizio Interfaccia WS Servizio back-end Messaggio XML di risposta al servizio Trasformazione del risultato secondo il formato del messaggio

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

21 Vantaggi dei Web Service
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

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

23 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 registrazione UDDI Consumatore Fornitore WSDL SOAP

24 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. Servizio di registrazione UDDI Consumatore Fornitore WSDL SOAP

25 Servizio di registrazione
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. Servizio di registrazione UDDI Consumatore Fornitore WSDL SOAP

26 Servizio di registrazione
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. Internet Information Services= IIS Servizio di registrazione UDDI Consumatore Fornitore WSDL SOAP

27 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

28 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

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

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

31 SOAP – elaborazione dei messaggi
DESTINAZIONE FINALE CLIENT APPLICAZIONE Spedizione messaggio Identificazione e verifica delle parti del messaggio Elaborazione del messaggio da inoltrare Spedizione Risposta Caso in cui l’applicazione soap è il destinatario finale Inoltro del messaggio Caso in cui l’applicazione non e’ il destinatario finale Spedizione Risposta

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

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

34 SOAP – formato dei messaggi
SOAP Envelope <?xml version="1.0"?> <soap:Envelope xmlns:soap=" soap:encodingStyle=" <soap:Header> ... </soap:Header> <soap:Body> <soap:Fault> </soap:Fault> </soap:Body> </soap:Envelope> SOAP Header Parti dell’Header SOAP Body Dati da spedire SOAP Fault

35 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=" soap:encodingStyle= … </soap:Envelope>

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

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

38 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=" SOAP-ENV:mustUnderstand="true">5 </t:Transaction> </ SOAP-ENV :Header>

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

40 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

41 SOAP – body. Elemento fault
<env:Envelope xmlns:env=" xmlns:m=" xmlns:xml=" <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>

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

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

44 SOAP con HTTP-GET(SOAP response)
richiesta HTTP GET: GET /travel.example.org/reservations?code=F3T HTTP/1.1 Host: travelcompany.example.org Accept: text/html;q=0.5, application/soap+xml risposta HTTP GET: HTTP/ OK Content-Type: application/soap+xml; charset="utf-8“ Content-Length: 200  <?xml version='1.0' ?> <env:Envelope xmlns:env=" <env:Header>…</env:Header> <env:Body>…</env:Body> </env:Envelope>

45 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=" > <env:Header>... </env:Header> <env:Body>…</env:Body> </env:Envelope> risposta HTTP POST uguale al caso della GET

46 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… il service provider descrive il suo servizio usando WSDL. Questa definizione viene pubblicata nella directory dei servizi. un service consumer emette una o più query alla directory per localizzare un servizio e stabilire come comunicare con quel servizio. 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. Il service consumer utilizza il WSDL per mandare una richiesta al service provider. Il service provider fornisce la risposta attesa al service consumer.

47 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: Definizioni… generalmente espressi in XML includono sia le definizioni dei data type, che quelle dei messaggi. 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. Legami tra i servizi… consente la connessione tra port type e port.

48 WSDL 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. Data Type Operation Binding

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

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

51 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

52 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);

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

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

55 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 .... /> …. </types>

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

57 L’elemento message Esempio 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> <part name="composite" type="Composite"/> </message>

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

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

60 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).

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

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

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

64 WSDL – service e port L’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.

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

66 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

67 Riferimenti SOAP: http://www.w3.org/2000/xp/Group/
WSDL: WEBService:

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

69 UDDI

70 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) L'UDDI (acronimo di Universal Description Discovery and Integration) è un registry (ovvero una base dati ordinata ed indicizzata), basato su XML ed indipendente dalla piattaforma hardware, che permette alle aziende la pubblicazione dei propri dati e dei servizi offerti su internet. UDDI, un'iniziativa "open" sviluppata tra il 1999 ed il 2000 e sponsorizzata dall'Organization for the Advancement of Structured Information Standards (consorzio internazionale per lo sviluppo e l'adozione di standard nel campo dell'e-business e dei Web Services spesso indicato anche come OASIS), permette la scoperta e l'interrogazione dei servizi offerti sul web, delle aziende che li offrono e della maniera per usufruirne. La versione 2.04 dello standard è stata pubblicata nel luglio 2002[1], la versione nell'ottobre 2004[2] 70

71 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. Una "registrazione" UDDI consiste di tre diverse componenti: Pagine bianche (White Pages): indirizzo, contatti (dell'azienda che offre uno o più servizi) e identificativi; Pagine gialle (Yellow Pages): categorizzazione dei servizi basata su tassonomie standardizzate; Pagine verdi (Green Pages): informazioni (tecniche) dei servizi fornite dall'azienda L'UDDI è uno degli standard alla base del funzionamento dei Web Service: è stato progettato per essere interrogato da messaggi in SOAP e per fornire il collegamento ai documenti WSDL che descrivono i vincoli protocollari ed i formati dei messaggi necessari per l'interazione con i Web Service elencati nella propria directory. 71

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

73 Web Services Interoperability

74 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

75 WS-I WS-I = Web Services – Interoperability
an open industry organization chartered to promote Web services interoperability across platforms, operating systems and programming languages WS-I (Web Services Integration Organization): è un'organizzazione formata da diversi produttori (Microsoft, IBM, Sun Microsystem, Oracle, HP, BEA ed altri) che si sono uniti per assicurare l'interoperabilità dei servizi Web tra tutte le piattaforme. Per fare ciò, hanno creato una raccomandazione denominata Basic Profile 1.0, che definisce un insieme di regole per l'utilizzo congiunto di XML, SOAP, e WSDL al fine di creare servizi Web interoperabili. 75

76 WS-I It provides: profiles sample applications testing tools 76

77 WS-I Profiles A profile defines implementation guidelines for how related Web services specifications should be used together for best interoperability Il WS-I basic profile è composto da specifiche che restringono le sovrabbondanti capacità espressive di SOAP, individuando un set minimo di caratteristiche comunemente supportate dai provider di web services. 77

78 WS-I Profiles To date, WS-I has finalized Basic Profile
Attachments Profile Simple SOAP Binding Profile Basic Security Profile Security Profile

79 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 Not More Than One Expires per Timestamp R3224 Any TIMESTAMP MUST NOT contain more than one EXPIRES 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.

80 WS-I example … INCORRECT: <wsu:Timestamp wsu:Id="timestamp"> <wsu:Expires> T09:00:00Z</wsu:Expires> </wsu:Timestamp> CORRECT: <wsu:Timestamp wsu:Id="timestamp"> <wsu:Created> T08:42:00Z</wsu:Created> <wsu:Expires> T09:00:00Z</wsu:Expires> </wsu:Timestamp>

81 Web services in HEP Distributed analysis (reconstruction)
E.g. Clarens 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

82 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

83 References Web Services Architecture ( Cap 1 (tutto) Cap , 3.1.2; Cap 3.2 (tutto) Cap 3.4 SOAP ( SOAP Message Structure Web Services Description Language (WSDL) 1.1 ( Cap 1 WSDL Document Structure WSDL Message Exchange Patterns WS-I (

84 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: un documento WSDL fornisce ad un programmatore un descrizione di come può essere instaurata una comunicazione con un determinato servizio. un sistema automatico potrebbe utilizzare questa descrizione per invocare dinamicamente un servizio Web. generare automaticamente, a partire da una descrizione WSDL, il servizio stesso o il client per inoltrare delle richieste al servizio descritto.