UDDI - Guida rapida
UDDI è uno standard basato su XML per la descrizione, la pubblicazione e la ricerca di servizi Web.
UDDI sta per Universal Description, Discovery, and Integration.
UDDI è una specifica per un registro distribuito di servizi web.
UDDI è un framework aperto, indipendente dalla piattaforma.
UDDI può comunicare tramite SOAP, CORBA, Java RMI Protocol.
UDDI utilizza WSDL (Web Service Definition Language) per descrivere le interfacce ai servizi web.
UDDI è visto con SOAP e WSDL come uno dei tre standard di base dei servizi web.
UDDI è un'iniziativa di settore aperto, che consente alle aziende di scoprirsi e definire come interagiscono su Internet.
UDDI ha due sezioni:
Un registro di tutti i metadati del servizio Web, incluso un puntatore alla descrizione WSDL di un servizio.
Una serie di definizioni del tipo di porta WSDL per la manipolazione e la ricerca in quel registro.
Storia dell'UDDI
UDDI 1.0 è stato originariamente annunciato da Microsoft, IBM e Ariba nel settembre 2000.
Dall'annuncio iniziale, l'iniziativa UDDI è cresciuta fino a includere più di 300 aziende tra cui Dell, Fujitsu, HP, Hitachi, IBM, Intel, Microsoft, Oracle, SAP e Sun.
Nel maggio 2001, Microsoft e IBM hanno lanciato i primi siti di operatori UDDI e hanno attivato il registro UDDI.
Nel giugno 2001, UDDI ha annunciato la versione 2.0.
Al momento della stesura di questo tutorial, i siti Microsoft e IBM avevano implementato la specifica 1.0 e stavano pianificando il supporto 2.0 nel prossimo futuro.
Attualmente UDDI è sponsorizzato da OASIS.
Processi dell'interfaccia del partner
I Partner Interface Processes (PIP) sono interfacce basate su XML che consentono a due partner commerciali di scambiare dati. Esistono già dozzine di PIP. Alcuni di loro sono elencati qui -
PIP2A2 - Consente a un partner di interrogare un altro per informazioni sul prodotto.
PIP3A2 - Consente a un partner di interrogare il prezzo e la disponibilità di prodotti specifici.
PIP3A4 - Consente a un partner di inviare un ordine di acquisto elettronico e ricevere conferma dell'ordine.
PIP3A3 - Consente a un partner di trasferire il contenuto di un carrello della spesa elettronico.
PIP3B4 - Consente a un partner di interrogare lo stato di una specifica spedizione.
Registri UDDI privati
In alternativa all'utilizzo della rete pubblica federata di registri UDDI disponibile su Internet, le aziende o i gruppi industriali possono scegliere di implementare i propri registri UDDI privati.
Questi servizi esclusivi sono progettati al solo scopo di consentire ai membri della società o del gruppo industriale di condividere e pubblicizzare servizi tra di loro.
Indipendentemente dal fatto che il registro UDDI faccia parte della rete federata globale o di un registro di proprietà e gestito privatamente, l'unica cosa che li lega tutti insieme è un'API di servizi Web comune per la pubblicazione e l'individuazione di aziende e servizi pubblicizzati all'interno del registro UDDI.
Un'azienda o una società può registrare tre tipi di informazioni in un registro UDDI. Queste informazioni sono contenute in tre elementi di UDDI.
Questi tre elementi sono:
- Pagine bianche,
- Pagine Gialle e
- Pagine verdi.
Pagine bianche
Le pagine bianche contengono:
Informazioni di base sull'azienda e sulla sua attività.
Informazioni di contatto di base tra cui nome dell'azienda, indirizzo, numero di telefono di contatto, ecc.
A Identificatori univoci per gli ID fiscali dell'azienda. Queste informazioni consentono ad altri di scoprire il tuo servizio web in base alla tua identificazione aziendale.
Pagine Gialle
Le pagine gialle contengono maggiori dettagli sull'azienda. Includono descrizioni del tipo di capacità elettroniche che l'azienda può offrire a chiunque voglia fare affari con esso.
Le pagine gialle utilizzano schemi di classificazione industriale comunemente accettati, codici di settore, codici di prodotto, codici di identificazione aziendale e simili per rendere più facile per le aziende cercare tra gli elenchi e trovare esattamente ciò che desiderano.
Pagine verdi
Le pagine verdi contengono informazioni tecniche su un servizio web. Una pagina verde consente a qualcuno di collegarsi a un servizio Web dopo che è stato trovato. Include:
- Le varie interfacce
- Le posizioni degli URL
- Informazioni di rilevamento e dati simili necessari per trovare ed eseguire il servizio Web.
NOTE- UDDI non si limita a descrivere i servizi web basati su SOAP. Piuttosto, UDDI può essere utilizzato per descrivere qualsiasi servizio, da una singola pagina Web o indirizzo e-mail fino ai servizi SOAP, CORBA e Java RMI.
L'architettura tecnica UDDI è composta da tre parti:
Modello dati UDDI
UDDI Data Model è uno schema XML per descrivere aziende e servizi web. Il modello dati è descritto in dettaglio nel capitolo "Modello dati UDDI".
Specifica API UDDI
È una specifica dell'API per la ricerca e la pubblicazione di dati UDDI.
Servizi cloud UDDI
Si tratta di siti dell'operatore che forniscono implementazioni della specifica UDDI e sincronizzano tutti i dati in base a una pianificazione.
L'UDDI Business Registry (UBR), noto anche come Public Cloud, è un sistema concettualmente unico costruito da più nodi i cui dati vengono sincronizzati tramite replica.
Gli attuali servizi cloud forniscono una directory centralizzata logicamente, ma distribuita fisicamente. Significa che i dati inviati a un nodo radice verranno replicati automaticamente su tutti gli altri nodi radice. Attualmente, la replica dei dati avviene ogni 24 ore.
I servizi cloud UDDI sono attualmente forniti da Microsoft e IBM. Ariba aveva inizialmente previsto di offrire anche un operatore, ma da allora si è ritirata dall'impegno. Per il prossimo futuro sono previsti altri operatori di altre società, inclusa Hewlett-Packard.
È anche possibile creare registri UDDI privati. Ad esempio, una grande azienda può creare il proprio registro UDDI privato per registrare tutti i servizi web interni. Poiché questi registri non vengono sincronizzati automaticamente con i nodi UDDI root, non vengono considerati come parte del cloud UDDI.
UDDI include uno schema XML che descrive le seguenti strutture di dati:
- businessEntity
- businessService
- bindingTemplate
- tModel
- publisherAssertion
struttura dei dati businessEntity
La struttura dell'entità aziendale rappresenta il fornitore di servizi web. All'interno del registro UDDI, questa struttura contiene informazioni sulla società stessa, comprese informazioni di contatto, categorie di settore, identificativi aziendali e un elenco dei servizi forniti.
Ecco un esempio di voce di registro UDDI di un'azienda fittizia:
<businessEntity businessKey = "uuid:C0E6D5A8-C446-4f01-99DA-70E212685A40"
operator = "http://www.ibm.com" authorizedName = "John Doe">
<name>Acme Company</name>
<description>
We create cool Web services
</description>
<contacts>
<contact useType = "general info">
<description>General Information</description>
<personName>John Doe</personName>
<phone>(123) 123-1234</phone>
<email>[email protected]</email>
</contact>
</contacts>
<businessServices>
...
</businessServices>
<identifierBag>
<keyedReference tModelKey = "UUID:8609C81E-EE1F-4D5A-B202-3EB13AD01823"
name = "D-U-N-S" value = "123456789" />
</identifierBag>
<categoryBag>
<keyedReference tModelKey = "UUID:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2"
name = "NAICS" value = "111336" />
</categoryBag>
</businessEntity>struttura dei dati businessService
La struttura del servizio aziendale rappresenta un servizio Web individuale fornito dall'entità aziendale. La sua descrizione include informazioni su come collegarsi al servizio web, che tipo di servizio web è e a quali categorie tassonomiche appartiene.
Di seguito è riportato un esempio di una struttura di servizi aziendali per il servizio Web Hello World.
<businessService serviceKey = "uuid:D6F1B765-BDB3-4837-828D-8284301E5A2A"
businessKey = "uuid:C0E6D5A8-C446-4f01-99DA-70E212685A40">
<name>Hello World Web Service</name>
<description>A friendly Web service</description>
<bindingTemplates>
...
</bindingTemplates>
<categoryBag />
</businessService>Si noti l'uso degli identificatori univoci universali (UUID) negli attributi businessKey e serviceKey . Ogni entità aziendale e servizio aziendale viene identificato in modo univoco in tutti i registri UDDI tramite l'UUID assegnato dal registro quando le informazioni vengono inserite per la prima volta.
bindingTemplate Struttura dati
I modelli vincolanti sono le descrizioni tecniche dei servizi Web rappresentati dalla struttura dei servizi aziendali. Un singolo servizio aziendale può avere più modelli di associazione. Il modello di associazione rappresenta l'effettiva implementazione del servizio Web.
Di seguito è riportato un esempio di un modello di associazione per Hello World.
<bindingTemplate serviceKey = "uuid:D6F1B765-BDB3-4837-828D-8284301E5A2A"
bindingKey = "uuid:C0E6D5A8-C446-4f01-99DA-70E212685A40">
<description>Hello World SOAP Binding</description>
<accessPoint URLType = "http">http://localhost:8080</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo tModelKey = "uuid:EB1B645F-CF2F-491f-811A-4868705F5904">
<instanceDetails>
<overviewDoc>
<description>
references the description of the WSDL service definition
</description>
<overviewURL>
http://localhost/helloworld.wsdl
</overviewURL>
</overviewDoc>
</instanceDetails>
</tModelInstanceInfo>
</tModelInstanceDetails>
</bindingTemplate>Poiché un servizio aziendale può avere più modelli di associazione, il servizio può specificare diverse implementazioni dello stesso servizio, ciascuna associata a un diverso insieme di protocolli oa un diverso indirizzo di rete.
tModel Data Structure
tModel è l'ultimo tipo di dati di base, ma potenzialmente il più difficile da comprendere. tModel sta per modello tecnico.
tModel è un modo per descrivere le varie strutture aziendali, di servizio e di modello memorizzate nel registro UDDI. Qualsiasi concetto astratto può essere registrato all'interno dell'UDDI come tModel. Ad esempio, se si definisce un nuovo tipo di porta WSDL, è possibile definire un tModel che rappresenta quel tipo di porta all'interno dell'UDDI. Quindi, è possibile specificare che un determinato servizio aziendale implementa quel tipo di porta associando tModel a uno dei modelli di binding di quel servizio aziendale.
Di seguito è riportato un esempio di un tModel che rappresenta il tipo di porta Hello World Interface.
<tModel tModelKey = "uuid:xyz987..." operator = "http://www.ibm.com"
authorizedName = "John Doe">
<name>HelloWorldInterface Port Type</name>
<description>
An interface for a friendly Web service
</description>
<overviewDoc>
<overviewURL>
http://localhost/helloworld.wsdl
</overviewURL>
</overviewDoc>
</tModel>struttura dati publisherAssertion
Si tratta di una struttura di relazione che mette in associazione due o più strutture businessEntity in base a un tipo specifico di relazione, come filiale o dipartimento.
La struttura publisherAssertion è costituita dai tre elementi: fromKey (il primo businessKey), toKey (il secondo businessKey) e keyedReference.
KeyedReference designa il tipo di relazione affermata in termini di una coppia keyName keyValue all'interno di un tModel, a cui fa riferimento univocamente tModelKey.
<element name = "publisherAssertion" type = "uddi:publisherAssertion" />
<complexType name = "publisherAssertion">
<sequence>
<element ref = "uddi:fromKey" />
<element ref = "uddi:toKey" />
<element ref = "uddi:keyedReference" />
</sequence>
</complexType>Un registro non è di alcuna utilità senza un modo per accedervi. Lo standard UDDI versione 2.0 specifica due interfacce per i consumatori di servizi e i fornitori di servizi per interagire con il registro.
I consumatori di servizi utilizzano Inquiry Interface per trovare un servizio e i fornitori di servizi utilizzano Publisher Interface per elencare un servizio.
Il nucleo dell'interfaccia UDDI sono le definizioni dello schema XML UDDI. Questi definiscono i tipi di dati UDDI fondamentali attraverso i quali fluiscono tutte le informazioni.
L'interfaccia del publisher
L'interfaccia del publisher definisce sedici operazioni per un fornitore di servizi che gestisce le sue voci nel registro UDDI -
get_authToken- Recupera un token di autorizzazione. Tutte le operazioni dell'interfaccia del publisher richiedono l'invio di un token di autorizzazione valido con la richiesta.
discard_authToken- Indica al registro UDDI di non accettare più un determinato token di autorizzazione. Questo passaggio equivale a disconnettersi dal sistema.
save_business - Crea o aggiorna le informazioni di un'entità aziendale contenute nel registro UDDI.
save_service - Crea o aggiorna le informazioni sui servizi Web forniti da un'entità aziendale.
save_binding - Crea o aggiorna le informazioni tecniche sull'implementazione di un servizio web.
save_tModel - Crea o aggiorna la registrazione dei concetti astratti gestiti dal registro UDDI.
delete_business - Rimuove completamente le entità aziendali fornite dal registro UDDI.
delete_service - Rimuove completamente i servizi Web forniti dal registro UDDI.
delete_binding - Rimuove i dettagli tecnici dei servizi Web forniti dal registro UDDI.
delete_tModel - Rimuove i tModels specificati dal registro UDDI.
get_registeredInfo - Restituisce un riepilogo di tutto ciò di cui il registro UDDI tiene traccia per l'utente, comprese tutte le attività, tutti i servizi e tutti i tModel.
set_publisherAssertions - Gestisce tutte le asserzioni di relazione tracciate associate a un singolo account editore.
add_publisherAssertions - Fa sì che una o più publisherAssertions vengano aggiunte alla raccolta di asserzioni di un singolo editore.
delete_publisherAssertions - Causa la rimozione di uno o più elementi publisherAssertion dalla raccolta di asserzioni di un editore.
get_assertionStatusReport - Fornisce supporto amministrativo per determinare lo stato delle affermazioni dell'editore correnti e in sospeso che coinvolgono una qualsiasi delle registrazioni aziendali gestite dal singolo account editore.
get_publisherAssertions - Ottiene il set completo di affermazioni del publisher associato a un account publisher individuale.
L'interfaccia di indagine
L'interfaccia di richiesta definisce dieci operazioni per la ricerca nel registro UDDI e il recupero dei dettagli su registrazioni specifiche:
find_binding - Restituisce un elenco di servizi Web che corrispondono a un particolare insieme di criteri in base alle informazioni tecniche vincolanti.
find_business - Restituisce un elenco di entità aziendali che corrispondono a un particolare insieme di criteri.
find_ltservice - Restituisce un elenco di servizi Web che corrispondono a un particolare insieme di criteri.
find_tModel - Restituisce un elenco di tModels che corrispondono a un particolare insieme di criteri.
get_bindingDetail - Restituisce le informazioni di registrazione complete per un particolare modello di associazione del servizio Web.
get_businessDetail - Restituisce le informazioni di registrazione per un'entità aziendale, inclusi tutti i servizi forniti dall'entità.
get_businessDetailExt - Restituisce le informazioni di registrazione complete per un'entità aziendale.
get_serviceDetail - Restituisce le informazioni di registrazione complete per un servizio web.
get_tModelDetail - Restituisce le informazioni di registrazione complete per un tModel.
find_relatedBusinesses - Rileva le attività che sono state collegate tramite il modello uddi-org: relations.
Si consideri che un'azienda XYZ desidera registrare le proprie informazioni di contatto, la descrizione del servizio e le informazioni di accesso al servizio in linea con UDDI. Sono necessari i seguenti passaggi:
Scegli un operatore con cui lavorare. Ogni operatore ha termini e condizioni diversi per autorizzare l'accesso alla sua replica del registro.
Costruisci o ottieni in altro modo un client UDDI, come quelli forniti dagli operatori.
Ottieni un token di autenticazione dall'operatore.
Registrare le informazioni sull'attività. Includere tutte le informazioni che potrebbero essere utili a chi cerca corrispondenze.
Rilascia il token di autenticazione.
Utilizza le API di ricerca per testare il recupero delle informazioni, comprese le informazioni sul modello di associazione, per assicurarti che qualcuno che le ottiene possa utilizzarle con successo per interagire con il tuo servizio.
Compila le informazioni di tModel nel caso in cui qualcuno desideri cercare un determinato servizio e trovare la tua attività come uno dei fornitori di servizi.
Aggiornare le informazioni secondo necessità per riflettere le mutevoli informazioni di contatto aziendali e nuovi dettagli del servizio, ottenendo e rilasciando ogni volta un nuovo token di autenticazione dall'operatore. Ogni volta che devi aggiornare o modificare i dati che hai registrato, devi tornare dall'operatore con cui hai inserito i dati.
I seguenti esempi mostreranno come la Società XYZ registrerebbe le proprie informazioni e come un distributore interessato a portare la linea di prodotti XYZ potrebbe trovare informazioni su come contattare la società ed effettuare un ordine, utilizzando i servizi Web XYZ.com.
Creazione del registro
Dopo aver ottenuto un token di autenticazione da uno degli operatori Microsoft, ad esempio gli sviluppatori di XYZ.com decidono quali informazioni pubblicare nel registro e utilizzano uno degli strumenti UDDI forniti da Microsoft. Se necessario, gli sviluppatori possono anche scrivere un programma Java, C # o VB.NET per generare i messaggi SOAP appropriati. Ecco un esempio.
POST /save_business HTTP/1.1
Host: www.XYZ.com
Content-Type: text/xml; charset = "utf-8"
Content-Length: nnnn
SOAPAction: "save_business"
<?xml version = "1.0" encoding = "UTF-8" ?>
<Envelope xmlns = "http://schemas/xmlsoap.org/soap/envelope/">
<Body>
<save_business generic = "2.0" xmlns = "urn:uddi-org:api_v2">
<businessKey = "">
</businessKey>
<name>
XYZ, Pvt Ltd.
</name>
<description>
Company is involved in giving Stat-of-the-art....
</description>
<identifierBag> ... </identifierBag>
...
</save_business>
</Body>
</Envelope>Questo esempio illustra un messaggio SOAP che richiede di registrare un'entità aziendale UDDI per la società XYZ. L'elemento chiave è vuoto, perché l'operatore genera automaticamente la chiave UUID per la struttura dati. La maggior parte dei campi viene omessa per mostrare un semplice esempio.
La società XYZ può sempre eseguire un'altra operazione save_business da aggiungere alle informazioni di base richieste per creare un'entità aziendale.
Recupero delle informazioni
Dopo che la società XYZ ha aggiornato la propria voce UDDI con le informazioni pertinenti, le aziende che desiderano diventare distributori XYZ possono cercare le informazioni di contatto nel registro UDDI e ottenere le descrizioni dei servizi e i punti di accesso per i due servizi Web che XYZ.com pubblica online inserimento ordini: ordini all'ingrosso pre-stagione e ordini di rifornimento durante la stagione.
Questo esempio illustra una richiesta SOAP di esempio per ottenere informazioni sui dettagli aziendali sulla società XYZ. Una volta che conosci l'UUID, o chiave, per l'attività specifica che è stata registrata, puoi utilizzarlo nell'API get_businessDetail per restituire informazioni specifiche su tale attività.
POST /get_businessDetail HTTP/1.1
Host: www.XYZ.com
Content-Type: text/xml; charset = "utf-8"
Content-Length: nnnn
SOAPAction: "get_businessDetail"
<?xml version = "1.0" encoding = "UTF-8" ?>
<Envelope xmlns = "http://schemas/xmlsoap.org/soap/envelope/">
<Body>
<get_businessDetail generic = "2.0" xmlns = "urn:uddi-org:api_v2">
<businessKey = "C90D731D-772HSH-4130-9DE3-5303371170C2">
</businessKey>
</get_businessDetail>
</Body>
</Envelope>Il modello di dati UDDI definisce una struttura generica per l'archiviazione delle informazioni su un'azienda e sui servizi web che pubblica. Il modello di dati UDDI è completamente estensibile, includendo diverse strutture di informazioni in sequenza ripetuta.
Tuttavia, WSDL viene utilizzato per descrivere l'interfaccia di un servizio Web. WSDL è abbastanza semplice da usare con UDDI.
WSDL è rappresentato in UDDI utilizzando una combinazione di informazioni businessService, bindingTemplate e tModel .
Come con qualsiasi servizio registrato in UDDI, le informazioni generiche sul servizio vengono memorizzate nella struttura dati businessService e le informazioni specifiche su come e dove si accede al servizio vengono memorizzate in una o più strutture bindingTemplate associate . Ogni struttura bindingTemplate include un elemento che contiene l'indirizzo di rete del servizio e ha associato ad esso una o più strutture tModel che descrivono e identificano in modo univoco il servizio.
Quando UDDI viene utilizzato per archiviare informazioni WSDL o puntatori a file WSDL, per convenzione si dovrebbe fare riferimento a tModel come tipo wsdlSpec , il che significa che l' elemento overviewDoc è chiaramente identificato come che punta a una definizione dell'interfaccia del servizio WSDL.
Per UDDI, i contenuti WSDL sono suddivisi in due elementi principali: il file di interfaccia e il file di implementazione.
Il servizio web del sistema di prenotazione Hertz fornisce un esempio concreto di come UDDI e WSDL lavorano insieme. Ecco il <tModel> per questo servizio web -
<tModel authorizedName = "..." operator = "..." tModelKey = "...">
<name>HertzReserveService</name>
<description xml:lang = "en">
WSDL description of the Hertz reservation service interface
</description>
<overviewDoc>
<description xml:lang = "en">
WSDL source document.
</description>
<overviewURL>
http://mach3.ebphost.net/wsdl/hertz_reserve.wsdl
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference tModelKey = "uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"
keyName = "uddi-org:types" keyValue = "wsdlSpec"/>
</categoryBag>
</tModel>I punti chiave sono:
L'elemento overviewURL fornisce l'URL in cui è possibile trovare il file WSDL di definizione dell'interfaccia del servizio. Ciò consente agli utenti e agli strumenti che supportano UDDI / WSDL di individuare la definizione dell'interfaccia del servizio.
Lo scopo dell'elemento keyedReference in categoryBag è assicurarsi che questo tModel sia classificato come documento di specifica WSDL.
Sono attualmente disponibili numerose implementazioni UDDI. Queste implementazioni semplificano la ricerca o la pubblicazione di dati UDDI, senza rimanere impantanati nelle complessità dell'API UDDI. Ecco una breve sinossi delle principali implementazioni UDDI disponibili.
Implementazioni Java
Esistono due implementazioni UDDI per Java.
UDDI4J (UDDI per Java) - UDDI4J è stato originariamente creato da IBM. Nel gennaio 2001, IBM ha consegnato il codice al proprio sito open source. UDDI4J è una libreria di classi Java che fornisce un'API per interagire con un UDDI.
jUDDI - jUDDI è un'implementazione Java open source di un registro UDDI e un toolkit per l'accesso ai servizi UDDI.
Implementazione di Perl
UDDI::Lite - Fornisce un client UDDI di base per la ricerca e la pubblicazione.
Implementazione di Ruby
UDDI4r - Fornisce un client UDDI di base per la ricerca e la pubblicazione.
Implementazione di Python
UDDI4Py - UDDI4Py è un pacchetto Python che consente l'invio di richieste e l'elaborazione delle risposte dalle API UDDI versione 2.
Il progetto UDDI definisce anche una serie di definizioni di XML Schema che descrivono i formati di dati utilizzati dalle varie API di specifica. Questi documenti sono tutti disponibili per il download su www.uddi.org . La versione corrente di tutti i gruppi di specifiche è la versione 2.0.
Le specifiche includono quanto segue:
- Replica UDDI,
- Operatori UDDI,
- API del programmatore UDDI e
- Strutture dati UDDI
Replica UDDI
Questo documento descrive i processi di replica dei dati e le interfacce a cui un operatore del registro deve conformarsi per ottenere la replica dei dati tra i siti. Questa specifica non è l'API di un programmatore; definisce il meccanismo di replica utilizzato tra i nodi UBR.
Operatori UDDI
Questo documento delinea il comportamento ei parametri operativi richiesti dagli operatori del nodo UDDI. Questa specifica definisce i requisiti di gestione dei dati a cui gli operatori devono attenersi.
API del programmatore UDDI
Questa specifica definisce una serie di funzioni supportate da tutti i registri UDDI per la richiesta di informazioni sui servizi ospitati in un registro e per la pubblicazione di informazioni su un'azienda o un servizio in un registro. Questa specifica definisce una serie di messaggi SOAP contenenti documenti XML che un registro UDDI accetta, analizza e risponde. Questa specifica, insieme allo schema API XML UDDI e alla specifica struttura dati UDDI, costituisce un'interfaccia di programmazione completa per un registro UDDI.
Strutture dati UDDI
Questa specifica copre le specifiche delle strutture XML contenute nei messaggi SOAP definiti dall'API del programmatore UDDI. Questa specifica definisce cinque strutture di dati di base e le loro relazioni tra loro.
Lo schema API XML UDDI non è contenuto in una specifica; piuttosto, è memorizzato come un documento XML Schema che definisce la struttura e i tipi di dati delle strutture di dati UDDI.
UDDI ei suoi elementi in questo tutorial e hanno anche visto l'architettura completa e il modello di dati di UDDI.
Abbiamo imparato a conoscere le due interfacce UDDI: interfaccia del publisher e interfaccia di richiesta. Abbiamo anche imparato come registrarsi e cercare servizi web con UDDI.
Qual è il prossimo?
Il passaggio successivo consiste nell'apprendere SOAP, WSDL e servizi Web.
SAPONE
SOAP è un semplice protocollo basato su XML che consente alle applicazioni di scambiare informazioni su HTTP.
Se vuoi saperne di più su SOAP, visita il nostro tutorial SOAP .
WSDL
WSDL è il formato standard per descrivere un servizio Web in formato XML.
WSDL è parte integrante di UDDI.
Se vuoi saperne di più su WSDL, visita il nostro tutorial WSDL .
Servizi web
I servizi Web possono convertire le tue applicazioni in applicazioni web.
Se desideri saperne di più sui servizi web, visita il nostro tutorial sui servizi web .
Di seguito è riportato il riferimento completo delle API di indagine UDDI e delle API di pubblicazione UDDI.
Le API di indagine UDDI
| Nome API | Descrizione | V1.0 | V2.0 |
|---|---|---|---|
| find_binding | Cerca le associazioni di modelli associate a un servizio specificato. | Y | Y |
| find_business | Cerca attività che soddisfano i criteri specificati. | Y | Y |
| find_relatedBusinesses | Rileva le attività che sono state collegate tramite il modello uddi-org: relations. | Y | |
| find_service | Cerca il servizio associato a un'attività specifica. | Y | Y |
| find_tModel | Cerca i record tModel che corrispondono ai criteri specificati. | Y | Y |
| get_bindingDetail | Recupera il bindingTemplate completo per ogni bindingKey specificato. | Y | Y |
| get_businessDetail | Recupera il businessEntity completo per ogni businessKey specificato. | Y | Y |
| get_businessDetailExt | Recupera il businessEntity esteso per ogni businessKey specificato. | Y | Y |
| get_serviceDetail | Recupera il record businessService per ogni serviceKey specificato. | Y | Y |
| get_tModelDetail | Recupera il record tModel per ogni tModelKey specificato. | Y | Y |
Le API di pubblicazione UDDI
| Nome API | Descrizione | V1.0 | V2.0 |
|---|---|---|---|
| get_authToken | Recupera un token di autorizzazione. Tutte le operazioni dell'interfaccia del publisher richiedono l'invio di un token di autorizzazione valido con la richiesta. | Y | Y |
| discard_authToken | Indica al registro UDDI di non accettare più un determinato token di autorizzazione. Questo passaggio equivale a disconnettersi dal sistema. | Y | Y |
| save_business | Crea o aggiorna le informazioni di un'entità aziendale contenute nel registro UDDI. | Y | Y |
| save_service | Crea o aggiorna le informazioni sui servizi Web forniti da un'entità aziendale. | Y | Y |
| save_binding | Crea o aggiorna le informazioni tecniche sull'implementazione di un servizio Web. | Y | Y |
| save_tModel | Crea o aggiorna la registrazione dei concetti astratti gestiti dal registro UDDI. | Y | Y |
| delete_business | Rimuove completamente le entità aziendali specificate dal registro UDDI. | Y | Y |
| delete_service | Rimuove completamente i servizi Web forniti dal registro UDDI. | Y | Y |
| delete_binding | Rimuove i dettagli tecnici del servizio Web dal registro UDDI. | Y | Y |
| delete_tModel | Rimuove i tModels specificati dal registro UDDI. | Y | Y |
| get_registeredInfo | Restituisce un riepilogo di tutto ciò di cui il registro UDDI sta attualmente tenendo traccia per l'utente, comprese tutte le attività commerciali, tutti i servizi e tutti i tModel. | Y | Y |
| set_publisherAssertions | Gestisce tutte le asserzioni di relazione tracciate associate a un singolo account editore. | Y | |
| add_publisherAssertions | Causa l'aggiunta di una o più publisherAssertions alla raccolta di asserzioni di un singolo editore. | Y | |
| delete_publisherAssertions | Causa la rimozione di uno o più elementi publisherAssertion dalla raccolta di asserzioni di un editore. | Y | |
| get_assertionStatusReport | Fornisce supporto amministrativo per determinare lo stato delle affermazioni dell'editore correnti e in sospeso che coinvolgono una qualsiasi delle registrazioni aziendali gestite dal singolo account editore. | Y | |
| get_publisherAssertions | Ottiene il set completo di affermazioni del publisher associato a un account publisher individuale. | Y |
Riferimento codice di errore
Viene fornito un riferimento completo dei codici di errore restituiti dalle API UDDI: