Corso di Web Services A A. 2010 2011 Domenico Rosaci Descrivere servizi SOAP

1. Corso diWeb ServicesA A. 2010 2011Domenico RosaciDescrivere serviziSOAP Descrivere servizi SOAP

2. Rendere “usabili” i WS • Abbiamo visto come realizzare un Web Service basato su SOAP • Adesso introdurremo le tecnologie necessarie per rendere semplice l’utilizzo dei WS • In particolare decsriveremo il Web Service Description Language (WSDL), che rende possibile la semplificazione dei clients per WS già esistenti Descrivere servizi SOAP

3. Descrivere WS • Una caratteristica dei WS è che possono essere resi “auto descriventi”. Adesso vedremo come • Un’applicazione “espone” delle funzionalità, e per usare ciascuna funzionalità il client deve invocare determinate operazioni • Le operazioni comportano l’invio da parte del client di “pezzetti” di informazione, e in risposta all’operazione altra informazione può essere restituita al client • Ogni volta che l’implementazione dell’applicazione cambia, occorre ricompilare tutto: scarsa flessibilità Descrivere servizi SOAP

4. Descrivere WS • Attraverso i WS, l’applicazione può scoprire dinamicamente le informazioni coinvolte, rendendo così più semplice e flessibile l’uso dell’applicazione stessa • La specifica SOAP non copre la problematica descrittiva. Lo standard de facto in questo settore è WSDL • WSDL permette a un WS di descrivere cosa esso fa, come lo fa e cosa un utente deve fare per utilizzarlo Descrivere servizi SOAP

5. Vantaggi nell’usare WSDL • WSDL permette di rendere più semplice l’utilizzo dei WS, specificando con esattezza le interfacce • WSDL rende più semplice la scrittura dell’applicazione client, richiedendo meno codice per il client stesso • WSDL permette che gli eventuali cambiamenti al WS possano essere gestiti dal client semplicemente “scoprendo” tali cambiamenti a run time nella descrizione WSDL, senza dover modificare il client Descrivere servizi SOAP

6. Altro su WSDL • WSDL non è perfetto. • Non c’è supporto al “versioning”, quindi se delle modifiche si fanno all’interfaccia, non c’è modo di propagarle al client • L’interfaccia WSDL è quindi simile a quella che si usa nella OOP, e deve essere considerata “immutabile”, pena la modifica del client • Esistono tool per generare automaticamente descrizioni WSDL. Esempi: Web Services Toolkit e WSIF di IBM, Apache Axis, Toolkit di .NET Descrivere servizi SOAP

7. Sommario • Motivazioni • Specifiche WSDL e un esempio • Tools • Alternative WSDL Descrivere servizi SOAP

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

9. WSDL…Utilizzo

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

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

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

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

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

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

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

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

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

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

20. 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> <message name="PO"> <part name="composite" type="Composite"/> </message>

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

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

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

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

25. WSDL – operazioni L’elemento faultspecifica 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.

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

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

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

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

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

31. Tools: editor Come si scrivono i files WSDL? • A mano: alcuni editor hanno supporti speciali perWSDL • Non si scrivono: generazione automatica (in pochi passi) Descrivere servizi SOAP

