|
Introduzione
Le JAXR (Java API for XML Registries) completano, insieme
a JAXM (Java API for XML Messaging) e JAX-RPC (Java
API for XML RPC), il supporto della piattaforma Java
alle tecnologie dei Web Services. Come per molte altre
tecnologie Java, che cercano di essere il più
generico possibile, le JAXR consentono non solo l'accesso
a registri UDDI ma anche ad altre tipologie di registri
di servizi, come ad esempio ebXML.
Nel definire le specifiche JAXR sono stati tenuti in
considerazione alcuni importanti obiettivi, tra cui:
-
definire una API che fosse l'unione delle migliori
caratteristiche delle principali specifiche per registri
di servizi web;
- assicurare
il supporto alle specifiche dominanti come UDDI ed
ebXML;
- assicurare
la sinergia con le altre tecnologie Java legate ad
XML.
Sicuramente,
l'obbiettivo di assicurare il supporto UDDI é
il primario scopo delle specifiche mentre il supporto
ad ebXML appare più un tentativo di diffondere
maggiormente quest'ultima tecnologia, inizialmente creata
da SUN ed ora in mano al consorzio OASIS.
Architettura
Una
implementazione JAXR é detta JAXR Provider e
può essere di livello 0 o livello 1. Questo indica
quali elementi sono supportati dall'implementazione.
Ad esempio, il supporto ad UDDI é di livello
0. Questo significa che qualsiasi prodotto che dichiari
la compatibilità a JAXR dovrà per forza
supportare l'accesso ad UDDI. Il supporto ebXML é
invece posto a livello 1, quindi i prodotti JAXR level
1 complaint supporteranno sia UDDI che ebXML.
Il supporto a diversi registri di Web Services avviene
tramite l'utilizzo di un modello informativo comune
ma estendibile che é stato mutuato dal modello
informativo di ebXML con aggiunte prelevate da UDDI.
Questo ha consentito di risparmiare il tempo necessario
a sviluppare un modello apposito e si traduce nelle
specifiche come pochissime pagine dedicate alla mappatura
di JAXR su ebXML.
In
figura 1 é possibile vedere l'architettura generale
di JAXR: un client utilizza sicuramente l'interfaccia
RS (RegistryService). Questa é sempre presente
e consente di ottenere informazioni sulla disponibilità
delle funzionalità per lo specifico prodotto,
come l'indicazione del livello di supporto dell'implementazione.
Figura
1 - Architettura JAXR
Le
altre interfacce (C?) supportano le varie funzionalità,
come la gestione del ciclo operativo e la gestione delle
query.
Gli altri elementi dell'architettura sono il codice
comune a tutti i registri, contenuto in "JAXR Pluggable
Provider", e i componenti di accesso agli specifici
registri ebXML, UDDI o altri.
L'implementazione delle API JAXR sono racchiuse in due
package:
-
javax.xml.registry.infomodel che contiene le interfacce
per modellare le informazioni supportate da JAXR,
come pure la loro interrelazione;
- javax.xml.registry
contiene la definizione dell'interfaccia di accesso
al registro.
Entità
e classificazioni
Le specifiche JAXR definiscono una serie di entità
che costituiscono il modello informativo su cui questo
si basa. Come detto, queste sono entità presenti
nel modello ebXML (anche i nomi sono sempre praticamente
identici), con aggiunte mutuate da UDDI. Le entità
principali sono:
-
Organization. Rappresenta una azienda, ad esempio
quella che ha inviato informazioni sui propri servizi
al registro. Può avere un riferimento alla
"capogruppo" per modellare eventuali gruppi
aziendali.
- Service.
E' il servizio offerto dall'azienda.
- ServiceBinding.
Sono le specifiche tecniche per l'accesso al servizio.
Un servizio può avere più binding;
- ClassificationScheme.
Rappresenta la tassonomia che può essere usata
per classificare o categorizzare altri elementi del
registro.
- Classification.
Utilizzato per classificare concretamente un elemento
del registro secondo uno specifico schema.
Attorno
a queste entità ne esistono altre che consentono
di collegarle tra di loro o di estendere il modello
informativo.
Una delle caratteristiche più interessanti dei
registri di Web Services, é infatti la possibilità
di catalogare i servizi e le aziende secondo diverse
tassonomie costruendo dunque un patrimonio informativo
che consente di effettuare ricerche più puntuali.
Ad esempio é possibile restringere la ricerca
ai soli venditori di libri online che operano sul territorio
italiano ma che magari hanno sede in Svizzera. JAXR
supporta due diverse tipologie di tassonomia: interna
ed esterna. Queste sono relative al registro: quando
una tassonomia é riconosciuta da quest'ultimo,
potrà essere utilizzata come interna. In alternativa
é possibile mischiare diverse tassonomie, o definirne
di nuove, e creare così tassonomie esterne. Solitamente
le tassonomie vengono definite da organismi nazionali
od internazionali, come nel caso di NAICS (American
Industry Classification System) - standard in uso nelle
nazioni dell'America del nord. Entrambe le tipologie
di tassonomie hanno vantaggi e svantaggi, ad esempio
le tassonomie esterne sono molto più indefinite
e difficile da gestire e manutenere, mentre quelle interne
sono predefinite e quindi forniscono un riferimento
più solido.
Quasi tutti gli elementi del modello informativo di
JAXR sono associabili tra di loro. Le associazioni non
hanno una tipologia fissa ma si basano sull'astrazione
di concetto, rappresentata nel modello informativo di
JAXR come Concept.
Un Concept, in JAXR, può rappresentare un qualsiasi
concetto e viene combinato con altri Concept per costruire
un alberatura che rappresenti una tassonomia. Azzardando
un collegamento con DOM, si può dire che Concept
di JAXR equivalga al Node di DOM. Con la differenza
semantica che il primo rappresenta un concetto (p.e.
l'Europa, l'Asia, la macchina o il pappagallo) mentre
il secondo rappresenta un elemento di un documento XML.
Accedere
ai registri
Come consuetudine nelle API Java, l'accesso alle informazioni
avviene tramite una connessione restituita da una factory
(altre API che utilizzano questo approccio sono JCA
- Java Connector Architecture e JAXM - Java API for
XML Messaging). La factory stessa può essere
recuperata da un riferimenti JNDI (Java Naming and Directory
Interface, ed é il metodo consigliato) o attraverso
la chiamata ConnectionFactory.newInstance(). In ogni
modo, prima di ottenere una connessione al registro,
é necessario impostare sulla factory ottenuta
alcune proprietà indispensabili come l'url del
registro a cui si desidera accedere.
Una volta ottenuta la connessione é possibile:
-
indicare se l'accesso al registro é sincrono
od asincrono. Nel caso di accesso sincrono, tutte
le chiamate alle API che prevedono l'interazione con
il registro risulteranno bloccanti per il thread chiamante.
In caso di accesso asincrono, la chiamata termina
subito, eventualmente restituendo un oggetto JAXRResponse.
Questa instanza non avrà ovviamente i dati
richiesti in quanto verranno caricati con una sorta
di Lazy-Loading (detto anche Futures Pattern), o all'atto
dell'effettiva interrogazione di un metodo di get,
oppure tramite un thread apposito.
- impostare
le credenziali dell'utente. Non é possibile
accedere ai registri quali UDDI o ebXML senza dichiarare
la propria identità: nei casi più semplici
(UDDI) di utilizza la coppia utente/password, ottenuta
tramite la registrazione presso il fornitore del servizio
(IBM, Microsoft); in casi più complessi é
possibile utilizzare certificati digitali X500 (in
ebXML). Sicuramente comunque tutte le implementazioni
JAXR possono fare uso di SSL e, nel caso di JAXR level
1, anche di crittare la comunicazione in quanto JAXR
é allineato a JAAS (Java Authentication and
Authorization Specification) e JSSE (Java Secure Sockets
Extensions).
Ma
cosa accade se in una applicazione é necessario
accedere a diversi registri, ad esempio, sia ad UDDI
che ad ebXML? JAXR consente di stabilire più
connessioni contemporanee a diversi registri e di "federare"
queste connessioni in una entità logica unica
in modo, ad esempio, di poter eseguire funzionalità
di ricerca su tutti i registri con una singola chiamata.
Sopratutto in questo caso, ma anche nel caso di singole
connessioni, é importante, al termine delle operazioni
con il registro, operare la chiusura della connessione.
Questa alloca un numero significativo di risorse, quali
connessioni di rete e thread che devono essere rilasciate
al più presto per non compromettere le prestazioni.
Gestione
del registro
Le JAXR consentono, ovviamente, la gestione delle informazioni
presenti nel registro, come la creazione, l'aggiornamento
e l'eliminazione di elementi. Inoltre é supportata
l'interrogazione del registro per eseguire le ricerche
di servizi ed aziende.
Ciascun elemento del registro é individuato univocamente
da una UUID conforme al DCE 128 bit. Questa chiave é
solitamente creata in modo trasparente dal registro
anche se per alcuni registri (come ebXML) é possibile
fornire dall'esterno la chiave da utilizzare.
Il ciclo di vita degli oggetti del registro inizia con
l'operazione di creazione (l'interfaccia LifeCycleManager
fornisce una serie di metodi di utilità per creare
i differenti oggetti definiti nel modello informativo).
Un oggetto creato non é ancora presente all'interno
del registro e non può dunque essere oggetto
di aggiornamenti o cancellazioni. Per inserire l'oggetto
nel registro é necessario che questo passi attraverso
un'operazione di salvataggio (save).
Una caratteristica interessante di JAXR é la
possibilità di deprecare gli oggetti, con un
concetto simile al tag @deprecated di Javadoc. Gli oggetti
deprecati non consentono nuove referenze (come associazioni
o classificazioni), ma continuano a funzionare normalmente.
Se da una parte l'interfaccia LifeCycleManager consente
di gestire tutti gli elementi ad alto e basso livello
del registro, può essere necessario concentrarsi
più su elementi di business. L'interfaccia BusinessLifeCycleManager
é contiene alcune importanti chiamate ad alto
livello definendo una API simile alle Publisher API
di UDDI. Con questa interfaccia non vengono introdotte
nuove funzionalità ma viene allungata una mano
agli sviluppatori UDDI che dovrebbero trovarsi ad operare
con API più familiari. Un limite di JAXR in questa
versione é che le operazioni sul ciclo di vita
degli oggetti non sono applicabili a federazioni di
connessioni. Non é, ad esempio possibile, creare
la stessa entità direttamente in due registri
differenti.
Interrogazione
del registro
A differenza delle operazioni "dispositive"
(come la creazione o la modifica di informazioni), le
operazioni di ricerca avvengono in modo non privilegiato.
Non é necessaria dunque l'autenticazione dell'utente.
L'interrogazione può avvenire in modo puntuale
o tramite query. Nel primo caso viene utilizzata l'interfaccia
BusinessQueryManager che, in modo similare a BusinessLifeCycleManager,
ha una impostazione più ad alto livello e permette
l'interrogazione delle interfacce più funzionali
del modello informativo.
Molti metodi dell'interfaccia richiedono argomenti simili,
alcuni tra i più importanti sono:
-
findQualifiers. Definiscono le regole di confronto
di stringhe, ordinamento e operatori logici sui parametri
di ricerca.
- namePatterns.
E' una Collection di stringhe che contengono nomi,
anche parziali con eventuali wildcard come specificato
nelle SQL-92 per la parola chiave LIKE.
-
classifications. E' una Collection di Classification
che identifica in quali classificazioni eseguire la
ricerca.
Nel
secondo caso é possibile utilizzare una query
dichiarativa, tramite l'interfaccia DeclarativeQueryManager.
Ad oggi l'unico standard supportato é una derivazione
di SQL-92, in particolare dell'istruzione SELECT, estese
con le specifiche relative alle stored procedures.
Le query dichiarative sono supportate anche su connessioni
federate ma sono una caratteristica opzionale dei provider
JAXR 1.0.
Conclusioni
Con JAXR non é più tanto importante dove
risiedano le informazioni, se in registri UDDI o registri
ebXML, in quanto dal punto di vista dello sviluppatore
la cosa é trasparente. Diventa più importante,
ai fini del successo della visione dei Web Services,
che il registro mondiale dei servizi - qualunque sia
- sia completo e con informazioni consistenti e corrette,
una cosa a tutt'oggi estremamente difficile. Come riportato
anche nelle specifiche JAXR, una ricerca congiunta condotta
da SalCentral e WebServicesArchitect ([4]) ha individuato
che quasi il 48% degli URL nel registro UDDI non sono
validi, rappresentando un'ostacolo concreto alla piena
realizzazione della visione dei Web Services.
Bibliografia
[1] Consorzio UDDI - http:/www.uddi.org
[2] Massimiliano Bigatti - "Web Services (3) -
la tecnologia UDDI", Mokabyte, Luglio 2001
[3] Specifiche "Java API for XML Registries (JAXR)",
versione 0.75
[4] http://www.webservicesarchitect.com/content/articles/clark04.asp
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 del portale www.javawebservices.it
|
