UDDI - Szybki przewodnik

UDDI to oparty na języku XML standard opisywania, publikowania i znajdowania usług internetowych.

UDDI oznacza Universal Description, Discovery, and Integration.
UDDI to specyfikacja rozproszonego rejestru usług internetowych.
UDDI to niezależna od platformy, otwarta struktura.
UDDI może komunikować się za pośrednictwem protokołu SOAP, CORBA, Java RMI.
UDDI używa języka definicji usługi sieci Web (WSDL) do opisywania interfejsów usług internetowych.
UDDI jest postrzegany w SOAP i WSDL jako jeden z trzech podstawowych standardów usług WWW.
UDDI to otwarta inicjatywa branżowa, która umożliwia firmom wzajemne poznanie się i zdefiniowanie sposobu interakcji w Internecie.

UDDI ma dwie sekcje -

Rejestr wszystkich metadanych usługi WWW, w tym wskaźnik do opisu usługi WSDL.
Zestaw definicji typów portów WSDL do manipulowania i wyszukiwania w tym rejestrze.

Historia UDDI

UDDI 1.0 został pierwotnie ogłoszony przez Microsoft, IBM i Ariba we wrześniu 2000 roku.
Od czasu pierwszego ogłoszenia inicjatywa UDDI rozrosła się i obejmuje ponad 300 firm, w tym Dell, Fujitsu, HP, Hitachi, IBM, Intel, Microsoft, Oracle, SAP i Sun.
W maju 2001 r. Microsoft i IBM uruchomiły pierwsze strony operatorów UDDI i uruchomiły rejestr UDDI.
W czerwcu 2001 roku UDDI ogłosił wersję 2.0.
W chwili pisania tego samouczka witryny Microsoft i IBM wdrożyły specyfikację 1.0 i planowały obsługę 2.0 w najbliższej przyszłości.
Obecnie UDDI jest sponsorowany przez OASIS.

Procesy interfejsu partnera

Procesy interfejsu partnera (PIP) to interfejsy oparte na języku XML, które umożliwiają dwóm partnerom handlowym wymianę danych. Istnieją już dziesiątki PIP. Niektóre z nich są wymienione tutaj -

PIP2A2 - Umożliwia partnerowi zapytanie innego partnera o informacje o produkcie.
PIP3A2 - Umożliwia partnerowi sprawdzenie ceny i dostępności określonych produktów.
PIP3A4 - Umożliwia partnerowi złożenie elektronicznego zamówienia i otrzymanie potwierdzenia przyjęcia zamówienia.
PIP3A3 - Umożliwia partnerowi przenoszenie zawartości elektronicznego koszyka na zakupy.
PIP3B4 - Umożliwia partnerowi zapytanie o status określonej przesyłki.

Prywatne rejestry UDDI

Alternatywnie do korzystania z publicznej sfederowanej sieci rejestrów UDDI dostępnych w Internecie, firmy lub grupy branżowe mogą zdecydować się na wdrożenie własnych prywatnych rejestrów UDDI.

Te ekskluzywne usługi mają na celu wyłącznie umożliwienie członkom firmy lub grupy branżowej dzielenia się i reklamowania usług między sobą.

Niezależnie od tego, czy rejestr UDDI jest częścią globalnej sieci federacyjnej, czy też jest prywatnym i zarządzanym rejestrem, jedyną rzeczą, która je łączy, jest wspólny interfejs API usług sieciowych do publikowania i lokalizowania firm i usług reklamowanych w rejestrze UDDI.

Firma lub firma może zarejestrować trzy rodzaje informacji w rejestrze UDDI. Informacje te zawarte są w trzech elementach UDDI.

Te trzy elementy to -

Białe strony,
Yellow Pages i
Zielone strony.

Białe strony

Białe strony zawierają -

Podstawowe informacje o firmie i jej działalności.
Podstawowe informacje kontaktowe, w tym nazwa firmy, adres, numer telefonu kontaktowego itp.
Unikalne identyfikatory identyfikatorów podatkowych firmy. Te informacje pozwalają innym na znalezienie Twojej usługi internetowej na podstawie identyfikacji Twojej firmy.

