Mobile computing non significa solamente realizzare applicazioni che possano essere eseguite all'interno di un palmare o di un telefono cellulare. E' fondamentale anche definire l'accesso a risorse di business logic remota. In Java si tratta di realizzare una interconnessione fra le tecnologie J2EE e J2ME. XML ed HTTP sono i candidati migliori per interconnettere le due piattaforme: in una parola Web Services.

Introduzione ai Web Services
Come spesso accade, una tecnologia è figlia di una necessità. L'inizio del nuovo millennio è sicuramente caratterizzato dall'ingresso di Internet nella vita di ciascuno di noi. Le persone che non utilizzano questo nuovo strumento o che non dispongono di almeno un indirizzo di posta elettronica sono davvero poche. Non esiste azienda che non abbiamo un proprio indirizzo www. Al boom di questo fenomeno culturale si è associata una esplosione di tecnologie per la realizzazione di quelle che si chiamano applicazioni Web. Dall'utilizzo di semplici applicazioni attraverso una interfaccia CGI (Common Gateway Interface) e linguaggi come il C/C++ si è passati all'utilizzo di linguaggi interpretati come PHP e PERL per poi arrivare al concetto di application server come ambiente per la realizzazione di applicazioni enterprise scalabili e di elevate prestazioni. Ecco che tecnologie come Java e .Net si sono affermate come principali scelte nella realizzazione di applicazioni web di notevoli dimensioni. Conseguenza di questo fermento è stato comunque la realizzazione di moltissime applicazioni realizzate con tecnologie molto diverse tra loro in ambienti e sistemi operativi differenti.

Inizialmente le necessità delle aziende era comunque quella di realizzare applicazioni denominate B2C (Business to Consumer) e che avevano come ultimo utilizzatore l'utente che, da casa o dall'ufficio, accede, attraverso una connessione telefonica o attraverso rete aziendale, a servizi di vario genere. Successivamente è nata invece la necessità, da parte delle diverse aziende, di comunicare tra loro, di effettuare quello che si chiama B2B (Business to Business). Il rivenditore deve quindi comunicare con il fornitore per ordinare i prodotti del proprio catalogo. Nel caso di più fornitori, il rivenditore potrebbe avere la necessità di conoscere quale di questi siano per lui più conveniente. Ma come fare per semplificare la comunicazione tra i due sistemi informativi? Come si potrebbe procedere nel caso in cui le tecnologie e sistemi utilizzati siano molto differenti tra loro? La risposta è molto più semplice di quello che sembra ed è legata alla parola "standard".

HTTP ed XML come standard di comunicazione
In effetti una applicazione Web, qualunque sia la tecnologia utilizzata, ha come caratteristica fondamentale quella di pubblicare delle informazioni in formato testuale attraverso un protocollo request/reply che si chiama HTTP (HyperText Transport Protocol). Il browser compone una richiesta HTTP in grado di incapsulare alcune informazioni nella modalità previste dal protocollo e di inviarle ad un server il quale elabora le informazioni e ritorna un risultato incapsulato all'interno di una risposta HTTP. Come detto, solitamente il risultato è un documento HTML. Ma se l'interazione con una qualunque applicazione Web avviene attraverso il protocollo HTTP perché non pensare ad un meccanismo che utilizzi lo stesso protocollo per far comunicare Web Application diverse? L'utilizzo del protocollo HTTP è possibile con una applicazione Web realizzata in Java, con una realizzata in .Net, con PHP o PERL. Lo sarebbe addirittura con una applicazione che utilizza la CGI. Ovviamente la comunicazione non può avvenire attraverso documenti HTML i quali hanno la caratteristica di descrivere sia un insieme di informazioni che la modalità con cui le stesse vengono presentate graficamente. Al nostro amico rivenditore interessano solamente i dati puri e strutturati, relativi ai diversi prodotti. Sarà il proprio sistema che avrà eventualmente la responsabilità di gestire eventualmente la presentazione dei prodotti acquistati. Nasce quindi l'esigenza di un modo standard per il trasporto dei dati. Da qui all'utilizzo di documenti XML il passo è breve. Attraverso un documento XML è quindi possibile descrivere un insieme di informazioni strutturate che possono essere trasmesse attraverso un protocollo di trasporto come può essere l'HTTP. Un documento XML ha infatti la fondamentale caratteristica di essere del "semplice testo" le cui informazioni possono essere estratte con gli strumenti ormai disponibili per tutti i linguaggi. L'operazione di estrazione delle informazioni contenute all'interno di un documento XML si chiama parsing e viene effettuata da alcuni componenti, di diverso tipo, che prendono il nome di parser a cui accenneremo successivamente.

