Introduzione
Dopo una pausa di qualche mese torniamo a parlare di Web Services e Java addentrandoci nelle problematiche che più interessano la tecnologia quando si deve incontrare con le esigenze di business di un'azienda.
In diversi articoli precedenti (si veda [1], [2] e [3]) abbiamo affrontato le tecnologie che stanno alla base dei Web Services e cioé SOAP, WSDL ed UDDI. Una volta in possesso delle conoscenze di base é utile fare qualche considerazione per porre queste tecnologie nella giusta ottica.

• RMI (Remote Method Invocation), consente la creazione di applicazioni distribuite: programmi che distribuiscano il carico elaborativo su computer diversi. Le specifiche SOAP forniscono un supporto basilare per applicazioni distribuite, ed infatti includono standard per la creazione di RPC (Remote Procedure Call) - SOAP-RPC.
  
  
• RMI ha alcune caratteristiche che lo rendono una scelta migliore di SOAP-RPC per le applicazioni distribuite: semplicità (trattare dati XML é più complesso che utilizzare RMI - senza contare la necessità di scrivere codice di gestione del protocollo SOAP-RPC), garbage collection distribuita, sicurezza, object orientation.
  In SOAP-RPC la mancanza di questi elementi è una specifica scelta di design: i progettisti hanno voluto mantenere semplici le specifiche, questo ha però portato a produrre una tecnologia procedurale e non ad oggetti.
  Una nuova API SUN che potrebbe cambiare di poco lo scenario é JAX-RPC (Java API for XML RPC). Questa tecnologia vuole fornire meccanismi di RPC su XML basati su SOAP o XML-RPC. Una volta completata risolverà il problema della "semplicità" di gestione, anche se le problematiche relative all'object orientation rimarranno irrisolte.
  
  
• SQL (Structured Query Language). Questo standard affermato consente, insieme ad altre cose, l'interrogazione di una base dati. Sebbene sia possibile ad oggi interfacciare alcuni database tramite XML (o SOAP) - come SQL Server od Oracle - anche in questo caso l'utilizzo di XML impone un overhead maggiore rispetto a JDBC (Java Database Connectivity - lo standard che viene utilizzato nella piattaforma Java per interfacciare il database). Nel momento che una query su database (oppure una stored procedure) venisse interfacciata, ad esempio, tramite SOAP, questa diverrebbe una "chiamata a Web Services" in quanto SOAP fungerebbe da disaccoppiatore e "componentizzatore" di interrogazioni.
  Questo può avere senso se l'interrogazione avviene dall'esterno dell'applicazione, il discorso cambia se l'interrogazione é interna all'applicazione Java: in questo caso potrebbe non avere senso sovraccaricare il sistema con strati di comunicazione SOAP ed il relativo costo di elaborazione dei dati XML.
  
  
• Solitamente i Web Services che utilizzano HTTP per la comunicazione vengono realizzati tramite Servlet. E' la scelta più ovvia per la piattaforma Java e diversi toolkit (Apache SOAP, JAXB) utilizzano questa tecnologia come base per la comunicazione. La Servlet, però, agisce da componente di "facciata" e solitamente si occupa poi di richiamare il vero oggetto di business che può essere implementato in due modi: (1) nello stesso processo come classe Java; (2) in processi separati tramite RMI, CORBA o anche SOAP.

Anche per quanto riguarda i componenti (o servizi - che in questo contesto sono componenti richiamabili da altri processi) la piattaforma Java dispone di uno standard abbastanza affermato e diffuso: gli EJB (Enterprise Java Beans). Come per la comunicazione con il database all'interno dell'applicazione può venire utilizzato JDBC, anche per i componenti di business interni potrebbe essere utilizzato EJB. Anche in questo caso, stabilità, semplicità, minor costo computazionale sono elementi che giocano a favore di EJB.

Valutare e selezionare
Una cosa deve essere chiara: i Web Services sono un concetto, non (ancora, completamente) una tecnologia. L'idea di base é che ambienti eterogenei si scambino informazioni in formato XML, usando come trasporto tecnologie Internet (HTTP, ma anche FTP, SMTP). Non é dunque "obbligatorio" utilizzare tutte le tecnologie sfornate dai vari enti e produttori: SOAP, WSDL, UDDI, WSEL (Web Services Experience Language), RosettaNet.
Un'applicazione può dirsi abilitata ai Web Services se utilizza le tecnologie necessarie al posto giusto.
Ad esempio, non é indispensabile abilitare ai WSDL la propria applicazione, se si conosce a priori che la tipologia di servizio interfacciato non cambierà. Può essere sufficiente fornire i WSDL dei servizi che invece espone la nostra applicazione. Questo approccio consente di ridurre i tempi di sviluppo in quanto non si necessita di un "motore" per la gestione dei WSDL.
Anche l'interfacciamento dei diversi sistemi può avvenire tramite registri UDDI, ma questa opzione ha senso in specifici contesti, ad esempio, se l'applicazione é destinata ad un numero elevato di fornitori di servizi.
Ed esempio: poniamo il caso di un software di integrazione del mainframe per una grande azienda (con applicazioni Java e native Windows). In merito a questo scenario possiamo fare una serie di considerazioni:

• i due diversi ambienti di fruizione dell'host (Java e Windows) richiederebbero modalità di accesso diverse: una Java ed una Windows (magari DCOM);
• i programmi Host da interfacciare saranno molto probabilmente scritti in COBOL, o comunque procedurali;