Żółte strony

Żółte strony zawierają więcej informacji o firmie. Zawierają opisy rodzajów możliwości elektronicznych, jakie firma może zaoferować każdemu, kto chce robić z nią interesy.
Yellow Pages wykorzystuje powszechnie akceptowane schematy kategoryzacji przemysłowej, kody branżowe, kody produktów, kody identyfikacyjne firm i tym podobne, aby ułatwić firmom przeszukiwanie list i znajdowanie dokładnie tego, czego chcą.

Zielone strony

Zielone strony zawierają informacje techniczne o usłudze internetowej. Zielona strona umożliwia komuś powiązanie z usługą sieci Web po jej znalezieniu. Obejmuje -

Różne interfejsy
Lokalizacje adresów URL
Informacje wyszukiwania i podobne dane wymagane do znalezienia i uruchomienia usługi sieci Web.

NOTE- UDDI nie ogranicza się do opisywania usług internetowych opartych na SOAP. Zamiast tego, UDDI może służyć do opisywania dowolnej usługi, od pojedynczej strony internetowej lub adresu e-mail aż po usługi SOAP, CORBA i Java RMI.

Architektura techniczna UDDI składa się z trzech części -

Model danych UDDI

Model danych UDDI to schemat XML do opisu firm i usług internetowych. Model danych został szczegółowo opisany w rozdziale „Model danych UDDI”.

Specyfikacja interfejsu API UDDI

Jest to specyfikacja API do wyszukiwania i publikowania danych UDDI.

Usługi w chmurze UDDI

Są to witryny operatorów, które zapewniają implementacje specyfikacji UDDI i synchronizują wszystkie dane zgodnie z harmonogramem.

Rejestr biznesowy UDDI (UBR), znany również jako Public Cloud, jest koncepcyjnie pojedynczym systemem zbudowanym z wielu węzłów, których dane są synchronizowane poprzez replikację.

Obecne usługi w chmurze zapewniają logicznie scentralizowany, ale fizycznie rozproszony katalog. Oznacza to, że dane przesłane do jednego węzła głównego będą automatycznie replikowane we wszystkich pozostałych węzłach głównych. Obecnie replikacja danych odbywa się co 24 godziny.

Usługi chmurowe UDDI są obecnie świadczone przez Microsoft i IBM. Ariba początkowo planowała również zaoferować operatora, ale od tego czasu wycofała się z tego zobowiązania. W najbliższej przyszłości planowani są dodatkowi operatorzy z innych firm, w tym Hewlett-Packard.

Możliwe jest również utworzenie prywatnych rejestrów UDDI. Na przykład duża firma może założyć własny prywatny rejestr UDDI do rejestrowania wszystkich wewnętrznych usług internetowych. Ponieważ te rejestry nie są automatycznie synchronizowane z głównymi węzłami UDDI, nie są traktowane jako część chmury UDDI.

UDDI zawiera schemat XML opisujący następujące struktury danych -

businessEntity
businessService
bindingTemplate
tModel
publisherAssertion

Struktura danych businessEntity

Struktura podmiotu gospodarczego reprezentuje dostawcę usług internetowych. W rejestrze UDDI ta struktura zawiera informacje o samej firmie, w tym dane kontaktowe, kategorie branżowe, identyfikatory biznesowe oraz listę świadczonych usług.

Oto przykład wpisu rejestru UDDI fikcyjnej firmy -

<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>

Struktura danych businessService

Struktura usług biznesowych reprezentuje indywidualną usługę internetową świadczoną przez podmiot gospodarczy. Jego opis zawiera informacje o tym, jak powiązać się z usługą internetową, jakiego rodzaju jest to usługa sieciowa i do jakich kategorii taksonomicznych należy.

Oto przykład struktury usług biznesowych dla usługi sieci 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>

Zwróć uwagę na użycie uniwersalnych unikalnych identyfikatorów (UUID) w atrybutach businessKey i serviceKey . Każdy podmiot gospodarczy i usługa biznesowa są jednoznacznie identyfikowane we wszystkich rejestrach UDDI za pomocą identyfikatora UUID przypisanego przez rejestr podczas pierwszego wprowadzania informacji.