HTTP ed XML sono sufficienti?
Abbiamo quindi visto come l'utilizzo di HTTP ed XML come protocolli di trasporto e di rappresentazione dei dati ci permetta di risolvere i problemi legati alla interoperabilità tra sistemi che utilizzano ambienti e tecnologie molto diverse tra loro. Manca comunque ancora qualcosa di importante. Utilizzare l'HTTP e l'XML per la comunicazione è forse troppo generico. Nel nostro scenario è necessario che il rivenditore ed il produttore parlino la stessa lingua e quindi che le informazioni contenute all'interno del documento XML inviato dal produttore siano comprese nel modo corretto da parte del rivenditore. Attorno quindi alla realizzazione di documenti XML serve un meccanismo che permetta alle diverse parti di concordare il formato da utilizzare per la rappresentazione delle informazioni e quindi permetta di descrivere alcune regole cui lo stesso documento dovrà sottostare per essere considerato valido. A tale scopo sono state realizzate diverse tecnologie. Quella denominata DTD (Data Type Definition) è stata probabilmente la prima tecnologia utilizzata a tale scopo. Attualmente si parla di XML Schema, di Relax NG ed altre come di metodi per descrivere un insieme di documenti XML che soddisfano un dato insieme di regole. Ecco che quando due sistemi devono comunicare tra loro devono accordarsi sulla lingua e quindi sulle regole che i documenti XML scambiati devono soddisfare. Un documento XML che non soddisfa a queste regole dovrà quindi essere scartato.

SOA - Service Oriented Architecture
Supponiamo ora che il fornitore abbia la necessità di rendere disponibili le informazioni relative ai propri prodotti non solo al nostro rivenditore ma anche ad altri. Viceversa supponiamo che il rivenditore non voglia comprare tutto dallo stesso fornitore ma abbia la necessità di confrontare i prezzi con quelli di altri fornitori magari più convenienti. Possiamo quindi pensare al fornitore come colui che mette a disposizione un servizio per la consultazione dei propri prodotti. Possiamo pensare al rivenditore come un utente che utilizza i servizi esposti dai diversi fornitori per determinare quello più conveniente. Se pensiamo ad uno scenario di questo tipo si intuisce la necessità di alcuni servizi di supporto che permettano al rivenditore di:

• individuare i servizi messi a disposizione dai diversi fornitori per la consultazione delle informazioni di catalogo
• concordare con ciascun fornitore da consultare la modalità di accesso al servizio
• invocare il servizio passando dei parametri in input ottenendo delle informazioni in output

Analogamente al fornitore serviranno degli strumenti che permettano di:

• descrivere il proprio servizio
• descrivere le modalità di accesso allo stesso
• informare i diversi rivenditori della disponibilità del proprio servizio

Dopo quanto detto in precedenza è scontato che le tecnologie che ci permettono di raggiungere questi scopi si basino sull'utilizzo di particolari applicazioni XML che quindi soddisfano determinate regole questa volta standardizzate. Si parla quindi di:

• SOAP (Simple Object Access Protocol) per l'interrogazione dei servizi
• UDDI (Universal Description Discovery and Integration) per la registrazione ed individuazione del servizio
• WSDL (Web Services Description Language) per la descrizione dei servizi e delle modalità di accesso

