Nel lungo termine, le specifiche, ora standard di fatto, potrebbero essere superate. Il panorama è in costante evoluzione e le aziende che maggiormente contribuiscono a infittire il campo sono, guardacaso, Ibm e Microsoft. Ma occhio a Sun (con Java)
Aparte la partnership pubblica che ha con Ibm in materia di standard per i Web service, Microsoft ha una propria idea architetturale che è fortemente determinata a divulgare. Del resto, nessun altro vendor ha lanciato qualcosa di simile a .Net, l’architettura su cui la casa di Redmond poggia tutte le proprie fortune. Nemmeno Big Blue, Bea e Oracle, che dei Web service sono comunque alfieri, hanno puntato quasi tutto sui servizi Web come ha fatto la casa di Redmond. Logico, quindi, che Microsoft cerchi il più possibile di standardizzarne l’utilizzazione.
Al workshop del W3C sui Web service dello scorso anno, Ibm e Microsoft avevano presentato una soluzione congiunta chiamata “Web service framework” che suggeriva una dozzina di componenti funzionali canditati alla standardizzazione. Questi includono specifiche esistenti, come Wsdl e Uddi, ma anche lavori in corso, come quelli sul protocollo Xml, e un buon numero di progetti futuribili. Dopo l’annuncio congiunto con Big Blue, Microsoft ha lavorato sulla Global Xml Web Service Architetture (Gxa) che comprende i migliori frutti delle partnership strette con altre società e l’insieme di specifiche Ws-Security, Ws-License, Ws-Routing, Ws-Referral.
La società ha anche pubblicato una specifica chiamata Direct Internet Message Encapsulation (Dime), che è stata sottoposta all’Ietf. Questa tecnologia di incapsulamento fa il mapping diretto di Soap con il Tcp, gettando le basi per una rivoluzione in fatto di performance.
L’ecumenicità di Ibm
E mentre la pubblicistica la pone il più possibile vicina a Microsoft per quanto riguarda gli standard, Ibm mostra di avere una visione del proprio potenziale a lungo termine abbastanza differente da quella della società di Bill Gates. Senza dubbio alcuno, all’interno di Big Blue molti vorrebbero sfruttare il tradizionale vantaggio che ha l’azienda in aree come i processi di transazione, per creare una differenziazione competitiva nei confronti di Microsoft.
Altri vedono, invece, un maggior vantaggio nel procedere affiancati. Ibm ha dichiarato di aver sviluppato una propria architettura di Web service da prima del 1999, che si metteva, già allora, su quello stesso piano che, due anni dopo, avrebbe scelto .Net. In seguito, comunque, Big Blue si è affidata alla modalità operativa di Microsoft, facendo, forse, affidamento sulla propria abilità di “influenzare” i progettisti Microsoft. Recentemente, Ibm ha anche parlato di Web service integration framework (Wsif), cioè di un modo per creare i Web service senza Soap. Inoltre, ha promesso una forma più robusta di Http, conosciuta come Reliable Http (HttpPr). Altri suggerimenti di Ibm riguardano i “misteriosi” Web service endpoint language (Wsel), che non si sa se siano stati assorbiti dal nuovo Bpel4ws. È interessante, infine, osservare che Ibm ha fornito la guida tecnica per il Jsr 109, la specifica chiave che lega i Web service al J2Ee.
L’antesignanità di Java
Potrà sorprendere i profani, ma Sun è stata il pioniere della programmazione Xml. A testimonianza di ciò, ricordiamo che già nel 1998 erano stati pubblicati diversi libri che indicavano come usare Java insieme a Xml. Tuttavia, questo linguaggio meglio si prestava a operare con i dati, mentre Java era l’ideale per la codifica e la comunicazione.
L’avvento dei Web service, abbinato all’annuncio di .Net con enfasi sul messaging Xml (Biztalk), ha apparentemente messo Sun ai margini.
L’attuale atteggiamento di Sun e della comunità Java verso i Web service è riassunto nelle Java Specification Request (Jsr) 101, Api Java per Rpc basato su Xml (Jax-Rpc).
Esistono già due principali sistemi Rpc nella piattaforma Java, Omg Corba e Java Rmi. Senza dimenticare la specifica Rmi-Iiop, volta a fornire un’unificazione parziale di Corba e Rmi, che si è scontrata contro la difficoltà di mappare la semantica di un linguaggio e quella di un protocollo di rete.
La specifica correlata ai Web service fatta all’interno di J2Ee 1.3 è costituita dalle vecchie Api Java per Xml Parsing (Jamp), che permettono ai programmatori di tradurre i documenti Xml usando sia Dom sia parser Sax. Le Api Java per Xml Registry (Jaxr) dovrebbero essere integrate in J2Ee versione 1.4.
Ciò conferirebbe il vantaggio di lavorare ugualmente bene con Uddi ed ebXml Registry, dal momento che gli sviluppatori vogliono avere tool separati per supportare i due standard. Alla fine, J2Ee 1.4 includerà Soap with attachment api for Java (Saaj), che supporta allegati binari come parte di messaggi Soap. Saaj viene spesso usato in congiunzione con le Api Java per Xml messaging (Jaxm) che però non sono menzionate nell’ultimo draft di J2Ee 1.4.
Dal momento che i Web service sono ritenuti validi, in quanto nascondono la complessità di Java, i membri del Java community process (Jcp) tendono a vedere le Api quali Jax-Rpc e Jaxr come una salvezza per tutti quegli sviluppatori che non intendono diventare esperti di Xml.
Jsr 109 Web Service per J2Ee (in precedenza chiamato Implementing Enterprise Web Service) è visto da alcune delle più importanti specifiche Java per Web service. Questo riunisce specifiche rilevanti (come per esempio Jax-Rpc) e descrive come queste devono essere usate per supportare i Web service sotto J2Ee.