bindingTemplate Struktura danych

Szablony powiązań to techniczne opisy usług internetowych reprezentowanych przez strukturę usług biznesowych. Pojedyncza usługa biznesowa może mieć wiele szablonów powiązań. Szablon powiązania reprezentuje rzeczywistą implementację usługi internetowej.

Oto przykład szablonu powiązania dla 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>

Ponieważ usługa biznesowa może mieć wiele szablonów powiązań, usługa może określać różne implementacje tej samej usługi, z których każda jest powiązana z innym zestawem protokołów lub innym adresem sieciowym.

Struktura danych tModel

tModel to ostatni podstawowy typ danych, ale potencjalnie najtrudniejszy do uchwycenia. tModel oznacza model techniczny.

Model tModel to sposób opisu różnych struktur biznesowych, usługowych i szablonów przechowywanych w rejestrze UDDI. Każde abstrakcyjne pojęcie można zarejestrować w UDDI jako tModel. Na przykład, jeśli zdefiniujesz nowy typ portu WSDL, możesz zdefiniować tModel, który reprezentuje ten typ portu w UDDI. Następnie można określić, że dana usługa biznesowa implementuje ten typ portu, kojarząc tModel z jednym z szablonów powiązań tej usługi biznesowej.

Oto przykład tModel reprezentujący typ portu 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>

Struktura danych publisherAssertion

Jest to struktura relacji łącząca dwie lub więcej struktur businessEntity zgodnie z określonym typem relacji, takim jak oddział lub dział.

Struktura publisherAssertion składa się z trzech elementów: fromKey (pierwszy businessKey), toKey (drugi businessKey) i keyedReference.

KeyedReference wyznacza potwierdzony typ relacji za pomocą pary keyName keyValue w tModel, do której jednoznacznie odwołuje się 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>

Rejestr jest bezużyteczny bez możliwości uzyskania do niego dostępu. Standard UDDI w wersji 2.0 określa dwa interfejsy dla odbiorców usług i dostawców usług do interakcji z rejestrem.

Z usług korzystają konsumenci Inquiry Interface znaleźć usługę, z której usługodawcy korzystają Publisher Interface wystawić usługę.

Rdzeniem interfejsu UDDI są definicje schematu XML UDDI. Definiują one podstawowe typy danych UDDI, przez które przepływają wszystkie informacje.

Interfejs wydawcy

Interfejs wydawcy definiuje szesnaście operacji dla usługodawcy zarządzającego swoimi wpisami w rejestrze UDDI -

get_authToken- Pobiera token autoryzacyjny. Wszystkie operacje interfejsu wydawcy wymagają przesłania prawidłowego tokenu autoryzacji wraz z żądaniem.
discard_authToken- Informuje rejestr UDDI, aby nie akceptował już danego tokena autoryzacyjnego. Ten krok jest równoznaczny z wylogowaniem się z systemu.
save_business - Tworzy lub aktualizuje informacje podmiotu gospodarczego zawarte w rejestrze UDDI.
save_service - Tworzy lub aktualizuje informacje o usługach internetowych świadczonych przez podmiot gospodarczy.
save_binding - Tworzy lub aktualizuje informacje techniczne o wdrożeniu usługi internetowej.
save_tModel - Tworzy lub aktualizuje rejestrację pojęć abstrakcyjnych zarządzanych przez rejestr UDDI.
delete_business - Całkowicie usuwa dane podmioty gospodarcze z rejestru UDDI.
delete_service - Całkowicie usuwa określone usługi internetowe z rejestru UDDI.
delete_binding - Usuwa dane techniczne usług WWW z rejestru UDDI.
delete_tModel - Usuwa określone tModels z rejestru UDDI.
get_registeredInfo - Zwraca podsumowanie wszystkiego, co rejestr UDDI aktualnie śledzi dla użytkownika, w tym wszystkie firmy, wszystkie usługi i wszystkie tModele.
set_publisherAssertions - Zarządza wszystkimi śledzonymi potwierdzeniami relacji powiązanymi z indywidualnym kontem wydawcy.
add_publisherAssertions - powoduje dodanie jednej lub więcej asercji wydawcy do zbioru potwierdzeń pojedynczego wydawcy.
delete_publisherAssertions - Powoduje usunięcie co najmniej jednego elementu publisherAssertion z kolekcji asercji wydawcy.
get_assertionStatusReport - Zapewnia obsługę administracyjną przy określaniu stanu bieżących i oczekujących potwierdzeń wydawców, które obejmują dowolne rejestracje biznesowe zarządzane przez indywidualne konto wydawcy.
get_publisherAssertions - Uzyskuje pełny zestaw potwierdzeń wydawcy, który jest powiązany z indywidualnym kontem wydawcy.