La realizzazione di quanto descritto nello scenario iniziale è rappresentata da SOAP ovvero un protocollo standard, basato sull'XML, per lo scambio di informazioni in un ambiente distribuito e decentralizzato. Senza entrare nello specifico del protocollo possiamo dire che SOAP permette la definizione di un framework per la descrizione delle informazioni contenute all'interno di un particolare messaggio e di quali siano le modalità di elaborazione delle stesse. A tale scopo SOAP definisce alcune regole di decodifica dei diversi tipi di dato ed alcune convenzioni per la rappresentazione delle richieste e delle risposte secondo il paradigma RPC (Remote Procedure Call) che non è altro che un modo per accedere, in modo trasparente, a servizi remoti come si trattasse di servizi locali. Ricordiamo che nel caso di Java due servizi si considerano remoti se in esecuzione in istanze di JVM diverse. Nel caso di Web Service, possiamo dire che due servizi sono remoti se la loro comunicazione avviene attraverso HTTP o altro protocollo di supporto.
Un fornitore che deve pubblicare il proprio servizio dovrà quindi come prima cosa descriverlo attraverso un documento WSDL e quindi pubblicarlo attraverso UDDI in un contenitore di servizi che prende il nome di UDDI repository. Per semplificare l'individuazione del servizio lo stesso dovrà essere organizzato per categorie. Un rivenditore dovrà invece utilizzare i servizi UDDI per cercare, in base ad alcuni criteri di ricerca, l'insieme dei servizi a cui è interessato. Di questi ne otterrà quindi una descrizione attraverso il relativo documento WSDL che descriverà quindi le modalità di accesso attraverso gli strumenti SOAP.
Si è quindi realizzata una architettura orientata ai servizi che basandosi su tecnologie e protocolli standard permette l'interoperabilità tra sistemi con caratteristiche anche molto diverse tra loro.

Un esempio concreto
Per chiarire alcuni degli aspetti del paragrafo precedente supponiamo di avere la necessità di utilizzare un particolare servizio di cui conosciamo solamente gli aspetti funzionali. Supponiamo, ad esempio, di avere la necessità di un servizio che ci permetta di sapere se un determinato indirizzo di posta elettrica esiste o meno. Il primo passo da fare è quello di cercare il servizio che fa a caso nostro. Per fare questo è quindi possibile accedere ad uno dei repository disponibili nel Web attraverso le loro interfacce oppure accedere attraverso UDDI ad un repository compatibile con questo protocollo. Scegliamo la prima strada accedendo al sito http://www.xmethods.net/ e verificando la presenza di un servizio che fa al caso nostro leggendone la documentazione a supporto. Sebbene esista una tecnologia come l'UDDI non è così insolito che la ricerca di un particolare servizio avvenga in modo diverso come nel nostro caso.
Una volta individuato il servizio che fa al caso nostro, abbiamo bisogno di conoscere quelle che sono le modalità di accesso al servizio stesso. Questo significa che abbiamo bisogno di conoscere il nome della procedura da invocare, i parametri di ingresso e quelli di uscita. Avremo inoltre bisogno di conoscere l'URL a cui accedere. Tutte queste informazioni sono descritte attraverso un documento XML che prende il nome di Web Service Descriptor Language (WSDL). Dal WSDL esistono quindi molti strumenti che, in diversi ambienti, permettono la generazione automatica di quelle che sono le classi per l'invocazione del servizio. Ecco che a partire dal WSDL del servizio, attraverso uno dei tool disponibili a tale scopo, è possibile creare le API da utilizzare per poter invocare una particolare procedura esportata da un Web Service allo stesso modo con cui è possibile invocare l'esecuzione di un normale metodo di un qualunque istanza. Gli oggetti di questo tipo vengono chiamati Stub.
Quello descritto non è comunque un procedimento nuovo. L'utilizzo della tecnologia CORBA (Common Object Request Broker Architecture) prevede infatti la descrizione di un insieme di servizi con un linguaggio IDL (Interface Description Language) da cui generare, con appositi tool, i corrispondenti Stub per poterli invocare. Esiste inoltre un servizio simile a quello messo a disposizione dal protocollo UDDI per l'individuazione di servizi in modo dinamico.