32. Tools: validation • I documenti WSDL documents possono essere di grandi dimensioni (il documento WSDL Amazon E-Commerce Service ha 2432 linee di codice ed oltre 100KB) • Tools per validare(analizzare documenti WSDL: • http://xmethods.net/ve2/Tools.po • http://www.softwaresecretweapons.com/jspwiki/services/oy-lm-1.3/generator.jsp Descrivere servizi SOAP

33. Tools: WSDL generation and client generation • Creare manualmente un file WSDL per un WS è un task difficile e soggetto ad errori • Dato un file WSDL, generare un client per interagire con il servizio è un task ripetitivo • Esistono toolkits per tutti i più importanti linguaggi che permettono di automatizzare entrambi i task Descrivere servizi SOAP

34. WSDL toolkit: Java • Axis: http://ws.apache.org/axis/ • Builds stubs, skeleton and data types from WSDL • java org.apache.axis.wsdl.WSDL2Java AWSECommerceService.wsdl • Builds WSDL from Java code • java org.apache.axis.wsdl.Java2WSDL -o wp.wsdl -l "http://localhost:8080/axis/services/WidgetPrice -n"urn:Example6" -p"samples.userguide.example6" "urn:Example6" samples.userguide.example6.WidgetPrice • Axis2: http://ws.apache.org/axis2/ Descrivere servizi SOAP

35. WSDL toolkit: Python • SOAPpy: http://pywebsvcs.sourceforge.net/ • Parsing a WSDL file: >>> from SOAPpy import WSDL >>> wsdlFile = 'http://webservices.amazon.com/AWSECommerceService/AWSECommerceService.wsdl' >>> server = WSDL.Proxy(wsdlFile) >>> server.methods.keys() [u'SellerListingSearch', u'CartCreate', u'SellerLookup', u'Help', u'TransactionLookup', u'CartAdd', u'ItemLookup', u'MultiOperation', u'SimilarityLookup', u'CartClear', u'ListLookup', u'CartModify', u'CustomerContentLookup', u'ListSearch', u'BrowseNodeLookup', u'CartGet', u'SellerListingLookup', u'CustomerContentSearch', u'ItemSearch'] Descrivere servizi SOAP

36. WSDL toolkit: Python – cnt'd >>> itemSearchM = server.methods['ItemSearch'] >>> for inparams in itemSearchM.inparams: ... print inparams.name, inparams.type ... body (u'http://webservices.amazon.com/AWSECommerceService/2005-10-05', u'ItemSearch') >>> >>> for outparams in itemSearchM.outparams: ... print outparams.name, outparams.type ... body (u'http://webservices.amazon.com/AWSECommerceService/2005-10-05', u'ItemSearchResponse') >>> result = server.ItemSearch({'body': {'SubscriptionId': 'xxxxxxxxxxxxxxxxxxxx', 'SearchIndex': 'Books', 'Request' : {'SearchIndex': 'Books', 'Title': 'restaurant end universe'}}}) >>> result.Items.TotalPages 2 >>> result['Items'].TotalResults '18' Descrivere servizi SOAP

37. WSDL toolkit: Python – cnt'd >>> result.Items.Item[0] <SOAPpy.Types.structType Item at -1214384084>: {'ItemAttributes': <SOAPpy.Types.structTypeItemAttributes at -1214386100>: {'Title': 'The Restaurant at the End of the Universe', 'ProductGroup': 'Book', 'Author': 'Douglas Adams'}, 'ASIN': '0345391810', 'DetailPageURL': 'http://www.amazon.com/exec/obidos/redirect?tag=ws%26link_code=sp1%26camp=2025%26creative=165953%26path=http://www.amazon.com/gp/redirect.html%253fASIN=0345391810%2526tag=ws%2526lcode=sp1%2526cID=2025%2526ccmID=165953%2526location=/o/ASIN/0345391810%25253FSubscriptionId=xxxxxxxxxxxxxxxxxxxx'} Descrivere servizi SOAP

38. In conclusione • Lavorare con i tipi complessi è...complesso e non interoperabile • Editare file WSDL a mano è masochistico, e va accuratamente evitato • Se qualcosa sembra corretto ma non funziona, fate un double check dei vostri namespaces Descrivere servizi SOAP

39. Alternative • Al momento, WSDL 1.1 è “il” linguaggio di descrizione per WS • WSDL 2.0 ridefinisce e precisa la grammatica di WSDL • Semplificare lo stack XSD, SOAP/REST, WSDL: SSDL (SOAP Service Description Language), RESEDEL (REstful SErvices DEscription Language), WRDL (Web Resource Description Language), WADL (Web Application Description Language), SMEX-D (Simple Message EXchange Descriptor), WDL (Web Description Language) • Aggiungere semantica alla descrizione di un servizio: WSDL-S, WSML (Web Service Modeling Language) Descrivere servizi SOAP

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

41. UDDI

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

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

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