Interfejs zapytań

Interfejs zapytań definiuje dziesięć operacji przeszukiwania rejestru UDDI i pobierania szczegółów dotyczących określonych rejestracji -

find_binding - Zwraca listę usług internetowych, które pasują do określonego zestawu kryteriów na podstawie informacji technicznych wiążących.
find_business - Zwraca listę podmiotów gospodarczych, które pasują do określonego zestawu kryteriów.
find_ltservice - Zwraca listę usług internetowych, które pasują do określonego zestawu kryteriów.
find_tModel - Zwraca listę modeli tModels pasujących do określonego zestawu kryteriów.
get_bindingDetail - Zwraca pełne informacje rejestracyjne dla określonego szablonu powiązania usługi sieci Web.
get_businessDetail - Zwraca informacje rejestracyjne dla podmiotu gospodarczego, w tym wszystkie usługi świadczone przez podmiot.
get_businessDetailExt - Zwraca pełne informacje rejestracyjne dla podmiotu gospodarczego.
get_serviceDetail - Zwraca pełne informacje rejestracyjne dla usługi internetowej.
get_tModelDetail - Zwraca pełne informacje rejestracyjne dla tModel.
find_relatedBusinesses - Odkrywa biznesy, które zostały powiązane przez model uddi-org: relacje.

Rozważmy, że firma XYZ chce zarejestrować swoje dane kontaktowe, opis usług i informacje o dostępie do usług online w UDDI. Konieczne są następujące kroki -

Wybierz operatora, z którym chcesz pracować. Każdy operator ma inne warunki autoryzacji dostępu do swojej repliki rejestru.
Zbuduj lub w inny sposób uzyskaj klienta UDDI, takiego jak te dostarczone przez operatorów.
Uzyskaj token uwierzytelniający od operatora.
Zarejestruj informacje o firmie. Uwzględnij jak najwięcej informacji, które mogą być pomocne dla osób szukających dopasowań.
Zwolnij token uwierzytelniający.
Użyj interfejsów API zapytań, aby przetestować pobieranie informacji, w tym informacji o szablonie powiązań, aby upewnić się, że osoba, która je uzyska, może z powodzeniem używać ich do interakcji z usługą.
Uzupełnij informacje tModel na wypadek, gdyby ktoś chciał wyszukać daną usługę i znaleźć Twoją firmę jako jednego z usługodawców.
Zaktualizuj informacje, jeśli jest to konieczne, aby odzwierciedlić zmieniające się biznesowe informacje kontaktowe i nowe szczegóły usługi, za każdym razem uzyskując i udostępniając nowy token uwierzytelniający od operatora. Za każdym razem, gdy musisz zaktualizować lub zmodyfikować zarejestrowane dane, musisz wrócić do operatora, u którego wprowadziłeś dane.

Poniższe przykłady pokazują, w jaki sposób firma XYZ rejestruje swoje informacje i w jaki sposób dystrybutor zainteresowany prowadzeniem linii produktów XYZ może znaleźć informacje o tym, jak skontaktować się z firmą i złożyć zamówienie, korzystając z usług internetowych XYZ.com.

Tworzenie rejestru

