• SOAP
• WSDL
• UDDI

La tecnologia SOAP è stata ampiamente descritta nell’articolo [1], mentre UDDI è una tecnologia nuova e non ancora completamente consolidata – sicuramente meno matura di SOAP – che dovrebbe consentire l’accesso a registri dove i Web Services vengono elencati e catalogati.
La tecnologia WSDL si pone a metà tra SOAP (il protocollo di “filo” – wire protocol) ed il registro UDDI e consente di definire la semantica dei servizi scomponendo i metadati in elementi più o meno astratti.
Le informazioni contenute in un “WSDL” sono rappresentate in XML e permettono di definire i messaggi di input ed output di un determinato servizio (codificati preferibilmente in XML Schema), la relazione tra questi (le operazioni) ed il collegamento fisico ad un determinato “endpoint” che costituisce il punto di fornitura fisico del servizio web.
Il WSDL è un documento XML e quindi può essere contenuto nel filesystem locale oppure caricato dinamicamente da un web server. Quello che conta nelle specifiche non è la posizione fisica dell’informazione XML ma la semantica e la struttura dei contenuti.
 
 
 

A chi si rivolge WSDL
WSDL è una specifica che interessa sicuramente chi intende sviluppare Web Services. Per ciascun servizio sarebbe bene definire un WSDL in modo che il client non acceda direttamente al servizio web ma passi dal livello di indirezione del WSDL.
Anche chi sviluppa la parte client dovrebbe considerare questo protocollo e disaccoppiare la chiamata ai Web Services. Per alcuni aspetti l’utilizzo di WSDL può essere ridondante, come ad esempio le informazioni aggiuntive necessarie a definire il binding con SOAP (potrebbero essere implicite), ma dobbiamo ricordare che lo scopo del WSDL è quello di definire una grammatica di definizione di un servizio di network generico e non strettamente legato agli altri protocolli “Web Services” come SOAP ed UDDI. Quindi un parser di documenti WSDL (utile ad esempio a validare le richieste e le risposte verso e da un servizio web) dovrà interpretare tutte queste informazioni ed estrarne quelle utili.
 
 
 

Le specifiche WSDL
La specifica di questa tecnologia, reperibile all’indirizzo [2] definiscono un inseme di informazioni relative alla definizione dei servizi ed al collegamento di questi a SOAP, HTTP e MIME. Gli elementi basilari che compongono una definizione WSDL sono:

• i tipi;
• i messaggi;
• le operazioni;
• i collegamenti (binding);
• la definizione del servizio.

La combinazione di più definizioni di questi tipi definiscono un Web Service.
Vediamo subito un esempio di WSDL (un esempio vale spesso più di mille spiegazioni – infatti anche le specifiche SOAP e WSDL riportano quasi subito un esempio pratico di utilizzo. D’altra parte il formato XML è molto leggibile), estratto dalle specifiche WSDL 1.1

Example 1 SOAP 1.1 Request/Response via HTTP

<?xml version="1.0"?>
<definitions name="StockQuote"

targetNamespace="http://example.com/stockquote.wsdl"
          xmlns:tns="http://example.com/stockquote.wsdl"
          xmlns:xsd1="http://example.com/stockquote.xsd"
          xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
          xmlns="http://schemas.xmlsoap.org/wsdl/">

    <types>
       <schema targetNamespace="http://example.com/stockquote.xsd"
              xmlns="http://www.w3.org/2000/10/XMLSchema">
           <element name="TradePriceRequest">
              <complexType>
                  <all>
                      <element name="tickerSymbol" type="string"/>
                  </all>
              </complexType>
           </element>
           <element name="TradePrice">
              <complexType>
                  <all>
                      <element name="price" type="float"/>
                  </all>
              </complexType>
           </element>
       </schema>
    </types>

    <message name="GetLastTradePriceInput">
        <part name="body" element="xsd1:TradePriceRequest"/>
    </message>

    <message name="GetLastTradePriceOutput">
        <part name="body" element="xsd1:TradePrice"/>
    </message>

    <portType name="StockQuotePortType">
        <operation name="GetLastTradePrice">
           <input message="tns:GetLastTradePriceInput"/>
           <output message="tns:GetLastTradePriceOutput"/>
        </operation>
    </portType>

   <binding name="StockQuoteSoapBinding" 
            type="tns:StockQuotePortType">
      <soap:binding style="document" 
            transport="http://schemas.xmlsoap.org/soap/http"/>
      <operation name="GetLastTradePrice">
      <soap:operation 
            soapAction="http://example.com/GetLastTradePrice"/>
           <input>
               <soap:body use="literal"/>
           </input>
           <output>
               <soap:body use="literal"/>
           </output>
        </operation>
    </binding>

   <service name="StockQuoteService">
      <documentation>My first service</documentation>
      <port name="StockQuotePort" binding="tns:StockQuoteBinding">
        <soap:address location="http://example.com/stockquote"/>
      </port>
   </service>

