Supponiamo di avere un'interfaccia (es. IAuthentication) che specifica due o più overload di un metodo (es. Login). Quando si vuole esporre un'implementazione di tale interfaccia come servizio WCF aggiungiamo gli attributi ServiceContract a livello di interfaccia e OperationContract a livello di metodo, ma se non facciamo attenzione a specificare un alias univoco per ciascun overload tramite la proprietà Name si scatena una InvalidOperationException nel momento in cui viene invocato il metodo ServiceHost.Open(). Riporto quindi un esempio corretto di overloading di metodi in ambiente WCF:
[ServiceContract]
public interface IAuthentication
{
[OperationContract(Name="LoginByUsernamePassword")]
UserInfo Login(string username, string password);
[OperationContract(Name="LoginByPIN")]
UserInfo Login(string PIN);
...
}
Approfondendo l'argomento, il nocciolo della questione si trova nel fatto che il compilatore non possiede alcuna conoscenza speciale nei confronti degli attributi WCF, ma si limita semplicemente ad inserirli nei metadati dell'assembly. La compilazione dunque va a buon fine.
Tuttavia in fase di esecuzione, in assenza di un alias univoco, quando WCF avvia il servizio vengono interrogati semplicemente i metadati per generare il contratto WSDL, un linguaggio che (ancora) non supporta concetti provenienti dal mondo OO come l'overloading o l'ereditarietà. Per questo WCF si accorge del fatto che ci sono due metodi che hanno lo stesso nome (Login nell'esempio) e scatena di conseguenza un'eccezione a runtime.
La proprietà Name a livello di OperationContract permette quindi di definire il nome univoco dell'operazione corrispondente nel WSDL generato da WCF.
Domanda: come verranno presentati questi overload al service consumer?
Se utilizziamo svcutility.exe notiamo che nella classe proxy generata vengono inseriti gli alias (nell'esempio LoginByUsernamePassword e LoginByPIN), ma possiamo sempre modificare a mano il sorgente di tale classe affinché al client risultino visibili gli overload originari.
Insomma...un caso che mostra come lo sviluppo object-oriented spesso non si traduce direttamente nello sviluppo SOA-oriented :).
Technorati tags: 
WCF