Po uzyskaniu tokena uwierzytelniającego od jednego z operatorów Microsoft, na przykład programiści XYZ.com decydują, jakie informacje opublikować w rejestrze i korzystają z jednego z narzędzi UDDI dostarczonych przez Microsoft. W razie potrzeby programiści mogą również napisać program w języku Java, C # lub VB.NET do generowania odpowiednich komunikatów SOAP. Oto przykład.

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>

Ten przykład ilustruje komunikat SOAP żądający zarejestrowania podmiotu gospodarczego UDDI dla firmy XYZ. Element klucza jest pusty, ponieważ operator automatycznie generuje klucz UUID dla struktury danych. Większość pól jest pomijana ze względu na prosty przykład.

Firma XYZ może zawsze wykonać kolejną operację save_business, aby dodać podstawowe informacje wymagane do utworzenia podmiotu gospodarczego.

Pobieranie informacji

Po zaktualizowaniu przez firmę XYZ wpisu UDDI o odpowiednie informacje, firmy, które chcą zostać dystrybutorami XYZ, mogą wyszukać informacje kontaktowe w rejestrze UDDI i uzyskać opisy usług oraz punkty dostępu do dwóch usług internetowych, które XYZ.com publikuje online wprowadzanie zamówień: zamówienia hurtowe przedsezonowe i zamówienia uzupełniania zapasów w trakcie sezonu.

Ten przykład ilustruje przykładowe żądanie SOAP w celu uzyskania szczegółowych informacji biznesowych o firmie XYZ. Gdy już znasz identyfikator UUID lub klucz zarejestrowanej firmy, możesz użyć go w interfejsie API get_businessDetail, aby zwrócić określone informacje o tej firmie.

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>

Model danych UDDI definiuje ogólną strukturę do przechowywania informacji o firmie i usługach internetowych, które publikuje. Model danych UDDI jest całkowicie rozszerzalny i obejmuje kilka powtarzających się sekwencji sekwencji informacji.

Jednak WSDL jest używany do opisu interfejsu usługi WWW. WSDL jest dość prosty w użyciu z UDDI.

WSDL jest reprezentowany w UDDI przy użyciu kombinacji informacji businessService, bindingTemplate i tModel .
Podobnie jak w przypadku każdej usługi zarejestrowanej w UDDI, ogólne informacje o usłudze są przechowywane w strukturze danych businessService , a informacje dotyczące sposobu i miejsca uzyskiwania dostępu do usługi są przechowywane w jednej lub kilku powiązanych strukturach bindingTemplate . Każda struktura bindingTemplate zawiera element, który zawiera adres sieciowy usługi i ma skojarzoną z nim jedną lub więcej struktur tModel , które opisują i jednoznacznie identyfikują usługę.
Gdy UDDI jest używany do przechowywania informacji WSDL lub wskaźników do plików WSDL, tModel powinien być określany zgodnie z konwencją jako typ wsdlSpec , co oznacza, że element overviewDoc jest wyraźnie zidentyfikowana jako wskazująca na definicję interfejsu usługi WSDL.
W przypadku UDDI zawartość WSDL jest podzielona na dwa główne elementy: plik interfejsu i plik implementacji.

Usługa sieciowa systemu rezerwacji Hertz stanowi konkretny przykład współpracy UDDI i WSDL. Oto <tModel> dla tej usługi internetowej -

<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>

Kluczowe punkty to -

Element OverviewURL podaje adres URL miejsca, w którym można znaleźć plik WSDL definicji interfejsu usługi. Pozwala to ludziom i narzędziom obsługującym UDDI / WSDL zlokalizować definicję interfejsu usługi.
Celem elementu keyedReference w categoryBag jest upewnienie się, że ten tModel jest sklasyfikowany jako dokument specyfikacji WSDL.

Obecnie dostępnych jest wiele implementacji UDDI. Te implementacje ułatwiają wyszukiwanie i publikowanie danych UDDI bez zagłębiania się w złożoność interfejsu API UDDI. Oto krótkie streszczenie głównych dostępnych implementacji UDDI.

Implementacje Java

Istnieją dwie implementacje UDDI dla języka Java.