I Parser XML
Da quanto detto in precedenza si intuisce come tutta l'architettura descritta si basi sulla possibilità di poter eseguire operazioni di parsing in ognuno degli ambienti in comunicazione tra loro. A tale proposito, per ciascuna tecnologia, sono disponibili diverse tipologie di parsing che possiamo classificare in:

• SAX (Simple Api for XML)
• DOM (Document Object Model)
• Pull Parser

Un parser SAX legge ciascun carattere di un documento XML generando un evento in corrispondenza di determinate informazioni quali l'inizio e la fine di un documento, l'inizio e la fine di un elemento, l'individuazione di un attributo ed altre ancora. Gli eventi generati da un parser SAX dovranno quindi essere ricevuti da quello che si chiama Handler e che implementa, come vedremo nei capitoli successivi, opportune interfacce in base alla tipologia di informazioni a cui lo stesso è interessato. Questa trilogia di parser XML è solitamente molto veloce e snella anche se la creazione dei diversi handler è spesso difficoltosa.
Un parser DOM permette invece di parserizzare un documento XML creandone una rappresentazione in memoria secondo una struttura ad albero caratteristica appunto dello standard DOM. Questa tipologia di parser, che utilizza di solito al proprio interno un parser SAX, permette una più semplice elaborazione delle informazioni contenute al prezzo di una maggiore quantità di memoria richiesta. Nel caso di documenti di grandi dimensioni l'utilizzo di un parser di questo tipo potrebbe essere problematico.
Una ultima tipologia di parser XML a cui accenniamo è quella denominata Poll. Si tratta di un parser con caratteristiche simili a quelle di un parser SAX con la fondamentale differenza che ora non si ha una generazione di evento successiva di una scansione del documento XML ma un posizionamento nel documento a seguito della esecuzione di un esplicito metodo. Conquesta tipologia di parser è quindi possibile gestire il posizionamento all'elemento o attributo successivo, gestirne il valore per poi proseguire. Questa tipologia di parser è solitamente più semplice da utilizzare rispetto ad un parser SAX ed ha la fondamentale caratteristica di essere spesso di minori dimensioni rendendosi adatto per sistemi a risorse limitate come quelli in grado di ospitare un ambiente J2ME.

Web Services e J2ME
A questo punto potremmo chiederci quale sia il rapporto tra un Web Service ed una applicazione in esecuzione in un ambiente J2ME. Sebbene tutto sia possibile, è abbastanza difficile che il ruolo di una applicazione J2ME sia quello di server ovvero di sistema in grado di rendere disponibile un servizio con la tecnologia descritta in precedenza. Questo perché le risorse necessarie alla implementazione di un server sono mediamente maggiori di quelle necessarie all'esecuzione di un client per lo stesso servizio. Per questo motivo è iniziata la standardizzazione di quelli che sono gli strumenti che un sistema J2ME può utilizzare per l'invocazione di Web Services, raccolta sotto il nome di JSR-175 Web Services on J2ME Platform e che vedremo nel dettaglio nel prossimo articolo. Fin da subito possiamo comunque intuire come le API descritte in queste specifiche saranno un sottoinsieme di quelle definite nell'ambiente J2SE come nel caso di altre API. Valuteremo quindi le motivazioni che hanno portato all'esclusione di alcune funzionalità in un ambiente J2ME per definizione dotato di risorse limitate.

Conclusioni
In questo primo articolo abbiamo visto quelle che sono state le principali motivazioni che hanno portato alla definizione di un architettura SOA per favorire l'interoperabilità tra sistemi realizzati con tecnologie molto diverse tra loro in ambienti eterogenei. Abbiamo quindi visto come una architettura di questo tipo si basi su tecnologia come SOAP, UDDI e WSDL particolari applicazioni XML standardizzate dal W3C. Abbiamo quindi concluso con un accenno all'utilizzo dei Web Service in un ambiente J2ME accennando a quelle che sono le API descritte dalle JSR-172 argomenti dei prossimi articoli.