</definitions>

Nel documento si possono evincere le diverse sezioni citate sopra.
In dettaglio:
 

• la sezione types definisce i tipi utilizzati all’interno dei messaggi del servizio. L’utilizzo del tag schema permette di scegliere quale tipo di encoding utilizzare (nell’esempio si usa proprio l’XML Schema – Nota: da poco le specifiche di XML Schema sono diventate una raccomandazione W3C e quindi probabilmente l’URL cambierà). I tipi corrispondono più o meno a strutture dati di tipo struct del linguaggio C;
• le sezioni message contengono le definizioni dei messaggi di scambio del servizio e fanno uso di parti definite come tipi nelle sezioni types. Possiamo pensare ai messaggi come aggregati di tipi;
• la sezione portType definisce le operazioni esposte dal Web Service (sostanzialmente i metodi remoti dell’ “ oggetto” remoto che costituisce il servizio web). Per ogni metodo viene definito il messaggio di input ed il messaggio di output;
• la sezione binding contiene il collegamento tra il portType (cioè la definizione astratta del servizio) all’end-point fisico. Queste sono le informazioni che indicano il protocollo (nell’esempio SOAP) da utilizzare e come ricondurre i messaggi di input ed output al protocollo utilizzato;
• la sezione service contiene la definizione del servizio in termini della sua descrizione e della posizione fisica del servizio (tipicamente il suo URL) – definiti endpoint;

Le operazioni possibili (portType) possono essere di diverso tipo e costituiscono le “primitive” che un endpoint può supportare. Sono sostanzialmente le quattro combinazioni ottenute dall’invio e la ricezione di un messaggio da parte di un endpoint. Queste sono:

• one-way. L’endpoint riceve un messaggio inviato dal client. E’ una sorta di fire&forget dove il Web Service riceve una notifica;
• request-response. In questo caso l’endpoint riceve un messaggio di richiesta, esegue le operazioni relative e fornisce al client una risposta inviando un messaggio correlato alla richiesta ricevuta;
• solicit-response. E’ l’opposto del precedente. Qui è l’endpoint che invia una notifica al client ed in seguito attende da questo una risposta correlata;
• notification. La notifica prevede l’invio da parte dell’end-point di un messaggio. E’ l’opposto dell’one-way e può essere utile per implementare sistemi di push (come i canali di IE4, ad esempio).

Altri collegamenti
Le specifiche WSDL, come abbiamo accennato sopra, definiscono alcuni collegamenti (bindings) con altre tecnologie, quali SOAP, HTTP e MIME.
Il binding con SOAP è relativo agli endpoint e cioè alle specifiche di invio dei messaggi di input ed output tramite SOAP. Senza entrare troppo nel dettaglio (le specifiche sono alcune pagine) possiamo dire che tramite una grammatica semplice ma espandibile, le informazioni relative ai messaggi vengono veicolate nella struttura SOAP utilizzando i blocchi Header e Body.
Per quanto riguarda HTTP, invece, le specifiche WSDL definiscono collegamenti per i verbi GET e POST in modo da consentire ad una applicazione sviluppata per WSDL di accedere ad un Web Server come se fosse un Web Service. Interessante qui come WSDL potrebbe costuire un wrapper su HTTP di fatto riducendone l’importanza – sarebbe uno dei tanti possibili protocolli a basso livello per la fornitura di servizi.
Un altro collegamento interessante è quello con alcuni tipi di encoding MIME, tra cui l’application/x-www-form-urlencoded che viene utilizzato per eseguire l’invio di una FORM in HTML ed il text/xml utilizzato per indicare testi XML. Anche la grammatica relativa al collegamento a MIME è espandibile e potrà essere sviluppata in futuro con altre tipologie di collegamenti.
 
 
 

Conclusioni
Come abbiamo già accennato sopra, è probabile che le specifiche WSDL cambino presto in seguito al lavoro del gruppo di sviluppo W3C per l’XML Protocol (tra l’altro è una indicazione data proprio da loro). Questo anche perché esiste già una specifica W3C chiamata RDF (Resource Definition File) che definisce dei metadati di descrizione (un concetto utilizzato anche all’interno dei WSDL) che probabilmente potrà essere utilizzata come base, insieme ai WSDL, per il nuovo linguaggio di definizione dei servizi web del W3C.
 
 
 

Riferimenti
[1] Andrea Giovannini - SOAP e Java Integrazione di applicazioni con Java e il nuovo protocollo SOAP - http://www.mokabyte.it/2001/01/soap.htm
[2] Specifiche WSDL - http:/www.w3c.org/TR/wsdl
[3] Massimiliano Bigatti – Web Services - http://www.mokabyte.it/
[4] Supercharging WSDL with RDF – IBM Library