Le basi tecnologiche

L’attuale visione dei Web Services, che come sappiamo attualmente è una visione IBM-Microsoft ma che evolverà presto in uno standard W3C differente, si basa sostanzialmente su tre tecnologie, più o meno consolidate. Queste sono:

• SOAP
• WSDL
• UDDI

La tecnologia SOAP è stata ampiamente descritta nell’articolo precedente, 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 o 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, cioè 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, che 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], definisce un insieme 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, o binding
• la definizione del servizio

La combinazione di più definizioni di questi tipi definisce un Web Service.

Vediamo subito un esempio di WSDL, 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:StockQuoteSoapBinding">
      <soap:address location="http://example.com/stockquote"/>
    </port>
  </service>
</definitions>

L’esempio mostra come WSDL separi il livello astratto della definizione del servizio dal livello concreto del binding e dell’endpoint.

Tipi, messaggi, operazioni e binding

I tipi descrivono le strutture dati utilizzate dal servizio, tipicamente tramite XML Schema. I messaggi rappresentano gli input e gli output associati alle operazioni. Le operazioni definiscono la semantica del servizio. Il binding collega infine questa descrizione astratta ad un protocollo concreto, per esempio SOAP su HTTP.

Questa suddivisione consente un notevole grado di flessibilità: la stessa descrizione astratta può essere collegata a binding differenti e a endpoint differenti, mantenendo invariata la semantica del servizio.

Conclusioni

WSDL è il punto di giunzione tra la descrizione astratta di un servizio ed il suo utilizzo concreto. Per questo motivo è un tassello fondamentale dell’architettura Web Services: disaccoppia client e servizio, rende esplicita l’interfaccia e permette strumenti di generazione e validazione automatica.

Nei prossimi articoli il discorso potrà essere esteso agli altri elementi dell’ecosistema Web Services, in particolare ai rapporti tra SOAP, WSDL e UDDI. ---