UDDI4J (UDDI for Java) - UDDI4J został pierwotnie stworzony przez IBM. W styczniu 2001 IBM przekazał kod do własnej witryny open source. UDDI4J to biblioteka klas Java, która udostępnia interfejs API do interakcji z UDDI.
jUDDI - jUDDI to implementacja rejestru UDDI w języku Java o otwartym kodzie źródłowym oraz zestaw narzędzi do uzyskiwania dostępu do usług UDDI.

Implementacja Perla

UDDI::Lite - Zapewnia podstawowego klienta UDDI do zapytań i publikacji.

Implementacja Rubiego

UDDI4r - Zapewnia podstawowego klienta UDDI do zapytań i publikacji.

Implementacja Pythona

UDDI4Py - UDDI4Py to pakiet Pythona, który umożliwia wysyłanie żądań i przetwarzanie odpowiedzi z interfejsów API UDDI w wersji 2.

Projekt UDDI definiuje również zestaw definicji schematu XML, które opisują formaty danych używane przez różne interfejsy API specyfikacji. Wszystkie te dokumenty są dostępne do pobrania na stronie www.uddi.org . Bieżąca wersja wszystkich grup specyfikacji to wersja 2.0.

Specyfikacje obejmują:

Replikacja UDDI,
Operatorzy UDDI,
API programisty UDDI oraz
Struktury danych UDDI

Replikacja UDDI

W tym dokumencie opisano procesy i interfejsy replikacji danych, do których operator rejestru musi się dostosować, aby osiągnąć replikację danych między lokacjami. Ta specyfikacja nie jest API programisty; definiuje mechanizm replikacji używany między węzłami UBR.

Operatorzy UDDI

W tym dokumencie opisano zachowanie i parametry operacyjne wymagane przez operatorów węzłów UDDI. Niniejsza specyfikacja definiuje wymagania dotyczące zarządzania danymi, których operatorzy muszą przestrzegać.

API programisty UDDI

Ta specyfikacja definiuje zestaw funkcji obsługiwanych przez wszystkie rejestry UDDI w celu wysyłania zapytań o usługi hostowane w rejestrze oraz do publikowania informacji o firmie lub usłudze w rejestrze. Ta specyfikacja definiuje serię komunikatów SOAP zawierających dokumenty XML, które rejestr UDDI akceptuje, analizuje i na które odpowiada. Ta specyfikacja, wraz ze schematem interfejsu API UDDI XML i specyfikacją struktury danych UDDI, stanowi kompletny interfejs programistyczny do rejestru UDDI.

Struktury danych UDDI

Ta specyfikacja obejmuje specyfikę struktur XML zawartych w komunikatach SOAP zdefiniowanych przez API programisty UDDI. Ta specyfikacja definiuje pięć podstawowych struktur danych i ich wzajemne relacje.

Schemat interfejsu API XML UDDI nie jest zawarty w specyfikacji; jest raczej przechowywany jako dokument schematu XML, który definiuje strukturę i typy danych struktur danych UDDI.

UDDI i jego elementy w tym samouczku, a także zapoznaliśmy się z pełną architekturą i modelem danych UDDI.

Dowiedzieliśmy się o dwóch interfejsach UDDI: interfejsie wydawcy i interfejsie zapytań. Dowiedzieliśmy się również, jak rejestrować się i wyszukiwać usługi internetowe za pomocą UDDI.

Co dalej?

Następnym krokiem jest poznanie SOAP, WSDL i usług WWW.

MYDŁO

SOAP to prosty protokół oparty na języku XML, który umożliwia aplikacjom wymianę informacji za pośrednictwem protokołu HTTP.

Jeśli chcesz dowiedzieć się więcej o SOAP, odwiedź nasz samouczek dotyczący SOAP .

WSDL

WSDL jest standardowym formatem opisywania usługi WWW w formacie XML.

WSDL jest integralną częścią UDDI.

Jeśli chcesz dowiedzieć się więcej o WSDL, odwiedź nasz samouczek dotyczący WSDL .

Usługi internetowe

Usługi internetowe mogą konwertować aplikacje na aplikacje internetowe.

