Architetture orientate ai servizi

Транскрипт

1 Architetture orientate ai servizi 1

2 Web Service Nuovo paradigma di sistema informativo basato su componenti software distribuiti I Web Service sono applicazioni indipendenti, modulari, autodescrittive, basate su tecnologie e standard aperti legati a Internet Possono essere pubblicati, ricercati e utilizzati da attori qualsiasi attraverso la rete Possono essere aggregati per create nuove applicazioni, servizi e processi Possono descrivere se stessi, cercare e interagire dinamicamente con altri Web service Anche applicazioni legacy possono essere pubblicate come Web service 2

3 SOA: Service Oriented Architecture 3

4 Elementi di una SOA I componenti chiave di una SOA sono: gli agenti che forniscono i servizi (service provider), quelli che li usano (service requester) e quelli adibiti alla loro registrazione e pubblicazione (service registry) i descrittori dei servizi, utilizzati per descriverne pubblicamente l interfaccia a scopi di discovery (è previsto uno standard di definizione delle interfacce dei servizi denominato WSDL Web Service Description Language) i messaggi e i meccanismi di comunicazione che permettono lo scambio delle informazioni tra i servizi (è previsto uno standard di definizione dei messaggi denominato SOAP Simple Object Access Protocol) 4

5 Tecnologie e linguaggi di una SOA L architettura dei Web Service è definita su 6 livelli (layers) di tecnologie e standard su cui i servizi possono essere implementati XML-based languages BPEL4WS WSCI BPML WSFL XLANG ebbpss UDDI ebxml WSDL XMLP SOAP HTTPR HTTP IBM, Microsoft Sun BPMI.org IBM Microsoft ebxml.org UDDI.org ebxml.org W3C W3C W3C IBM W3C Service Integration SLA (Service Level Agreement) Service Publication & Discovery Service Description XML-based Messaging Transport 5

6 Scenario applicativo Ski portal memorizza informazioni turistiche su hotel, permettendo inoltre la prenotazione di camere e il pagamento on-line La prenotazione è effettuata tramite i servizi messi a disposizione da ciascun hotel (HMS Hotel Management System) Il pagamento on-line è effettuato appoggiandosi su altri servizi messi a disposizione da un terzo sistema (PS - Payment System) L HMS fornisce anche servizi ausiliari utilizzabili dallo Ski portal (per esempio, news sugli hotel, notifiche di eventi, gestione dei commenti da parte degli utenti) Ski portal Hotel management system (HMS) HTTP Web appl. HTTP Resorts Ski slopes Hotels Clients Reservations Web service operations Payment system (PS) 6

7 Tipi di interazione L elemento fondamentale di un Web service è l operazione, che prevede lo scambio di 1 o 2 messaggi Request-Response Solicit-Response Notification One-Way Ski portal Web application One-way subscription to hotel news HMS Hotel news notification Get room offers request Room offer response Concert tickets solicit Concert tickets response 7

8 Synchronous vs Asynchronous Le operazioni che prevedono lo scambio di due messaggi possono essere usate in maniera sincrona: non viene effettuata nessuna operazione dopo che il primo messaggio è stato completato e prima che il secondo messaggio venga spedito, il sender aspetta in maniera asincrona: tra il primo e il secondo messaggio vengono compiute anche altre azioni, il sender non aspetta Ski portal HMS Get room offer request Make comment request Room offer response Comment response Solicit number of users connected Number of users. response Concert tickets solicit Concert tickets response 8

9 Due pilastri fondamentali I Web Service interagiscono scambiandosi i dati in un formato basato su XML,in accordo anche in questo caso con uno standard ben definito il Simple Object Access Protocol (SOAP) è lo standard utilizzato per descrivere il formato dei messaggi scambiati tra i servizi I Web Service presentano un interfaccia descritta in maniera standardizzata, a prescindere dai dettagli implementativi che ci stanno dietro il Web Service Description Language (WSDL) è lo standard utilizzato per descrivere l interfaccia dei servizi 9

10 SOAP: Simple Object Access Protocol 10

