Il Web Service Definition Language (WSDL)

WSDL è l’acronimo di Web Service Description Language[1], un linguaggio per la descrizione dei servizi web. Esso è una grammatica XML che si propone di descrivere un servizio web come una serie di end points capaci di scambiarsi messaggi. Da un certo punto di vista Wsdl è un Interface Description Language (IDL), come potrebbe essere Corba IDL o Microsoft IDL, e come tale è un linguaggio che definisce i tipi di dato, i messaggi e il tipo di comunicazione che ogni messaggio necessita; offre un grado di estendibilità che gli altri IDL non hanno, permettendo loro di scrivere i messaggi di scambio e i loro end point senza dover specificare il protocollo di rete che si occupa del trasporto.

Il file Wsdl specifica i parametri e i vincoli che stabiliscono le modalità di svolgimento della comunicazione, in cui qualunque elemento è astratto ed è un componente fondamentale, visto che consente di conoscere direttamente le possibilità e le funzionalità di qualunque web services.

Figura 1: Rappresentazione di un documento WSDL

Un file Wsdl si divide in due parti fondamentali:

una parte descrive l’implementazione del servizio, tramite gli attributi Service e Port, l’altra definisce l’interfaccia del servizio descrivendo i messaggi, i metodi e il tipo di dati supportato, con i relativi marcatori.

Nel prossimo paragrafo vengono esposti i principali tag che possono trovarsi in un documento Wsdl e ne viene data una descrizione dettagliata in modo che ne sia chiaro il loro utilizzo.

Dettagli protocollo WSDL

Per comprendere meglio il linguaggio WSDL occorre comprenderne la terminologia utilizzata.