Jeśli chcesz dowiedzieć się więcej o usługach internetowych, odwiedź nasz samouczek dotyczący usług internetowych .

Oto kompletne odniesienie do interfejsów API UDDI Inquiry i interfejsów API publikowania UDDI.

Interfejsy API UDDI Inquiry

Nazwa API	Opis	V1.0	V2.0
find_binding	Wyszukuje powiązania szablonów skojarzone z określoną usługą.	Y	Y
znajdź_biznes	Wyszukuje firmy spełniające określone kryteria.	Y	Y
find_relatedBusinesses	Odkrywa biznes, który został powiązany z modelem uddi-org: relations.		Y
find_service	Wyszukuje usługę powiązaną z określoną firmą.	Y	Y
find_tModel	Wyszukuje rekordy tModel, które spełniają określone kryteria.	Y	Y
get_bindingDetail	Pobiera kompletny bindingTemplate dla każdego określonego bindingKey.	Y	Y
get_businessDetail	Pobiera pełną businessEntity dla każdego określonego businessKey.	Y	Y
get_businessDetailExt	Pobiera rozszerzony businessEntity dla każdego określonego businessKey.	Y	Y
get_serviceDetail	Pobiera rekord businessService dla każdego określonego klucza serviceKey.	Y	Y
get_tModelDetail	Pobiera rekord tModel dla każdego określonego tModelKey.	Y	Y

Interfejsy API publikowania UDDI

Nazwa API	Opis	V1.0	V2.0
get_authToken	Pobiera token autoryzacyjny. Wszystkie operacje interfejsu wydawcy wymagają przesłania prawidłowego tokenu autoryzacji wraz z żądaniem.	Y	Y
discard_authToken	Informuje rejestr UDDI, aby nie akceptował już danego tokenu autoryzacyjnego. Ten krok jest równoznaczny z wylogowaniem się z systemu.	Y	Y
save_business	Tworzy lub aktualizuje informacje podmiotu gospodarczego zawarte w rejestrze UDDI.	Y	Y
save_service	Tworzy lub aktualizuje informacje o usługach internetowych świadczonych przez podmiot gospodarczy.	Y	Y
save_binding	Tworzy lub aktualizuje informacje techniczne o wdrożeniu usługi internetowej.	Y	Y
save_tModel	Tworzy lub aktualizuje rejestrację pojęć abstrakcyjnych zarządzanych przez rejestr UDDI.	Y	Y
delete_business	Całkowicie usuwa dane podmioty gospodarcze z rejestru UDDI.	Y	Y
delete_service	Całkowicie usuwa określone usługi sieci Web z rejestru UDDI.	Y	Y
delete_binding	Usuwa dane techniczne usługi WWW z rejestru UDDI.	Y	Y
delete_tModel	Usuwa określone tModels z rejestru UDDI.	Y	Y
get_registeredInfo	Zwraca podsumowanie wszystkiego, co rejestr UDDI aktualnie śledzi dla użytkownika, w tym wszystkie firmy, wszystkie usługi i wszystkie tModele.	Y	Y
set_publisherAssertions	Zarządza wszystkimi śledzonymi potwierdzeniami relacji powiązanymi z indywidualnym kontem wydawcy.		Y
add_publisherAssertions	Powoduje, że co najmniej jeden wydawca zostanie dodany do zbioru potwierdzeń pojedynczego wydawcy.		Y
delete_publisherAssertions	Powoduje usunięcie co najmniej jednego elementu publisherAssertion z kolekcji asercji wydawcy.		Y
get_assertionStatusReport	Zapewnia obsługę administracyjną w zakresie określania stanu bieżących i oczekujących potwierdzeń wydawców, które obejmują dowolne rejestracje biznesowe zarządzane przez indywidualne konto wydawcy.		Y
get_publisherAssertions	Uzyskuje pełny zestaw potwierdzeń wydawcy, który jest powiązany z indywidualnym kontem wydawcy.		Y

Kod błędu

Pełne odniesienie do kodów błędów zwracanych przez interfejsy API UDDI jest takie, jak podano -

Kody błędów