WSE 2.0 è la libreria di Microsoft che estende l'attuale implementazione ASP.NET dei web services. In essa troviamo l'implementazione di specifiche sulla sicurezza (OASIS WSSE), uno strumento di diagnostica (tracing sui messaggi SOAP) ed un framework message based (ala SOA).
Avendo ormai 'giocato' con WSE da un pò di tempo, mi sento pronto per tirare qualche conclusione. La libreria (intendo WSE) è sicuramente molto interessante ed apre una strada (che diverrà poi quella di Indigo) verso i 'veri' web services, cioè delle interfacce orientate al messaggio. Ahimè, l'attuale implementazione paga alcune 'deficienze' dovute, per lo più a una mancanza di stabilità nel mondo delle specifiche.
Infatti, la grande pubblicità di WSE ruote attorno alla sicurezza. Già, ma le specifiche sulla sicurezza sono così giovani (e direi pure incomplete e mal integrate con WSDL) che per mantenere l'interoperabilità si devono fare numeri da circo (provate a far dialogare un web service WSE enabled con una applicazione Office 2000 o XP !). Alla fine, si risolve il tutto con un bel SoapHeader e risolviamo tutti i problemi :-). Il problema è quindi, si ma .NET ha la sua implementazione WSE, ma che dire di SOAP Toolkit, Java e mondo compact framework ? Cercando si trova, ma nulla è stabile e soprattutto certificato !
Inoltre, se guardiamo bene l'implementazione della security con WSE, ci rendiamo conto che non è il massimo. Basta vedere come si deve implementare la UsernameToken authentication a 'regola d'atre'. Basta creare un file di policy (ricordate com'era fatto in WSE 1.0 ? Ecco, ricominciate da capo) quindi modificare il we.bofing dicendo che c'è una policy. Ora dovete implementare una classe che derivi da UsernameTokenManager per controllare la password ed infine rilevare l'identità nel web method stesso. Sono tre attività apparentemente distinte ma che in realtà influiscono noveolmente l'una sull'altra. Indigo (per quel che si è visto) è decisamente meglio: un bel attributo a livello di Web Method e via :-))
Passiamo ad un'altro slogan. Con WSE puoi veramente usare web services su protocolli differenti all'HTTP. Vero ! Ma chi li usa ? E poi, che binding usiamo dal momento che lo stesso W3C timidamente parla di non-HTTP ! Alla fine cosa usiamo, HTTP perchè passa attraverso i firewalls ed è facilmente controllabile.
Bene, ma allora WSE è proprio da buttare via ? NO ! E' una libreria di studiare a fondo, non solo perchè il modello di programmazione va nella direzione di Indigo, ma perchè con WSE possiamo veramente scrivere web service orientati ai messaggi. Quindi ci concentriamo sulla vera natura dei web services. Se poi aggiungiamo che possiamo hostare con pochissimo codice un web service su IIS o una applicazione console (ok, solo per provare) oppure su una applicazione COM+ allora il tutto si fa più interessante.
Che fare allora ? Bene, studiare WSE (magari per fare qualche prototipo) ma usare ASP.NET in produzione :-) Se proprio volete usare WSE in produzione, testatelo a fondo anche con chi lo andrà a consumare.