In WSDL un servizio espone uno o più gruppi di operazioni tramite i seguenti elementi:

  • Operation: Entry point di un servizio Web, è assimilabile ad un metodo Java.
  • PortType: Gruppo di operazioni. E’ assimilabile ad un’interfaccia Java.
  • Message: Contenitori di informazione. Definiscono le entità scambiate tra client e server. Per invocare un’operazione il client invia un messaggio contenente i dati in ingresso ed eventualmente aspetta come risposta da parte del server un messaggio contenente dati in uscita.
  • Part: Ogni messaggio è composto da una o più parti. Ogni dato nel messaggio costituisce una parte. Nel caso di servizi web orientati agli oggetti ciascuna delle parti di un messaggio rappresenta un parametro della procedura invocata.
  • Binding: Esprime come i messaggi SOAP vengano mappati sul protocollo di trasporto sottostante.
  • Port: E’ l’entry point fisico del servizio web, ogni porta specifica l’indirizzo fisico a cui si trova (ad esempio: http://www.someorg.com/ws/myws ) ed il binding da usare con essa.

Figura 2: Strutture WSDL


Un servizio è formato da una o più porte (port). Ad ogni porta (indirizzo fisico) è associato un binding. Ogni binding fa riferimento ad un portType, alle operazioni contenute in esso e ai messaggi che compongono l’operazione. Ogni portType ha una o più operazioni. Ogni operazione ha messaggi di input e/o di output. Ogni messaggio è costituito da zero o più parti e ogni parte è caratterizzata da un tipo di dato. Questo tipo di dato può essere standard (tra quelli definiti in XML Schema) o può essere un tipo definito dall’utente utilizzando appunto XML Schema.

Passiamo ora ad analizzare in dettaglio i vari elementi che compongono un file WSDL

L’elemento <definitions>

E’ l’elemento radice del file WSDL, esso contiene le dichiarazioni dei namespaces utilizzati nel documento.

<definitions
targetNamespace=”urn:myNameSpace”
xmlns=http://schemas.xmlsoap.org/wsdl/
xmlns:xsd=http://www.w3c.org/2001/xmlschema
xmlns:soap=”http://schemas.xmlsoap.org/wsdl/soap”
...
xmlns:tns=”urn:myNameSpace”>

In un documento XML i namespaces sono identificato per mezzo di un QNAME (il nome breve che segue xmlns: ) se due elementi o due attributi importati da due namespace diversi hanno lo stesso nome questi dovranno essere qualificati con il QNAME seguito da due punti. Esiste un namespace predefinito, che è quello che segue la dichiarazione xmlns= se due elementi in conflitto fanno capo a due namespaces distinti, verrà scelto quello predefinito.

L’attributo targetNameSpace definisce il namespace che il documento sta creando. E’ prassi comune creare un QNAME per il namespace di destinazione (si veda l’ultima riga in cui e’ definito il QNAME tns)

L’elemento <types>

Nell’elemento <types> di un documento WSDL sono indicati i tipi di dato astratti usati all’interno degli elementi <message> che definiscono il formato dei dati scambiati. WSDL non definisce un proprio sistema di definizione dei tipi ma si appoggia a linguaggi esistenti. Tra di essi un posto particolare è riservato a XML Schema. WSDL inoltre definisce un meccanismo di estensione che gli permette di ospitare un qualsiasi altro linguaggio di definizione.

<types>
<xsd:schema xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>
<input message=’theMessage’/>
<output message=’anotherMessage’/>
</xsd:schema>
</types>
Nel caso non si decida di utilizzare Schema ma un altro sistema di tipi (ad esempio. RDF) gli elementi interni all’elemento <types> rispecchieranno tale nuovo sistema di tipi.
<types>
<rdf:RDF xmlns:rdf=”http://www.w3.org/100/02/22-rdf-syntax-ns#“>
...
</rdf:RDF>
</types>

L’elemento <message>

L’elemento <message> descrive i dati scambiati durante lo svolgimento di un servizio, utilizzando i tipi definiti nella sezione <types> oppure utilizzando tipi standard, definiti da XSD. Ogni messaggio è identificato in maniera univoca da un attributo ‘name’. Ogni messaggio contiene uno o più sotto elementi <part> che hanno un attributo obbligatorio “name”.

<message name=’theMessage’>
<part type=’xsd:string’ name=’id’ />
<part type=’tns:myType’ name=’timeout’ />
</message>

In questo caso il messaggio risulta composto da due parti logiche distinte, una XSD standard e una precedentemente definita nella sezione <types>. In una chiamata RPC è logico fare corrispondere ad ogni parametro una parte del messaggio.

Quando non si utilizzi Schema come sistema di definizione dei tipi, ma si ricorra alla estensibilità nel sotto elemento <part> devono essere inseriti attributi derivanti dal sistema di tipo scelto. Si potrebbe anche fare riferimento a tipi non definiti nel documento corrente (come accade nell’esempio precedente con il tipo “xsd:string”).

L’elemento <portType>

L’elemento <portType> specifica le operazioni supportate dal servizio web. Ogni elemento <portType> contiene uno o più elementi <operation>. Ogni elemento <operation> è assimilabile ad un metodo Java e può specificare un messaggio di input e uno di output.

L’ordine degli elementi <input> e <output> all’interno degli <operation> definisce il modello di trasmissione.

Le specifiche di WSDL definiscono quattro modelli di trasmissione:

  • request-response : questo modello prevede che il client invii una richiesta e il server risponda. Saranno presenti entrambi gli elementi <input> e <output> nell’ordine.
  • solicit-response : questo modello prevede che il server solleciti una risposta da parte del client. Sono presenti entrambi gli elementi <output> e <input> nell’ordine.
  • one-way : Il client invia una richiesta senza aspettarsi una risposta. E’ presente solo l’elemento <input>.
  • notification : Il server invia un messaggio unidirezionale al client non aspettando una risposta. E’presente solo l’elemento <output>.
<portType name=’myPortType’ />
<!--Request-response operations -->
<operation name=’RROperation’>
<input message=’theMessage’/>
<output message=’anotherMessage’/>
</operation>
<!--Sollicit-response operations -->
<operation name=’SollicitOperation’>
<output message=’theMessage’/>
<input message=’anotherMessage’/>
</operation>
<!--Notification operations -->
<operation name=’NotificationOperation’>
<output message=’theMessage’/>
</operation>
<!--One-way operations -->
<operation name=’onewayOperation’>
<input message=’theMessage’/>
</operation>
</portType>

La presenza delle operazioni solicit-response e notification è attualmente oggetto di discussione perché non sono chiari i meccanismi con cui possano essere implementati.

L’elemento <binding>

L’elemento <binding> definisce come saranno concretamente serializzati i dati definiti da <types>. Si possono usare delle estensioni standard, oppure se ne possono creare delle proprie. L’estensione più usata è l’estensione SOAP, essa consente di usare gli elementi di soap all’interno dell’elemento binding.

<binding name=”myBinding” type=”tns:myPortType”>
<soap:binding style=”document” transport=”http://schemas.xmlsoap.org/soap/http”>
<operation name=”docOperation”>
<soap:operation soapAction=”http://tmpuri.com/docOperation”>
<input>
<soap:body use=”literal”>
</input>
</soap:operation>
</operation>
<operation name=”RPCOperation”>
<soap:operation soapAction=”http://tmpuri.com/RPCOperation” style=”rpc”>
<input>
<soap:header part=”headMsg” use=”encoded” encodingStyle=”http://schemas.xmlsoap.org”/>
<soap:body use=”encoded” encodingStyle=”http://schemas.xmlsoap.org”/>
</input>
</soap:operation>
</operation>
</soap:binding>
</binding>

Il listato precedente indica che il portType “myPortType” sarà serializzato con il binding “myBinding”.

Di particolare interesse è l’attributo style nell’elemento <soap:binding> esso può assumere due valori:

  • document : in questa maniera si sta inviando un documento XML e si aspetta come risposta un documento XML. Nessun riferimento a passaggio di parametri o a chiamate di procedura.
  • rpc :si sta ragionando in termini di invocare un metodo, passare i parametri e recuperare il valore di ritorno. I messaggi di input e di output conterranno parti che corrispondono ai parametri del metodo e ai valori di ritorno.

L’attributo style può essere ridefinito da ogni elemento <operation>, nell’esempio la seconda operazione è orientata all’ rpc.

Un altro attributo importante è l’attributo use degli elementi <soap:header> e <soap:body>. Esso indica come saranno serializzati gli elementi contenuti entro questi elemento.

  • literal :Lo schema definito nella sezione <types> unito a quanto scritto nella sezione <message> definiscono completamente il modo secondo cui i messaggi saranno serializzati.
  • encoded :Ogni elemento part ha un tipo ma quel tipo da solo non fornisce tutte le informazioni necessarie alla serializzazione, è quello che si definisce un tipo astratto. Occorre specificare un ulteriore documento con l’attributo encodingStyle che fornisca le regole di serializzazione.

In generale si tende ad usare la combinazione di codifica document/literal e rpc/encoded. Nel primo caso quando si scambiano documenti si suppone che siano in un qualche formato standard. Per ottenere ciò si definisce uno schema XSD per questi documenti, e la sterilizzazione avviene direttamente rispecchiando questo schema. Nel caso di una RPC ciò non è necessario perché esistono già regole di serializzazione definite da SOAP per oggetti, strutture e array.

L’elemento <service>

L’elemento <service> specifica l’ URL al quale si trova il servizio WEB. Questo elemento potrebbe anche non essere presente perché il linguaggio WSDL ha lo scopo principale di descrivere un’interfaccia astratta, mentre questo elemento identifica l’endpoint fisico.

</pre>
<service name=’MyService’>
<documentation>
Descrizione del servizio
</documentation>
<port name=’myport’ binding=’theBinding’>
<soap:address
location=’http://www.someorg.com/ws/myws’ >
</port>
</service>
<pre>

Ogni elemento <port> definisce un punto di accesso fisico. Un attributo di questo elemento è binding il cui valore è una stringa che riporta il nome di un elemento <binding> sopra dichiarato.

Riferimenti

[1] La specifica completa di questo IDL (Interface Description Language) è reperibile presso l’URL: http://www.w3.org/TR/2002/WD-wsdl12-20020709

1 Stella2 Stelle3 Stelle4 Stelle5 Stelle (1 voti, media: 5,00 di 5)
Loading...
You can leave a response, or trackback from your own site.

Leave a Reply

*