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.