Caratteristiche di UDDI
Il registro UDDI è supportato da una rete mondiale di nodi, collegati tra di loro in una sorta di federazione, in modo similare alla tecnologia DNS. Quando un client sottopone una informazione al registro, questo la propaga agli altri nodi. In questo modo si attua la ridondanza dei dati, fornendo una certa affidabilità. Il ruolo del singolo nodo rimane comunque fondamentale, poiché, nel momento in cui un client gli sottopone dei dati, questo ne diviene il proprietario, e sarà in futuro solo questo nodo a poter operare importanti operazioni sui dati, quali la loro eliminazione.
Le chiamate ad UDDI sono implementate tramite comunicazioni SOAP di tipo request-response e permettono sostanzialmente due operazioni: quella di pubblicazione delle informazioni e quelle di ricerca.
Le informazioni gestite dal registro UDDI sono di tre tipi:

• pagine bianche. Contengono informazioni anagrafiche delle aziende, come l'indirizzo ed i numeri di telefono. Costituiscono un primo approccio alle aziende, di tipo umano prima che tecnico;
• pagine gialle. Definiscono la categorizzazione (tassonomia) dei servizi e delle aziende. Un'aziende potrebbe essere infatti catalogata in base alla sua posizione geografica od al proprio settore industriale. Le tassonomie dovrebbero rispettare standard internazionali, quali quelli dettati da ISO;
  
• pagine verdi. Costituiscono le informazioni tecniche dei servizi, quelle utili a livello informatico. Queste riguardano URL dei servizi o gli eventuali documenti WSDL.

Purtroppo ad oggi non sembra che il registro UDDI contenga molte informazioni, e le poche presenti risultano nella maggioranza dei casi non valide. In attesa che le aziende superino i timori relativi allo spostare i propri servizi sul Web, la piattaforma Java ha predisposto una opportuna API per l'accesso a questo ed altri registri.

JAXR
L'accesso ai registri di servizi Web dalla piattaforma Java avviene tramite le Java API for XML Registries (JAXR). Si parla di registri in generale perché JAXR ha un'architettura multiregistro, capace di accedere anche ad altre tipologie di registry, come ebXML R. Inoltre JAXR può propagare una singola ricerca di servizi a più registri contemporaneamente.
L'accesso ai registri avviene tramite una connessione, ottenuta dalla classe ConnectionFactory, che viene opportunamente configurata tramite una serie di proprietà che indicano, tra le altre cose, l'URL del registro al quale si vuole accedere.
Una volta in possesso della connessione è possibile eseguire ricerche e sottomettere la registrazione di aziende e servizi. Quest'ultima operazione è però sottoposta ad autenticazione e per poterla portare a termine è necessario essere registrati presso il particolare registro a cui si vuole accedere.
Un aspetto interessante di JAXR è il suo uso del pattern futures (anche detto lazy-loading): una ricerca su un registro mondiale può potenzialmente restituire una grande mole di informazioni che non è garantito venga poi analizzata tutta. Per ovviare a questo inconveniente, ad ogni ricerca, gli oggetti creati da JAXR non contengono tutte le informazioni, ma solo quelle indispensabili. Nel momento si renda necessario ottenere quelle mancanti, il runtime di JAXR esegue l'accesso ai dati necessari. Questa caratteristica ha due aspetti: per prima cosa, vengono recuperati solo i dati effettivamente necessari, con un guadagno in termini di performance; in secondo luogo, i client JAXR devono per forza essere sempre connessi alla rete, in modo che i successivi caricamenti dati possano essere eseguiti correttamente.

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 l'interfaccia RS (RegistryService) per 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 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, tra cui quelle per la gestione della tassonomia.
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 può essere combinato con altri Concept per costruire un alberatura che rappresenti una tassonomia.

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.

Non solo SOAP/WSDL/UDDI
Sebbene questi siano gli standard consolidati per i servizi Web, non sono i soli. Prima di SOAP esisteva XML-RPC, uno standard più semplice per l'esecuzione di chiamate remote tramite XML su Internet. Un'altra iniziativa simile, promossa da OASIS, è ebXML (Electronic Business XML). L'obiettivo di SOAP/WSDL/UDDI è il medesimo di ebXML, ma con un approccio differente, se le tecnologie viste in questo capitolo hanno un approccio "dal basso" (a partire proprio dalla tecnologia), ebXML ha un approccio "dall'alto" - ovverossia dai requisiti funzionali. Sebbene i due mondi abbiano sviluppato fino ad ora in modo indipendente, si cominciano a notare elementi di convergenza: ebXML utilizza SOAP (esteso con header specifiche ed allegati) come protocollo di comunicazione ed il consorzio UDDI ha ceduto le specifiche della versione 3.0 al consorzio OASIS. Nell'interesse del successo della visione dei servizi Web, i due mondi, in un futuro non troppo remoto, potrebbero convergerr in uno standard unico.