In base a questi elementi si può dire che la problematica di base é un RPC e gli ambienti client sono eterogenei. In questo caso RMI e DCOM sono le soluzioni meno indicate, in quanto proprietarie delle singole piattaforme. Le alternative potrebbero dunque essere CORBA e SOAP-RPC: ma sebbene il primo sia particolarmente complesso, il secondo invece é di facile implementazione e sfrutta infrastrutture molto probabilmente già esistenti (Web Server).
Seconda valutazione: WSDL. Introdurre WSDL in questo scenario significa introdurre un ulteriore livello di indirezione tra la piattaforma di integrazione e le applicazioni. Questo potrebbe non essere necessario in quanto l'astrazione dal servizio potrebbe essere già stata implementata nelle singole applicazioni (nel caso di legacy). Anche un registro UDDI interno potrebbe non essere utile in quanto solitamente esiste sempre e solo un servizio per svolgere un ben determinato compito (ad esempio per l'accesso alle informazioni anagrafiche). In questo caso le caratteristiche di UDDI (che semplificando possiamo considerare un registro di servizi web) possono non essere indispensabili: ad esempio si saprà sempre a priori che il servizio anagrafico sarà unico, si chiamerà Anag ed sarà disponibile sull'host morpheus.
E' necessario dunque valutare sempre l'opportunità di abbracciare un nuovo standard sopratutto se questo é ancora in fase di sviluppo come quelli alla base dei Web Services.

Valutare tramite i test
Per compiere una corretta valutazione é comunque necessario implementare una sorta di test bed per la propria applicazione. Non é conveniente assumere in fase di progettazione l'utilizzo di tecnologie non sperimentate. Il gruppo di sviluppo deve avere una buona conoscenza della tecnologia che dovrà utilizzare perché ogni nuovo elemento può diventare facilmente un elemento di criticità e comportare ritardi e problemi prestazionali. Se le risorse lo consentono, é sempre meglio iniziare con un progetto pilota, non essenziale per il business, che abbia il solo scopo di formare gli sviluppatori (e l'azienda) sulla tecnologia e sulle problematiche che ci girano intorno. Se le risorse non lo consentono, é consigliabile sviluppare il nuovo progetto con le tecnologie che meglio si conoscono.
Questa cautela può trasformarsi in modo più o meno marcato in un limitato avanzamento della tecnologia utilizzata dalle applicazioni. Sebbene questo possa sembrare limitante é necessario tenere sempre presente che in ogni progetto é bene perseguire per prima cosa la fattibilità, il contenimento dei costi nel budget e la completezza della soluzione a fronte delle funzioni richieste e solo in secondo luogo l'utilizzo di tecnologie innovative.

Seguire (quasi) sempre gli standard
Una regola molto diffusa ed importante é quella di seguire gli standard dettati da organismi indipendenti (o importanti società, come SUN). I vantaggi che questa linea d'azione possono comportare sono l'interoperabilità dei sistemi, la disponibilità di strumenti, lo scambio di informazioni nella comunità degli sviluppatori. Attenzione però: é importante valutare (magari tramite gli spunti suggeriti sopra) quando e quali standard adottare: SOAP, WSDL ed UDDI sono standard abbastanza affermati, ma che dire della pletora di standard che sta producendo IBM per i Web Services (WSEL, altro)?
Adottare standard nuovi prodotti da singole società può essere svantaggioso in quanto non c'é garanzia che lo standard venga universalmente accettato. Inoltre, se lo standard non é aperto, ci si lega ai prodotti e strumenti dello specifico produttore avvantaggiandolo e facendo i suoi interessi invece che i propri (vedi Microsoft e la piattaforma Windows).
Se da una parte gli standard pubblicati hanno una serie di vantaggi, anche le soluzioni home-grown (sviluppate in casa) ne hanno di altro tipo, ad esempio il completo controllo degli standard e dell'implementazione o la semplicità e focalizzazione sul problema specifico.
La regola generale potrebbe essere: utilizzare gli standard aperti e consolidati definiti dai consorzi ed enti indipendenti. Se questi non sono disponibili, acquistare prodotti di società commerciali o in alternativa, se il costo lo consente, produrli in casa.

Conclusioni
In conclusione: scegliere lo strumento giusto per il lavoro giusto, e che sia uno standard il più forte possibile. Sfruttare solo quelle parti dello standard che sono indispensabili per il problema da risolvere. Provare la soluzione sperimentandola e formando le risorse su di essa.
Questi sono alcuni spunti che possono aiutare il difficile e rischioso compito di affrontare lo sviluppo con tecnologie nuove come i Web Services.

Bibliografia
[1] Massimiliano Bigatti - "Web Services: SOAP e dintorni", Mokabyte, Mag 2001
[2] Massimiliano Bigatti - "Web Services II parte: capire i WSDL", Mokabyte, Giu 2001
[3] Massimiliano Bigatti - "Web Services III parte: la tecnologia UDDI", Mokabyte, Lug 2001
[4] Massimiliano Bigatti - "Web Services IV parte: lo stato dei WS nella piattaforma Java", Mokabyte, Set 2001

Massimiliano Bigatti é SUN Certified Enterprise Architect for Java Platform, Enterprise Edition Technology. Si occupa di architetture applicative basate su Java ed Internet, technical writing e musica rock.