Web Services
oggi
Mentre
il consorzio W3C sta lavorando sulla standardizzazione di SOAP (una bozza
delle specifiche di SOAP 1.2 è uscita qualche mese fa) e sulla definizione
del protocollo XMLP (XML Protocol), anche SUN sta lavorando per includere
nella piattaforma Java alcuni elementi dei Web Services.
Sicuramente
SOAP 1.2 ed XML Protocol saranno oggetti di prossimi articoli, dove entreremo
nel dettaglio delle singole specifiche, per ora è interessante notare
due particolari:
-
SOAP 1.2
non è molto diverso da SOAP 1.1. All’interno di Header e Body sono
stati inseriti suddivisioni, chiamati “block” di fatto rendendo più
modulari i messaggi SOAP. Un’altra modifica attesa è la variazione
dei namespace che ora riflettono l’indirizzo Internet del W3C (http://www.w3.org)
invece che quello di xmlsoap.org;
-
XML Protocol
non è un protocollo vero e proprio, ma un modello astratto di scambio
di messaggi XML. Contiene la definizione di concetti astratti che non definiscono
una implementazione ma sono aperti a realizzazioni differenti. Una di queste
sarà sicuramente SOAP 1.2. A differenza di SOAP, dunque, XMLP non
definisce strutture di messaggi e convenzioni per l’encoding.
Quest’ultimo
aspetto riveste una notevole importanza in questioni quali la compatibilità
dei sistemi. Ad esempio: se due sistemi implementano in modo diverso XML
Protocol ma entrambi rispettando il modello astratto, questi potranno essere
definiti correttamente implementazioni di XML Protocol, ma potranno scambiarsi
informazioni, visto che le implementazioni sono diverse?
La piattaforma
Java
SUN
sta utilizzando una certa cautela per quanto riguarda i Web Services (IBM/Microsoft)
anche perché, come accennato nei precedenti articoli, SUN è
tra i promotori di una iniziativa analoga, la ebXML. Sebbene ci sia una
certa antagonia tra WS e ebXML, SUN non vuole precludersi la tecnologia
di WS per non rimanere fuori dal mercato.
L’integrazione
di XML, tecnologia base dei WS e di ebXML, nella piattaforma Java come
sappiamo non è nativa, in quanto non esistono tipi di dati elementari
(primitive o classi di java.lang, come String) che supportano le informazioni
strutturate XML. È vero che in Java2 nel package java.util sono
presenti le classi del Collection Framework che contengono, tra le altre
cose, strutture ad albero, ma queste non sono adatte a contenere documenti
XML. D’altra parte le API del DOM non sono studiate per Java e forniscono
una modalità scomoda di accesso alle informazioni XML.
Un
insieme di API che potrebbe semplificare la manipolazione di informazioni
XML utilizzando la stessa eleganza delle classi Java native come String
o Hashtable è JDOM (http://www.jdom.org).
Questo
insieme di API espone elementi di un file XML come oggetti Java in modo
molto immediato implementando sostanzialmente un object model che rappresenta
un file XML.
Queste
API sono state accettate come JSR-102 (Java Specification Request) dal
JCP (Java Community Process), l’organismo che gestisce l’evoluzione di
Java e potranno in un futuro essere la base del supporto nativo di Java
per i documenti XML.
JDOM
affianca JAXP nel supporto di Java per XML. Come noto, JAXP è l’acronimo
di Java API for XML Parsing ed è un insieme di API per l’accesso
a parser XML. JAXP 1.1 contiene un parser di default sviluppato da SUN,
ma è possibile escluderlo ed utilizzarne un altro, ad esempio Xerces
dell’Apache Software Foundation (http://www.apache.org). Xerces è
un parser molto stabile ed evoluto e tra l’altro è free software.
Figura
1
Un
parser XML è un componente software che può essere interfacciato
tramite un pattern facade, un’interfaccia di dimensioni contenute che “nasconde”
all’utilizzatore le numerosi classi necessarie ad eseguire un compito così
complesso come l’interpretazione di documenti XML. Per questa sua natura,
il parser XML è un ottimo candidato al pattern facade ed infatti
la creazione delle API JAXP ha consentito, con bassi costi, la realizzazione
di applicazioni che possano fare il plug&play del parser (come per
tanti altri servizi nel mondo Java).
Figura
2
La
manipolazione di informazioni XML non è, come sappiamo, sufficiente
ad implementare il supporto ai Web Services. L’acronimo che risponde alla
necessità di comunicazione XML nella piattaforma Java è JAXM.
Comunicazione
XML indipendente dal trasporto
Le
classi di JAXM (Java API for XML Messaging) sono un insieme di API native
Java per la comunicazione (messagin) tramite XML. Le tre caratteristiche
chiave di JAXM sono:
-
impacchettamento
delle informazioni in XML;
-
instradamento
dei documenti XML;
-
trasporto;
Il trasporto
può avvenire su infrastruttre di comunicazione diverse, come:
Nota:
la cosa strana per JAXM (vista la X dell’acronimo) è che, stando
a quello che ha dichiarato SUN, dovrebbe gestire anche informazioni non
XML.
Le
codifiche supportate sono principalmente due:
-
SOAP 1.1
con attachment (ovviamente);
-
ebXML
transportation (altrettanto ovviamente).
La stessa
logica di facade utilizzata nelle API JAXP è stata implementata
in JAXM. Un’applicazione che parla in JAXM può accedere a protocolli
di comunicazione di varia natura (SOAP, ebXML, altri) ed a trasporti diversi
(HTTP, SMTP, etc.).
In
questo modo l’investimento nel codice è salvaguardato, come nel
caso di JAXP.
La
nota dolente riguardo a JAXM è che è attualmente in Early
Access, questo significa che è tutt’altro che pronta ed utilizzabile
in progetti reali. Nei prossimi mesi ci occuperemo più dettagliatamente
di JAXM e cercheremo di capire quando queste API potranno essere utilizzate
come base per progetti reali. Nel frattempo è possibile utilizzare
il toolkit di Apache [1] oppure realizzare un supporto personalizzato,
o ancora utilizzare uno dei tanti toolkit commerciali che stanno emergendo.
In tutti questi tre casi, purtroppo, il codice realizzato sarà fuori
standard.
Ulteriori
informazioni su JAXM sono disponibili sul sito di Javasoft all’indirizzo:
http://java.sun.com/xml/jaxm/index.html.
Una
limitazione di JAXM è l’impossibilità di combinare messaggi
XML in modo da realizzare schemi come richiesta/risposta, possibili con
SOAP e necessari per implementare un RPC (Remote Procedure Call). Questa
limitazion è di JAXM e non della piattaforma Java, infatti il supporto
ad RPC su XML è dato dalle API JAX-RPC.
Remote Procedure
Call su XML
JAX-RPC
(Java API for XML based RPC) è un insieme di API che fornisce allo
sviluppatore un modello astratto per la chiamata remota a procedure che
scambiano dati XML. SOAP 1.1 (con estensioni) ed XML Protocol saranno due
protocolli supportati da JAX-RPC. Attualmente queste API sono ancora in
fase di studio e recentemente approvate come JSR (http://jcp.org/jsr/detail/101.jsp).
Un
dubbio che sorge spontaneo pensando a JAX-RPC è il fatto che la
piattaforma Java già dispone di due standard per la chiamata remota
a procedure (anche se sarebbe meglio dire “ad oggetti”):
Le
ultime versioni di JDK (dalla 1.3) integrano inoltre una implementazione
(sviluppata da IBM) di RMI-IIOP, cioè una implementazione di RMI
che utilizza il protocollo di basso livello di CORBA. RMI-IIOP è
un tentativo di integrazione e convergenza tra RMI e CORBA.
Perché
dunque un ulteriore modalità di RPC? Come spiegato nel JSR, un obiettivo
sempre presente nello sviluppo della piattaforma Java è quello di
fornire allo sviluppatore il supporto necessario a sfruttare standard del
Web. E RPC su XML è sicuramente una parte importante di uno standard
emergente come SOAP.
La
speranza è che, almeno in un futuro, tutte queste API siano allineate
ad una unica modalità di programmazione distribuita.
UDDI … e non solo
Una
componente potenzialmente importante, soprattutto nei futuri Web Services,
sono i registri di servizi web. Come abbiamo visto nel precedente articolo
[2] UDDI è una iniziativa di IBM e Microsoft per l’implementazione
di questi registri. Come sappiamo ebXML è una iniziativa di SUN
che ha sviluppato anch’essa in questo senso. Come per SOAP, la necessità
della piattaforma Java è quella di supportare gli standard emergenti,
ma anche gli sforzi della “casa madre”. Per questo motivo, anche per l’accesso
a registri di servizi web è stata proposta un’estensione della piattaforma
Java che prende il nome di JAXR (Java API for XML Registries). Attualmente
anche questa tecnologia è in fase di studio, come JSR (http://jcp.org/jsr/detail/93.jsp).
Oltre a ebXML ed UDDI, queste API supporteranno altri due standard, OASIS
e eCo Framework.
Con
JAXR si conclude la rassegna delle API per il supporto ai Web Services
della piattaforma Java previste da SUN attualmente. Tutte queste tecnologie
sono riassunte in tabella 1.
|
TecnologiaJava
|
Corrispondenza WS
|
Stato
dell’arte
|
|
JAXM
|
SOAP
|
Early
Access
|
|
JAX-RPC
|
SOAP
RPC
|
Progettazione
|
|
JAXR
|
UDDI
|
Progettazione
|
Altro
XML…
Giusto
per concludere la panoramica del supporto ad XML della piattaforma Java,
vorrei citare le oramai consolidate JAXP (Java API for XML Processing),
già accennate sopra, che oramai giunte alla versione 1.1 includono
anche il supporto alle transformazioni XSLT, e le nuove API JAXB.
JAXB
è l’acronimo di Java Architecture for XML Binding. Queste sono un
insieme di API e strumenti per la creazione automatica di classi Java che
mappano direttamente documenti XML e viceversa. Quando non è necessario
elaborare a basso livello l’albero XML di un documento, è possibile
accedere alle sue informazioni non utilizzando JAXP, ma direttamente classi
Java generate con JAXB. Sicuramente questo strumento è un valido
aiuto alla realizzazione di applicazioni Java per XML. Attualmente JAXB
è in Early Access (http://developer.java.sun.com/developer/earlyAccess/xml/jaxb/).
Ulteriori informazioni al sito dedicato: http://java.sun.com/xml/jaxb/index.html
Conclusioni
Sicuramente
la comunità Java sta lavorando alacremente per integrare Java con
XML e le iniziative descritte in questo articolo ne sono la dimostrazione.
Ad oggi, purtroppo, solo JAXP è una API veramente stabile, tutte
le altre sono in versione Early Access o in fase di pianificazione. Sicuramente,
quando JAXM e JAX-RPC saranno disponibili, la realizzazione di server e
client per i Web Services sarà molto semplice … e si porrà
il problema della compatibilità tra i sistemi. Non sarà immediato
veder funzionare insieme le implementazioni di Microsoft, IBM, Apache e
SUN, occorrerà ancora del tempo. Il vantaggio del “JAX Pack” è
quello di consentire lo sviluppo di applicazioni che si basano su XML,
ma senza vincolare il prodotto ad una specifica implementazione. Se oggi
c’è SOAP, magari domani ci sarà XML Protocol. In entrambi
i casi un’applicazione realizzata con JAXM potrà sfruttare diverse
implementazioni di tipologie comuni di protocolli consentendo un risparmio
nei tempi di sviluppo per l’adattamento evolutivo dei programmi.
Per saperne di
più
Per
approfondire queste API, vi consiglio, a parte i siti dedicati a ciascuna
tecnologia e contenuti nell’articolo, i riferimenti [3] e [4]. La prima
è una feature di java.sun.com che tratta di tutte le tecnologie
“JAX”, la seconda è una whitepaper di SUN con ulteriori approfondimenti
più tecnici su tutte le API XML di Java.
Riferimenti
[1]
Andrea Giovannini - SOAP e Java Integrazione di applicazioni con Java e
il nuovo protocollo SOAP - http://www.mokabyte.it/2001/01/soap.htm
[2]
Massimiliano Bigatti – Web services III parte: la tecnologia UDDI - http://www.mokabyte.it/2001/07/webservices.htm
[3]
Javasoft – Creating Web Services with Java™ Technology and XML - http://java.sun.com/features/2001/05/jax.p.html
[4]
SUN – Web Services made esasier - http://java.sun.com/xml/webservices.pdf |
