L’elemento PortType

Ma perchè abbiamo definito un solo messaggio per salvare l’utente?

Per dare risposta a questa domanda bisogna introdurre il tag <portType>. Questo elemento è senza dubbio il più importante all’interno di un documento WSDL infatti ha il compito di definire un Web service, le operazioni che può effettuare ed i messaggi che sono coinvolti in questo processo.

È importante anche sottolineare il valore astratto del <portType>. Possiamo infatti compararlo con una libreria di funzioni del tutto simile a quella che troviamo nei principali linguaggi di programmazione. Questo risulta ulteriormente chiaro se ripetiamo ancora una volta che lo scopo di questo elemento è descrivere le operazioni (funzioni) ed i messaggi che utilizzano (quindi il tipo degli argomenti passati e dei dati che ritornano).

Ogni operazione definita all’interno del <portType> può essere di quattro tipi:

• One-way: può ricevere un messaggio ma non ritorna alcuna risposta
• Request-response: può ricevere una richiesta e ritorna una risposta
• Solicit-response: può inviare una richiesta ma non attende per la risposta
• Notification: può inviare un messaggio ma non attende la risposta

Il messaggio che abbiamo definito per salvare l’utente (save_userRequest) è un messaggio di tipo one-way. Ci serviva solo per questo esempio e vi sconsiglio di usare messaggi one-way per operazioni di salvataggio perchè l’applicazione che la fa eseguire, senza ricevere una risposta, non può sapere se l’operazioneè andata a buon fine.

Proseguendo con l’esempio è giunto il momento di creare anche l’elemento portType.

<portType name="gestioneUtentiType">
  <operation name="getUserById">
    <input message="tns:get_userRequest" />
    <output message="tns:get_userResponse" />
  </operation>
  <operation name="saveUser">
    <input message="tns:save_userRequest" />
  </operation>
</portType>

Come potete notare definire il <portType> è piuttosto semplice. È sufficiente infatti darli un nome ed inserire delle operazioni. Ogni operazione può essere composta da un messaggio di input, output oppure entrambi. Operazioni di solicit-response e request-response possono includere anche un terzo elemento (opzionale) chiamato fault che specifichi un messaggio con un formato valido per descrivere tutti gli errori che possono avvenire durante l’operazione.