Realizzare un web service in J2EE non è una procedura particolarmente complicata. Grazie alla presenza di tool che supportano questa operazione un web container come Tomcat può esporre in maniera piuttosto semplice un servizio sotto forma di web service.
Il funzionamento di un web service in ambiente J2EE è illustrato dalla figura che segue:
Focalizziamo l'attenzione sulla parte sinistra (lato server). L'implementazione del servizio è indipendente dal modo in cui esso verrà erogato, quindi potrà essere prevista semplicemente una classe java con relativi metodi. Il descrittore WSDL definisce in che modo si dovrà accedere alla classe che fornisce il servizio. Tutto quello che sta in mezzo (trasformazione del messaggio SOAP in comando java e viceversa) è a carico del middleware, che creerà l'opportuna infrastruttura.
Infatti, compito dello sviluppatore sarà: creare il servizio, definire il descrittore ed installare il tutto sulla macchina server.
Lato client, la procedura sarà analoga. Sarà sufficiente conoscere l'indirizzo del descrittore WSDL e costruire attorno ad esso i giusti messaggi SOAP (lo farà sempre uno strato di middleware).
Tralasciando la procedura di pubblicazione di un servizio, quello che serve alla creazione è la definizione della logica (anche una semplice classe), un descrittore WSDL e l'installazione su un web container predisposto a pubblicare web services. Il middleware si preoccuperà di configurare opportunamente il servizio per essere accessibile.
Come abbiamo detto in precedenza, anche una semplice classe java può essere sufficiente a definire un web service. Allora, che necessità c'è di scomodare l'architettura J2EE? La necessità risiede negli stessi motivi per cui utilizzare gli ejb: performance, scalabilità, sicurezza, affidabilità. Cose che una semplice classe java, da sola, non garantisce.
Per lo sviluppo di web service che rispondano direttamente dal container (strato web application) citiamo il progetto Apache Axis, che permette lo sviluppo di un web service a partire dal descrittore WSDL oppure a partire dalla logica definita in una classe. In pratica la logica del servizio risiede a livello di web application, quindi gestita dal container.
Lo sviluppo di web services su tecnologia J2EE è molto più interessante, proprio perché permette di avere a disposizione tutti i servizi offerti dall'application server. Degli strumenti di logica discussi nelle precedenti lezioni, quello che viene adibito ad essere il punto di logica applicativa di un web service è uno stateless session bean. È intuitivo comprendere il perché: una richiesta ad un web service è per sua natura una richiesta senza stato.
La creazione di web service con logica su stateless session bean garantisce un livello di performance eccellente, grazie alla gestione del ciclo di vita del componente tramite pooling. Inoltre, il bean può esporre determinati servizi facendo uso di altri ejb sviluppati dall'azienda.
In generale, il fatto di poter usufruire di tutti i servizi messi a disposizione dell'application server garantisce ottime performance al servizio creato. La gestione delle transazioni, l'eventuale accesso a sorgenti dati, le politiche di sicurezza, l'eventuale scalabilità, sono tutte caratteristiche curate dall'application server. In molti casi reali, soprattutto parlando di web services, acceduti da diverse organizzazioni distribuite geograficamente, questo è quanto meno necessario.
L'unico potenziale problema è legato al modo con il quale l'application server crea il middleware che gestisce lo scambio messaggi. In realtà, vista l'importanza dell'argomento, la stessa Sun ha promosso una serie di iniziative per definire degli standard sulla produzione dei web service. In particolare, la presenza del Java Web Services Developer Pack (JWSDP) permette la creazione di package indipendenti dalla piattaforma su cui verranno installati.