11 Remote Procedure Call (RPC) Una parte molto complessa dell elaborazione distribuita consiste nella gestione delle chiamate remote Si tratta di invocare del codice residente su un altro server, passandogli eventualmente dei parametri, e riceverne una risposta, anch essa espressa in un opportuna codifica Attualmente esistono molti standard per la codifica e la trasmissione delle chiamate e delle risposte CORBA, noto framework per la gestione di oggetti distribuiti, utilizza l Internet Inter-ORB Protocol (IIOP) DCOM di Microsoft, utilizza l Object Remote Procedure Call (ORPC).NET Remoting, per la piattaforma.net, utilizza diversi protocolli (tra cui SOAP) Java, per la Java Remote Method Invocation (RMI), utilizza il Java Remote Method Protocol (JRMP) SOAP, che si propone come sostituto di tutti questi protocolli 11

12 SOAP: Simple Object Access Protocol Protocollo leggero di scambio di informazioni strutturate e tipate tra attori (applicazioni) qualsiasi Definisce un formato generico di messaggio XML per lo scambio attraverso la rete Internet E un protocollo di comunicazione stateless e one-way, indipendente dalla piattaforma; pattern di interazione più complessi (es. richiesta/risposta, ) devono essere definiti a livello applicativo Descrive le azioni che gli attori della conversazione (i SOAP processors) devono svolgere al momento della ricezione dei messaggi Non descrive la semantica dei dati trasportati l implementazione della comunicazione la qualità del trasporto (affidabilità, routing) 12

13 SOAP: Simple Object Access Protocol SOAP gestisce informazione strutturata e tipata la strutturazione dei messaggi SOAP, che deriva direttamente dalla struttura implicita di XML, è molto adatta al trasporto dei dati la gestione dei tipi utilizza i tipi standard degli Schemi XML; in questo modo è possibile far viaggiare insieme ai dati anche dei metadati che ne descrivono la struttura SOAP non ha una semantica predefinita SOAP non definisce semantiche per i dati e le chiamate, ma fornisce agli sviluppatori i mezzi per farlo con un intenso uso dei namespace XML, SOAP permette agli autori dei messaggi di dichiararne la semantica usando grammatiche XML definite per lo scopo nei namespace 13

14 Struttura dei messaggi SOAP Envelope (obbligatorio): identifica il documento XML come un messaggio SOAP Header (opzionale): informazioni addizionali al messaggio, divise in entries, per i diversi attori coinvolti Body (obbligatorio): parte centrale del messaggio, contiene le informazioni di chiamata e risposta Fault (opzionale): contiene errori e informazioni di stato SOAP Envelope SOAP Header (opzionale) Header Entry 1 Header Entry N SOAP Body (obbligatorio) SOAP Fault 14

15 Struttura di un messaggio SOAP <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:header> </soap:header> <soap:body> <soap:fault> </soap:fault> </soap:body> Punta al sistema di serializzazione standard di SOAP per i tipi L elemento BODY contiene il messaggio vero e proprio; al suo interno non ci sono elementi definiti da SOAP, ma importati dal namespace del mittente del messaggio; lo stesso può dirsi dell elemento HEADER </soap:envelope> 15

16 SOAP processing model (I) Descrive le azioni che un SOAP processor deve svolgere alla ricezione di un messaggio SOAP Il SOAP processor deve saper riconoscere le parti di messaggio specifiche di SOAP (envelope, header, body, fault) Una header entry può contenere un attributo actor (un qualsiasi URI) che specifica il ruolo del destinatario di quel blocco Se non viene specificato, l actor predefinito è sempre il destinatario del messaggio 16

17 SOAP processing model (I) 17

18 SOAP processing model: esempio Supponiamo di voler certificare il contenuto dei nostri messaggi SOAP, avvalendoci dei servizi offerti da una terza società, che ci fornisce un token con il quale marcare il messaggio SOAP per riconoscerlo come valido La soluzione migliore (a meno di casi particolari) è sfruttare il supporto all estendibilità dei messaggi offerto da SOAP, attraverso le header entries... <soap:header> <notary:token xmlns:notary=" soap:actor=" </notary:token> </soap:header>... </soap:envelope> 18

19 Headers con attori L attore destinatario di una header entry deve sempre rimuoverla prima di inoltrare il messaggio all attore successivo lungo il path che conduce al destinatario Un attore può, se vuole, inserire altre header entries nel messaggio, senza però toccare il corpo del messaggio stesso 19

20 SOAP processing model (I) 20

21 SOAP processing model (II) Attori standard (URI next: ogni SOAP processor intermedio deve processare l elemento, perché esso deve essere esaminato dal successivo processor lungo il cammino di un messaggio none: nessun SOAP processor intermedio deve processare l elemento, a meno che venga richiesto da altri task ultimatereceiver: solo l ultimo SOAP processor che riceve il messaggio deve processare l elemento L elemento BODY è sempre indirizzato al processor con ruolo anonymous 21

22 SOAP processing model (III) È possibile specificare se il destinatario di una header entry debba elaborarla oppure possa ignorarla L attributo mustunderstand ( 1 0 ), inserito in una header entry, specifica quanto segue se posto a 1 indica che l attore deve elaborare la entry; se questo non è possibile, l attore deve generare un errore se posto a 0 indica che l elaborazione della entry è opzionale (valore di default) <soap:header> <notary:token xmlns:notary=" soap:actor= soap:mustunderstand="1">234 </notary:token > </soap:header>... </soap:envelope> 22

23 SOAP Body L elemento Body contiene il messaggio vero e proprio trasportato dal protocollo SOAP (è semanticamente equivalente ad una header entry con mustunderstand= 1 e actor non specificato) <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:body> <m:getprice xmlns:m=" <m:item>apples</m:item> </m:getprice> </soap:body> </soap:envelope> 23

24 Gestione errori: SOAP fault SOAP fornisce un modello per gestire situazioni di errore nel processing di un messaggio nel caso in cui il destinatario o un intermediario non sono stati in grado di elaborare la loro parte di messaggio L elemento Body ha un unico sotto-elemento predefinito (Fault) in cui specificare le informazioni sull errore verificatosi L elemento Fault contiene: faultcode (obbligatorio) per identificare l errore (VersionMismatch, MustUnderstand, Client, Server) faultstring (obbligatorio) per fornire una descrizione testuale dell errore faultactor (obbligatorio) per identificare il SOAP processor che ha generato l errore details (opzionale) per fornire informazioni applicative specifiche (tramite opportuno namespace), inserito solo se l errore è stato provocato dall elaborazione del Body (negli altri casi va inserita una nuova header entry) 24

25 SOAP encoding La codifica dei tipi è utilizzata per la serializzazione dei valori nei messaggi La codifica standard dei tipi di SOAP è indicata ponendo l attributo encodingstyle di un elemento al namespace Tuttavia, gli sviluppatori possono definire ed utilizzare anche altre codifiche dei tipi Descriveremo di seguito gli aspetti fondamentali della codifica SOAP per i tipi, che è usata anche in altri linguaggi come il WSDL 25

26 Codifica SOAP dei tipi semplici I tipi semplici sono tutti quelli definibili come simpletype negli Schemi XML (per esempio, string, decimal) In un messaggio SOAP, un valore di tipo semplice è serializzato all interno di un elemento detto accessor del valore Il tipo può venire specificato nel messaggio tramite l attributo type 26

27 Codifica SOAP dei tipi semplici I tipi semplici sono tutti quelli definibili come simpletype negli Schemi XML (per esempio, string, decimal)... In un messaggio SOAP, un valore di tipo semplice è serializzato all interno di un elemento detto accessor del valore <?xml version="1.0"?> <soap:envelope encodingstyle=" Il tipo xmlns:xsi=" può venire specificato nel messaggio tramite l attributo type o nel namespace che definisce xmlns:xsd=" la grammatica del messaggio <soap:body> <m:getstockpriceresponse xmlns:m=" <m:price xsi:type= xsd:decimal >34.5</m:Price> Accessor </m:getstockpriceresponse> </soap:body> </soap:envelope> 27

28 Codifica SOAP dei tipi semplici I tipi semplici sono tutti quelli definibili come simpletype negli Schemi XML (per esempio, string, decimal)... In un messaggio SOAP, un valore di tipo semplice è serializzato all interno di un elemento detto accessor del valore <?xml version="1.0"?> <soap:envelope encodingstyle=" Il tipo xmlns:xsi=" può venire specificato nel messaggio tramite l attributo type o nel namespace che definisce xmlns:xsd=" la grammatica del messaggio <soap:body> <m:getstockpriceresponse xmlns:m=" <m:category xsi:type= m:stockcategory >Energy</m:category> </m:getstockpriceresponse> </soap:body> </soap:envelope> 28

29 Codifica SOAP di strutture Una struttura dati in SOAP è codificata tramite un elemento (che è l accessor dell intera struttura) contenente altri elementi nidificati, che sono gli accessor dei singoli membri della struttura 29

30 Codifica SOAP di strutture <element Una struttura name= Book > dati in SOAP è codificata tramite un elemento (che è l accessor dell intera <complextype> struttura) contenente altri elementi nidificati, che sono gli accessor dei <element name= author type = xsd:string /> singoli membri della struttura <element name= preface type = xsd:string /> <element name= intro type = xsd:string /> </complextype> </element> <?xml version="1.0"?> <soap:envelope encodingstyle=" > <soap:body>... <e:book xmlns:e=" <e:author>henry Ford</e:author> <e:preface>prefactory text</e:preface> <e:intro>this is a book</e:intro> </e:book>... </soap:body> </soap:envelope> 30

31 Codifica SOAP di strutture <?xml version="1.0"?> <soap:envelope encodingstyle=" > <soap:body>... <e:book xmlns:e=" <e:title>my Life and Work</e:title> <e:author href= #Person-1 /> </e:book> <e:person id= Person-1 > <e:name>henry Ford</e:name> <e:address href= #Address-1 /> </e:person> </soap:body> </soap:envelope> 31

32 Codifica SOAP di array Il SOAP encoding fornisce un elemento Array per serializzare matrici e vettori Le istanze di un elemento Array devono contenere un attributo arraytype che specifica il tipo degli elementi dell array 32

33 Codifica SOAP di array Il SOAP encoding fornisce un elemento Array per serializzare matrici e vettori <?xml version="1.0"?> <soap:envelope encodingstyle=" Le istanze di un elemento Array devono contenere un attributo arraytype che > specifica il tipo degli elementi dell array <soap:body>... <p:person xmlns:p=" <p:name>devis Bianchini</p:name> <p:phonenumbers soap:arraytype= p:phonenumber[2] /> <p:phonenumber> </p:phoneNumber> <p:phonenumber> </p:phoneNumber> </p:phonenumbers> </p:person> </soap:body> </soap:envelope> 33

34 SOAP over HTTP Un messaggio SOAP, inviato utilizzando HTTP come protocollo di trasporto, fa sempre uso del metodo POST; il messaggio SOAP sta nel payload della richiesta/risposta HTTP Un messaggio HTTP POST che trasporta un payload SOAP deve necessariamente inserire nel suo header il campo SOAPAction Il contenuto del campo SOAPAction è un URI (anche vuoto) che dovrebbe fornire delle informazioni riguardanti il contenuto del messaggio SOAP allegato (lo vediamo più avanti) 34

35 Risposta ai messaggi HTTP SOAP Per inviare la risposta a un messaggio SOAP, il server deve attenersi allo standard HTTP Il contenuto della risposta sarà il messaggio SOAP di ritorno, eventualmente indicante un errore di elaborazione (tramite l elemento Fault) Se il messaggio SOAP ha generato un errore, il server dovrà restituire il messaggio SOAP riguardante l errore stesso unitamente al codice HTTP 500/Internal Server Error 35

36 RPC con SOAP (I) La codifica di una RPC con SOAP segue alcune regole convenzionali, riguardanti: l indicazione della risorsa (oggetto) alla quale è indirizzata la chiamata l indicazione del metodo da invocare l eventuale trasmissione della signature del metodo, per una sua più corretta identificazione la trasmissione dei parametri del metodo e del valore di ritorno dello stesso 36

37 RPC con SOAP (II) L indicazione della risorsa (oggetto) alla quale è indirizzata la chiamata avviene in maniera dipendente dal protocollo usato per trasportare il messaggio usando HTTP, sarà la URI richiesta al server a specificare l oggetto del quale si vuole invocare un determinato metodo convenzionalmente, l header field SOAPAction conterrà la URI completa dell oggetto seguita dal nome del metodo POST /InStock HTTP/1.1 SOAPAction= Indirizzo server Oggetto Metodo 37

38 RPC con SOAP (III) La chiamata al metodo viene codificata come una struttura XML nel Body del payload SOAP, in cui: l elemento radice della struttura ha lo stesso nome del metodo da chiamare i parametri sono codificati come elementi figli della radice, dichiarati con lo stesso nome e tipo del corrispondente parametro formale del metodo ed elencati nello stesso ordine con cui compaiono nella signature del metodo per l eventuale tipo ritornato dalla chiamata si crea un elemento a parte che figurerà solo nel messaggio di risposta 38

39 RPC con SOAP: esempio (I) public class stock { public double GetPrice(String Item) { double Price = ; return Price; } } <xsd:element name= GetPrice > <xsd:complextype> <xsd:sequence> <xsd:element name= Item type= xsd:string /> </xsd:sequence> </xsd:complextype> </xsd:element> Fase 1. Codifica XML della signature del metodo Nel riquadro in alto vediamo la classe stock e il metodo GetPrice che intendiamo invocare con SOAP/RPC Nel secondo riquadro usiamo la codifica standard di SOAP/RPC per descrivere lo schema degli elementi che incapsulano la chiamata al metodo; questo schema verrà associato al namespace 39

40 RPC con SOAP: esempio (II) Fase 2. Creazione del messaggio SOAP Il messaggio contenente la RPC viene creato seguendo le regole della codifica SOAP ed associato allo schema appena creato <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle= xmlns:xsi=" xmlns:xsd=" <soap:body> <m:getprice xmlns:m=" <m:item xsi:type= xsd:string >Apples</m:Item> </m:getprice> </soap:body> </soap:envelope> 40

41 RPC con SOAP: esempio (III) POST /InStock HTTP/1.1 Content-Type: text/xml; charset=utf-8 Content-Length: nnn SOAPAction= <?xml version="1.0"?> <soap:envelope </soap:envelope> Fase 3. Creazione della request HTTP Il nome dell oggetto da chiamare (stock) è specificato all interno dell URI richiesta, mentre l header SOAPAction riporta anche il nome del metodo da chiamare; il payload della richiesta POST contiene il messaggio preparato nella fase precedente 41

42 RPC con SOAP: risposta L esito della chiamata, se positivo, viene codificato come una struttura XML dove: l elemento radice ha convenzionalmente il nome del metodo seguito da Response il primo elemento della struttura rappresenta il valore di ritorno del metodo; il suo nome non ha importanza, ma ovviamente il tipo deve coincidere con quello ritornato dal metodo a seguire vengono inseriti, nell ordine con cui compaiono nella signature, i valori di tutti i parametri di tipo [out] e [in/out] del metodo 42

43 RPC con SOAP: esempio (IV) <xsd:element name= GetPriceResponse > <xsd:complextype> <xsd:sequence> <xsd:element name= Price type= xsd:decimal /> </xsd:sequence> </xsd:complextype> </xsd:element> HTTP/ OK Content-Type: text/xml; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <soap:envelope <soap:body xmlns:m=" <m:getpriceresponse> <m:price xsi:type= xsd:decimal >24.9</m:Price> </m:getpriceresponse> </soap:body> </soap:envelope> Fase 4. Ricezione della risposta via HTTP Nel riquadro in alto vediamo lo schema del messaggio SOAP di ritorno per il metodo GetPrice; il server invia il messaggio di risposta come fosse un normale contenuto HTTP, ad esempio una pagina HTML; l header contiene un codice che ci informa che l elaborazione della richiesta ha avuto successo 43

44 WSDL: Web Service Description Language 44

45 Il linguaggio WSDL WSDL è un linguaggio basato su XML per definire e descrivere Web service Un documento WSDL specifica la posizione (URL) del servizio e le operazioni che un servizio offre Più precisamente: una descrizione astratta di una classe di servizi un insieme di descrizioni di servizi concreti conformi alla descrizione astratta 45

46 Caratteristiche del linguaggio WSDL presenta le caratteristiche architetturali di molti altri linguaggi basati su XML: il linguaggio fa riferimento e si integra con standard esistenti, evitando di ridefinire ciò che esiste già: WSDL predilige l uso di XML Schema per il type system e di SOAP per la definizione dei messaggi il linguaggio è comunque estendibile, anche l uso di XML Schema e SOAP è consigliato, ma non è obbligatorio 46

47 Struttura di un documento WSDL <definitions> <types> definizioni dei types... </types> <message> definizione di un message... </message> <porttype> definizione di un port... (set di operations) </porttype> <binding> definizione di un binding... </binding> <service> collezione di port... </service> </definitions> 47

48 Descrivere un servizio Web WSDL separa gli aspetti astratti nella descrizione di un Web service da quelli concreti livello astratto: il servizio viene definito genericamente riferendosi alle operazioni offerte (interfacce) e al tipo di messaggi scambiati per ciascuna di esse livello concreto: le descrizioni astratte vengono istanziate legandole a una implementazione reale (procolli, indirizzi di rete, ecc.) Vantaggi lo stesso servizio può avere implementazioni diverse, basandosi sulla stessa descrizione astratta le descrizioni astratte possono essere riutilizzate, tutte o in parte, nella creazione di nuovi servizi 48

49 WSDL descrizione astratta Un insieme (opzionale) di TIPI (types): nuovi tipi XML schema che potranno essere usati nella specifica Un insieme di MESSAGGI (messages): descrizioni astratte (tipi e nomi) dei dati scambiati con il Web Service (eventualmente usando i tipi sopra definiti) Un insieme di OPERAZIONI (operations): descrizioni astratte delle azioni supportate da un Web Service Una o più porttype: collezioni di operazioni (interfacce) esposte dal Web service 49

50 WSDL descrizione concreta Un binding è la specifica di un particolare protocollo di comunicazione e di un formato dei dati per una certa porttype è possibile specificare diversi binding per un certo porttype (es., su HTTP, mail, SOAP, ecc.) noi descriveremo il binding SOAP su HTTP, che utilizza SOAP per codificare i messaggi e HTTP come trasporto Una port è descritta da: una porttype [interfaccia e specifica del servizio] un binding [come funziona il servizio] un indirizzo di rete (URL) [dove trovare il servizio] Un service è una collezione di port tra loro correlate 50

51 Messaggi Ciascun messaggio ha un nome univoco ed è costituito da una o più parti, ciascuna con un nome e un tipo distinti ad esempio, se un messaggio rappresenta la codifica di una RPC, le sue parti sono solitamente gli argomenti della chiamata o il valore di ritorno il type system preferito del WSDL è quello di XML Schema Per definire i tipi usati all interno del documento, WSDL usa l elemento <types>: types è il primo figlio di definitions all interno di types è possibile inserire un intero schema XML (incorporato nel tag <schema>) o qualsiasi altra definizione di tipo valida e definibile tramite la notazione XML è anche possibile far riferimento a schemi esterni al documento XML 51

52 Operazioni WSDL L operazione (operation) è l unità di interazione elementare con un Web service ed è eseguita attraverso lo scambio di messaggi Convenzionalmente: input messages: messaggi inviati dall utilizzatore al Web Service output messages: messaggi inviati dal Web Service L interazione con i Web Service può essere asincrona; scambi asincroni possono verificarsi all interno di una operazione a due messaggi, oppure tra due operazioni a messaggio singolo 52

53 Tipi di operazioni WSDL Un operazione può essere: one-way: il Web Service riceve un messaggio (input message) request-response: il Web Service riceve una richiesta (input message) e restituisce la risposta relativa (output message) solicit-response: il Web Service invia un messaggio (output message) e riceve una risposta (input message) notification: il Web Service invia un messaggio (output message) 53

54 Riassunto della definizione astratta 54

55 Esempio WSDL (parte astratta) <definitions name= PlaceFinder > <types> </types> <message name= findplace1soapin > <part name= arg0 type= xsd:string /> </message> <message name= findplace1soapout > <part name= Result type= LocationInfo /> </message> <porttype name= PlaceFinderSoap > <operation name= findplace > <input name= findplace1soapin message= findplace1soapin /> <output name= findplace1soapout message= findplace1soapout /> </operation> </porttype> </definitions> Request-response operation 55

56 SOAP binding Gli elementi del namespace SOAP contenuti nell elemento binding servono a descrivere come costruire un messaggio SOAP a partire dal messaggio definito in WSDL L elemento soap:binding specifica lo stile default di codifica da usare per tradurre le parti del messaggio WSDL in quelle di un messaggio SOAP (Header e Body) e il tipo di trasporto utilizzato da SOAP (per esempio, HTTP) 56

57 Stili di codifica Lo stile di codifica, specificato dall attributo style di soap:binding, può essere: rpc: il messaggio WSDL viene codificato come una RPC; all interno del Body del messaggio viene inserito un elemento con lo stesso nome dell operazione e tanti figli quante sono le part del messaggio associato document: il messaggio WSDL viene codificato usandone il contenuto letteralmente; in questo caso, ogni part del messaggio associato a un operazione figurerà come figlio distinto dell elemento Body nel messaggio SOAP 57

58 Stili di codifica: esempio <message name= twopartsopin > <part name= arg0 type= xsd:string /> <part name= arg1 type= xsd:double /> </message> <porttype name= twopartsport > <operation name= twopartsop > <input name= twopartsopin message= twopartsopin /> </operation> </porttype> <binding name= SoapGeneric type= twopartsport > <soap:binding style= transport= /> </binding> <soap:body> <twopartsop> <arg0/> <arg1/> </twopartsop> </soap:body> style= rpc <soap:body> <arg0/> <arg1/> </soap:body> style= document 58

59 Binding delle operazioni All interno dell elemento binding vengono ripetuti gli elementi operation della corrispondente porta astratta, aggiungendo le informazioni sul binding In ciascuna operation dovrà essere inserito un elemento soap:operation che specifica lo stile di codifica dell operazione, solo se diverso da quello dichiarato nel soap:binding (attributo style) la SOAPAction associata, solo se il trasporto è HTTP (attributo soapaction) 59

60 Binding degli input/output Il contenuto degli elementi input e/o output che compongono ciascuna operation non deve essere ripetuto all interno del binding Gli input e output conterranno invece dei nuovi elementi che specificano più in dettaglio come verrà costruito il corrispondente messaggio SOAP, in particolare quali informazioni dovranno essere mappate nell Header e quali nel Body del messaggio 60

61 Binding degli input/output: Body Per definire il contenuto del corpo del messaggio SOAP si usa l elemento soap:body specificando: le parti del messaggio che saranno incluse nel corpo (attributo parts); se non presente, tutte le parti del messaggio saranno inserite nel Body la codifica dei tipi interessati (attributi use e encodingstyle) use= encoded richiede la codifica di ogni parte in base al suo tipo secondo le regole di encodingstyle use= literal indica che le parti vanno copiate letteralmente nel messaggio il namespace di provenienza degli elementi usati nel messaggio (attributo namespace) 61

62 Binding degli input/output: esempio <binding name= PlaceFinderSoap type= PlaceFinderSoap > <soap:binding style= rpc transport= /> <operation name= findplace > <soap:operation soapaction= findplace style= rpc /> <input name= findplace1soapin > <soap:body use= encoded namespace= encodingstyle= /> </input> <output name= findplace1soapout > <soap:body use= encoded namespace= encodingstyle= /> </output> </operation> </binding> 62

63 Binding degli input/output: Header Opzionalmente, è possibile mappare anche alcune parti del messaggio nell Header del messaggio SOAP Ciascuna header entry è ottenuta con l elemento soap:header specificando: il messaggio e la sua parte che diventerà una header entry (attributi message e part) gli elementi della parte interessata possono includere gli attributi actor e mustunderstand di SOAP, ma solo se use= literal la codifica dei tipi (use e encodingstyle) e il namespace degli elementi (attributo namespace) 63

64 Binding degli input/output: Fault Opzionalmente, è possibile specificare i messaggi che saranno restituiti in caso di errore nell elaborazione del Body e dell Header soap:fault, ha la stessa sintassi di soap:body e può essere incluso negli elementi fault associati alle operation soap:headerfault ha la stessa sintassi di soap:header e può essere incluso negli elementi soap:header stessi 64

65 Binding degli input/output: Fault <operation name= twopartsop > <soap:operation soapaction= /> <input name= twoparts1soapin > <soap:body use= literal namespace= encodingstyle= /> <soap:header message= twopartsophdr part= h1 use= literal namespace= /> <soap:header message= twopartsophdr part= h2 use= literal namespace= > <soap:headerfault message= twopartsophdr part= h2e use= literal namespace= /> </soap:header> </input> <fault> <soap:fault name= twopartsfault use= encoded namespace= /> </fault> </operation> 65

66 Porte e servizi Una porta è l istanza di una porta astratta (porttype) ottenuta tramite un binding Le porte sono specificate con elementi di tipo port ogni port ha un nome unico (attributo name) ogni port fa riferimento al nome di un binding (attributo binding) se il binding è con SOAP, l elemento port deve contenere un elemento soap:address che specifichi l indirizzo di rete della porta (attributo location) Le porte non sono dichiarate globalmente, ma all interno di servizi (elemento service) 66

67 Porte e servizi <service name= PlaceFinder > <port name= PlaceFinderSoap binding= PlaceFinderSoap /> <soap:address location= /> </port> </service> 67

68 Riassunto della definizione concreta 68

69 Riassunto della definizione WSDL 69