WSDL (Web Services Description Language)
1. Garsc ogolnikow
WSDL jest bazujacym na XML’u jezykiem sluzacym do definiowania i opisu korzystania z Web Serwisow. Jest to XML’owy format opisujacy serwisy jako kolekcję punktow koncowych (odpowiednich URI do których wysylane sa żądania) , które mogą przesylac dane zawierajace dokumenty lub parametry/wyniki zdalnych metod.
W pewnym stopniu można tutaj dostrzec podobienstwo np. z IDL’em CORBY, gdyz oba sluza do definiowania interfejsow i typow, jednak z drugiej
strony oferuje szerszy zakres mozliwosci, które pozwalaja uzywac WSDL’a w nastepujacy sposób:
Do dokladnie daje WSDL:
WSDL wytworzyl oddzielne definicje i terminologie do definiowania Web Serwisu, koncowego punktu komunikacyjnego, w którym znajduje się Web Serwis, informacji o wejsciowych oraz wyjsciowych komunikatach dla Web
Serwisu i abstrakcyjnego sposobu deklarowania wiazan z konkretnymi protokolami i formatami danych.Wszystko co jest zdefiowane poprzez wewnatrz plliku WSDL jest abstrakcyjne: to tylko definicje parametrow i wiezow opisujacych, jak powinna odbywac się komunikacja. Implementacja Web Serwisu powinna stosowac się do definicji podanych w pliku WSDL, ale pozostawiona tu jest pewna elastycznosc. WSDL umozliwia również definiowanie wiazania miedzy abstrakcyjnym zbiorem definicji komunikatow z konkretnymi protokola
mi i formatami danych. WSDL definiuje od razu rozszerzenia dla wiazan z: SOAP 1.1, HTTP GET, HTTP POST oraz MIME.Ponieważ WSDL jest abstrakcyjnym opisem interfejsow Web Serwisu możliwe jest obecnie zarówno czesciowe wygenerowanie kodu implementacji Web Serwisu o ile dane sa definicje WSDL, jak i wygenerowanie definicji WSDL jeśli dany jest kod implementujacy Web Serwis.
Podobno lepiej jest najpierw budowac podstawowa, dzialajaca implementacje , a nastepnie przy uzyciu odpowiednich narzedzi wygenerowac definicje WSDL. Przykladowe narzedzia, które udostepniaja taka funkcjinalnosc to np. BEA’s WebLogic Server 6.1 (umozliwia utworzenie EJD lub JMS miejsca przeznaczenia i udostepnia skrypty Ant do utworzenia WSDL ‘a skojarzonego z implementacja) lub Systinet WASP, IBM ‘s Web Services Toolkit.
2. Opis struktury dokumentu WSDL
Opisane sa tutaj glowne elementy, które
mogą pojawic się w dokumencie WSDL. (*) oznacza, ze element może pojawic się wiecej niż raz. Elementy dotyczace wiazan (SOAP, HTTP) nie sa tutaj umieszczone (dla prostoty i wiekszeje wygody):<definitions>
<import>*
<types>
<schema></schema>*
</types>
<message>*
<part></part>*
</message>
<PortType>*
<operation>*
<input></input>
<output></output>
<fault></fault>*
</operation>
</PortType>
<binding>*
<operation>*
<input></input>
<output></output>
</operation>
</binding>
<service>*
<port></port>*
</service>
</definitions>
3. Krotka specyfikacja poszczegolnych elementow
<definitions>
- dziala jak kontener na opis serwisu. Udostepnia miejsce globalne deklaracje przestrzeni nazw, które maja być widoczen przez reszte dokumentu. Przykład (<definitions> element z XML Encoding Rules) – niektóre przestrenie nazw zdefiniowane w tym elemencie maja prefiksy (xsdm soapenc, xer, itd.), a niektóre nie. Prefiksy sa zwiazane z konkretnymi przestrzeniami nazw, ale nie okreslaja, które schemy (schemas) sa rzeczywiscie dostepne dla schema processor:<definitions
targetNamespace=”urn:3950”
xmlns=”
http://schemas.xmlsoap.org/wsdl/”xmlns:xsd=”
http://www.w3.org/2001/XMLSchema”xmlns:soap=”
http://schemas.xmlsoap.org/wsdl/soap/”xmlns:soapenc=”
http://schemas.xmlsoap.org/soap/encoding/”xmlns:tns=”urn:3950”
>
Nie wszystkie uzyte URI sa prawdziwe (dostepne w sieci) i wskazuja na dokumenty XML Schema nie dostepne w Internecie.
Atrybut targetNamespace definiuje przestrzen nazw, która tworzy ten dokument.
Table 5-1 Najczesciej spotykane w dokumentach WSDL prefiksy przestrzeni nazw i odpowiadajace im URI.~ | ||
Prefiks |
URI dla przestrzeni nazw |
Opis |
wsdl |
http://schemas.xmlsoap.org/wsdl/ |
Namespace of WSDL grammar. |
soap |
http://schemas.xmlsoap.org/wsdl/soap/ |
Namespace of WSDL extension binding for SOAP message. |
http |
http://schemas.xmlsoap.org/wsdl/http/ |
Namespace of WSDL extension binding HTTP protocol. |
mime |
http://schemas.xmlsoap.org/wsdl/mime/ |
Namespace of WSDL extension binding for MIME protocol. |
soapenc |
http://schemas.xmlsoap.org/soap/encoding/ |
Namespace of schema governing SOAP 1.1 encoding. |
soapenv |
http://schemas.xmlsoap.org/soap/envelope/ |
Namespace of schema governing SOAP 1.1 envelopes. |
xsi |
http://www.w3.org/2000/10/XMLSchema-instance |
Namespace of schema governing XML Schema instances. An instance is an XML document that conforms to a given XML Schema (.xsd) file. |
xsd |
http://www.w3.org/2000/10/XMLSchema |
Namespace of schema governing XML Schema (.xsd) files. |
tns |
(application or context-dependent) |
Namespace convention used to refer to the current WSDL document. The prefix is an acronym for “this namespace.” Assigning the targetNamespace value to this prefix is customary. |
<import>
- dziala podobnie do #include w C. Pozwala rozdzielic elementy serwisu do niezaleznych dokumentow i wlaczac je do glownego dokumentu w miare potrzeby. Poprawia to modularnosc oraz czytelnosc definicji serwisu.<definitions
targetNamespace=”urn:3950”
xmlns=”
http://schemas.xmlsoap.org/wsdl/”xmlns:xsd=”
http://www.w3.org/2001/XMLSchema”xmlns:soap=”
http://schemas.xmlsoap.org/wsdl/soap/”xmlns:soapenc=”
http://schemas.xmlsoap.org/soap/encoding/”xmlns:tns=”urn:3950”
>
<import namespace=”
http://asf.gils.net/xer”location=”
http://asf.gils.net/xer/ez.xsd”/><types>
- dziala jak kontener do definiowania typow danych uzywanyc w elemencie <message>. <message> definiuje format komunikatow wymienianych miedzy klientem i Web Serwisem.Element <types> zawiera zero lub wiecej podelementow <schema>, które musza stosowac się do regul dotyczacych dokumentow XML Schema.
I oczywiście przykład
(najpierw z uzyciem compelxType):<types>
<xsd:schema xmlns:xsd=”
http://www.w3.org/2001/XMLSchema”><xsd:element name=”PDU” type=”PDU”/>
<xsd:complexType name=”PDU”>
<xsd:choice>
<xsd:element name=”initRequest” type=”InitializeRequest” />
<xsd:element name=”initResponse” type=”InitializeResponse” />
<xsd:element name=”searchRequest” type=”SearchRequest” />
<xsd:element name=”searchResponse” type=”SearchResponse” />
<xsd:element name=”presentRequest” type=”PresentRequest” />
<xsd:element name=”presentResponse” type=”PresentResponse” />
<xsd:element name=”deleteResultSetRequest”
type=”DeleteResultSetRequest” />
<xsd:element name=”deleteResultSetResponse”
type=”DeleteResultSetResponse” />
<xsd:element name=”accessControlRequest”
type=”AccessControlRequest” />
<xsd:element name=”accessControlResponse”
type=”AccessControlResponse” />
<xsd:element name=”resourceControlRequest”
type=”ResourceControlRequest” />
<xsd:element name=”resourceControlResponse”
type=”ResourceControlResponse” />
<xsd:element name=”triggerResourceControlRequest”
type=”TriggerResourceControlRequest” />
<xsd:element name=”resourceReportRequest”
type=”ResourceReportRequest” />
<xsd:element name=”resourceReportResponse”
type=”ResourceReportResponse” />
<xsd:element name=”scanRequest” type=”ScanRequest” />
<xsd:element name=”scanResponse” type=”ScanResponse” />
<xsd:element name=”sortRequest” type=”SortRequest” />
<xsd:element name=”sortResponse” type=”SortResponse” />
<xsd:element name=”segmentRequest” type=”Segment” />
<xsd:element name=”extendedServicesRequest”
type=”ExtendedServicesRequest” />
<xsd:element name=”extendedServicesResponse”
type=”ExtendedServicesResponse” />
<xsd:element name=”close” type=”Close” />
</xsd:choice>
</xsd:complexType>
Nastepny przykład, tym ra
zem z uzyciem SimpleType:<xsd:simpleType name=”KnownProximityUnit”>
<xsd:restriction base=”xsd:string”>
<xsd:enumeration value=”character” />
<xsd:enumeration value=”word” />
<xsd:enumeration value=”sentence” />
<xsd:enumeration value=”paragraph” />
<xsd:enumeration value=”section” />
<xsd:enumeration value=”chapter” />
<xsd:enumeration value=”document” />
<xsd:enumeration value=”element” />
<xsd:enumeration value=”subelement” />
<xsd:enumeration value=”elementType” />
<xsd:enumeration value=”byte” />
</xsd:restriction>
</xsd:simpleType>
<message> -
element uzywany do modelowania wymienianych danych, jako czesci Web Serwisu. Elementy <message> wskazuja typy zdefiniowane w sekcji <types>. Dane zawarte w <message> sa abstrakcyjne. Komunikat sklada się z jednego lub wielu podelementow <part>. Pojedyncze elementy <part> identyfikuja poszczegolne partie danych, które skladaja się na ten komunikat z danymi oraz typy danych do których odnosza się poszczegolne partie danych.Przykład:
<message name=”soapHeader”>
<part type=”xsd:string” name=”id”/>
<part type=”xsd:string” name=”timeout”/>
</message>
Zasada dzialania: klient przesyla do serwisu komuniakt z zadaniem lub danymi wejsciowymi, otrzymuje zas odpowiedz lub dane wyjsciowe. Porządek elementow <part
> ozwierciedla kolejnosc parametrow wywolywanej zdalnie metody.<portType>
- element specyfikuje podzbior operacji wspieranych przez punkt koncowy danego Web Serwisu. W pewnym sensie, <portType> dostarcza unikatowego identyfikatora do grupy akcji, ktore mogą być wykonane w pojedynczym punkcie koncowym.<operation>
- jest to abstrakcyjna definicja akcji wspieranej przez Web Serwis. Element ten jest analogiczny do definicji metoidy w Javie. Operacja WSDL może mieć komunikaty typu wejscioweg i wyjsciowego jako czesci wykowywanej akcji. Tag <operation> definiuje nazwe operacji przy uzyciu atrybutu name, komunikaty wejsciowe i wyjsciowe sa definiowane przez podelementy <input> oraz <output>. Odnosza się one do elementow <message> zdefiniowanych w tym samym lub zaimportowanym dokumencie WSDL. Element <message> może reprezentowac zadanie, odpowiedz lub sygnalizacje bledu. Elementy <operation> sa pogrupowane w zaleznosci od ich zachowania (typy transmisji miedzy klientem, a portem):• Request-response – port otrzymuje zadanie i odsyla wynik (<input>, <output>, <fault>)
Wartosc przypisana atrybutowi name dla kazdego elementu <operation> musi
być unikatowa w zakresie elementu <portType>. Analogicznie ma się sprawa z <input> i <output>, których nazwy musza być unikatowe w zakresie <portType>, a nie tylko <operation>.<binding>
- element oznacza konkretny protokol i specyfikacje formatu danych dla danego elementu <portType>. To w tym miejscu uzywa się rozszerzen do wiazania (czyli wiazanie z HTTP, SOAP lub MIME – ewentualnie wlasny protokol).Ponieważ w dokumencie WSDL elementy <operation> sa już zdefiniowane, element <binding> mapuje abstrakcyjn
e definicje operacji, ich wejscowych i wyjscowych komunikatow do odpowiedniego protokolu uzywanego przez Web Serwis.<service> -
jest to element pojawiajacy się typowo na koncu dokumentu WSDL i identyfikujacy dany Web Serwis (nigdzie wczesniej URL okreslajacy, gdzie znajduje się Web Serwis nie był podawany). Element ten jest uzywany tylko wtedy, gdy opisywany jest rzeczywisty punkt koncowy Web Serwisu (WSDL jest uzywany przede wszystkim do opisu abstrakcyjnego interfejsu). Element <service> grupuje jeden lub wiecej elemetow <port>. Pojedynczy element <port> reprezentuje punkt koncowy (punkt dostepu) do Web Serwisu.Przykład:
<service name=”Oxford University Libraries”>
<documentation>
Z39.50 Server for Oxford University Libraries
</documentation>
<port name=”OLIS” binding=”ez:ez3950SOAPBinding”>
<soap:address location=”
http://jafer.las.ox.ac.uk/ez3950”/></port>
</service>
Opcjonalny podelement <documentation> opisuje Web Serwis. Atrybut binding odnosi
się o elementu <binding> zawartego w tym samym lub zaimportowanym dokumencie WSDL. <soap:address> identyfikuje URL Web Serwisu.4. Kilka uwag koncowych
Po pierwsze nie należy definiowac zbyd duzo operacji i komunikatow – nic ponadto co jest naprawde potrzebne. Należy tez pamietac, ze WSDL nie jest kodem programu, a metadanymi dotyczacymi kodu. Nie należy dlaczac niczego, czego klient Web Serwisu nie musi wiedziec, żeby z niego skorzystac. Żeby zapewnic niezaleznosc od platformy jako system typow należy uzywac XML Schema, kiedy tylko jest to możliwe.
UDDI (Universal Description Discovery and Integration)
1. Kilka uwag ogolnych
UDDI jest rejestrem dla Web Serwisow. Pomaga znalezc serwis oraz jego opis (WSDL). Dostarcza zestandaryzowane metody do publikowania i odkrywania informacji dotyczacych Web Serisow. Umozliwia wyszukiwanie po rodzaju prowadzonej dzialalnosci oraz wyszukiwanie po typie serwisu. Rejestr UDDI jest rozproszony pomiedzy wiele wezlow, a dane sa replikowane w wezlach. Co jest istotne, to fakt, ze specyfikacja UDDI ma wsparcie ze strony najwiekszych przedsiebiorstw, a priorytetem jest przenosnosc i latwosc adaptacji Web Serwisow.
Ogolnie w rejestrze UDDI
mogą być zarejestrowane trzy typy informacji:White pages
Podstawowe informacje o danej firmie (nazwa, adres, informacje kontaktowe oraz jakies unikatowe identyfikatory) – pozwala lokalizowac Web Serwis na podstawie danych identyfikujacych dana firme.
Yellow pages
Informacja opisujaca Web Serwis przy uzyciu roznych klasyfikacji. Pozwala lokalizowac Web Serwis względem klasy dostarcznych uslug (np. handel, reczny wyrob jakichs dobr itd...).
Green pages
Techniczne informacje opisujace zachowania i wspie
rane funkcje Web Serwisu udostepnioanego przez dana firme. Znajduja się tu wskazania na przykład konkretnie do lokalizacji Web Serwisu.2. Uzycie UDDI
Analityk biznesowy może uzywac UDDI jak wyszukiwarki Web Serwisow. Producenci oprogramowania uzywaja API do UDDI żeby publikowac serwisy, wyszukiwac serwisy wedlug zadanych kryteriow.
Jak to mniej wiecej może wygladac
3. Architektura UDDI
UDDI Business Registry (UBR) – koncepcyjnie jest to pojedynczy system zbudowany z wielu wezlow, których dane sa synchronizowane przy pomocy replikacji.
Dodawanie i aktualizacja danych
Z zalozenia UBR oferuje publiczne rejestry Web Serwisow, umozliwia przedsiebiorstwom reklamowanie swojej dzialalnosci i pozwala na wyszukanie potencjalnych partnerow biznesowych. Przedsiebiorstwa
mogą rejestrowac się u dowolnego operatora i te same informacje po pewnym czasie będą znajdywaly się u kazdego operatora (po najblizszej replikacji). Dla wszystkich operatorow jest wspolne SOAP API.Oczywiście UDDI nie oznacza wylacznie UBR – możliwe sa zarownoprywatne wezly, nie bedace czescia UBR, jak i prywatne sieci wezlow, które synchronizuje się miedzy soba, ale nie oddzialuja w żaden sposób z UBR.
Produkty, które umozliwiaja utworzenie wlasnych publicznych oraz prywatnych rejestrow UDDI, to np. BEA WebLogic Server i IBM WebSphere.
4. Specyfikacja UDDI
Projekt UDDI okresla zbior definicji XML Schema opisujacych formaty danych uzywanych przez rozne API. Dokladnie informacje znajduja się na stronie:
http://www.uddi.org.5. Rozne API bazujace na Javie
Specyfikacja UDDI nie definiuje API do bezposredniego dostepu do rejestru UDDI. Zamiast tego zdefiniowany jest szereg komunikatow SOAP, które rejestr może zaakceptowac. Stad dostep do UDDI można uzyskac na
kilka sposobow:SOAP API
bazujace na JavieUzycie komuniaktow SOAP zawierajacych dokument UDDI XML. Każdy taki XML’owy dokument powinien być wstawion w tresc komuniaktu SOAP (musi mieć odpowiedni format).
custom Java-based UDDI client API
Istnieja API (stworzona np. przez Systient) w których strukturom danych UDDI odpowiadaja klasy Javy – umozliwia to odwolanie do rejestru UDDI bez znajomosci specyfiki SOAP lub komunikatow XML i struktur danych UDDI.
JAXR
Specyfikacja definiujaca zestandaryzowane sposoby odwolywania
się do rejestrow (nie tylko UDDI).6 Co znajduje się w rejestrze
7. UDDI – pobiezny opis struktur danych
Powiazania pomiedzy glownymi strukturami danych UDDI
<businessEntity>
- reprezentuje przesiebiorstwo (informacje kontaktowe, opis, kategorie dzialalnosci, identyfikatory)<publisherAssertion>
- uzywany, żeby ustanowic publiczny zwiazek pomiedzy dwiema strukturami <businessEntity>. Taki zwiazek jest widoczny publicznie, jeśli oba przedsiebiorstwa utworzyly dwa oddzielne dokumenty <publisherAssertion> wskazujace na siebie.<businessEntity>
zawiera jedna lub wiecej strukture <businessService>, która reprezentuje pojedyncza, logiczna klasyfikacje serwisu. Element ten jest uzywany do opisu zbioru serwisow udostepnianych przez przedsiebiorstwo.<businessService>
zawiera jedna lub wiecej strukture <bindingTemplate>. Jest to wskazanie do opisu technicznego i punktu dostepu (URL) – nie zawiera szczegolow specyfikacji serwisu. Zawiera wskazania na jedna lub wieceje struktur <tModel>. <tModel> nie udostepnia specyfikacji Web Serwisu bezposrednio, za to zawiera wskazania do lokacji w których znajduja się rzeczywiste specyfikacje.8. Wyszukiwanie informacji
Przyklady kilku komunikatow uzywanych do zdobywania informacji o przedsiebiorstwie. Wszystkie komunikaty uzywaja SOAP (UUID – universally unique identifier sluzacy do identyfikowania instancji struktur UDDI).
Table 6-2. XML documents used in browsing inquiry messages |
||
Message name |
Response document |
Brief description |
<find_binding> |
<bindingDetail> |
Given a UUID to a <businessService> structure, this message retrieves zero or more <bindingTemplate> structures within a single <bindingDetail> structure matching the criteria specified in the input arguments. |
<find_business> |
<businessList> |
Given a regular expression, business category, business identifier, or <tModel>, this message retrieves zero or more <businessInfo> structures contained within a single <businessList> structure that meet the criteria specified in the input arguments. |
<find_relatedBusinesses> |
<relatedBusinessesList> |
Given the UUID of a <businessEntity>, this message returns a list of UUIDs contained within a <relatedBusinessList> structure for the other businesses that have a relationship with this business. |
<find_service> |
<serviceList> |
Given the UUID of a <businessEntity> and either the name of the service, the <tModel> of an implemented specification, or the service category, this message returns a list of all matching <businessService> documents contained within a <serviceList> structure. |
<find_tModel> |
<tModelList> |
Given the a name, a category, or identifier, this message returns all matching <tModel> structures contained within a <tModelList> structure. |
9. P
rzykład uzycia JAXR:Wymaga Tomcat’a do zaimplementowania klienta, ale prawdopodobnie niedlugo (o ile już nie teraz) nie będzie wymagany żaden zewnetrzny serwer.
import javax.xml.registry.*;
import javax.xml.registry.infomodel.*;
import java.net.*;
import java.util.*;
/*
• This is the FindBusiness UDDI example implemented using
• the JAXR libraries and the reference implementation
• JAXR provider for accessing a UDDI registry.
*/
public class JAXRFindBusiness {
public JAXRFindBusiness( ) {}
public static void main(String[] args) {
if (args.length != 1) {
System.out.println(“Usage: java “ +
“JAXRFindBusiness <query-string>”);
System.exit(1);
}
String queryString = new String(args[0]);
System.out.println(“Query string is “ + queryString);
doQuery(queryString);
}
public static void doQuery(String qString) {
Connection conn = null;
// Define connection configuration properties // To query, you need only the query URL Properties props = new Properties( );
props.setProperty(“javax.xml.registry.queryManagerURL”,
“
http://localhost:8080/wasp/uddi/inquiry/”);props.setProperty(“javax.xml.registry.factoryClass”,
“com.sun.xml.registry.uddi.ConnectionFactoryImpl”);
try {
// Create the connection, passing it the
// configuration properties
ConnectionFactory factory =
ConnectionFactory.newInstance( );
factory.setProperties(props);
conn = factory.createConnection( );
// Get registry service and query manager
RegistryService rs = conn.getRegistryService( );
BusinessQueryManager bqm = rs.getBusinessQueryManager( );
// Define find qualifiers and name patterns
Collection qualifiers = new ArrayList( );
qualifiers.add(FindQualifier.SORT_BY_NAME_DESC);
Collection namePatterns = new ArrayList( );
namePatterns.add(qString);
// Find using the name
BulkResponse response =
bqm.findOrganizations(qualifiers,
namePatterns, null, null, null, null);
Collection orgs = response.getCollection( );
// Display information about the organizations found
Iterator orgIter = orgs.iterator( );
while (orgIter.hasNext( )) {
Organization org =
(Organization) orgIter.next( );
System.out.println(“Org name: “ + getName(org));
System.out.println(“Org description: “ +
getDescription(org));
System.out.println(“Org key id: “ + getKey(org));
// Display primary contact information
User pc = org.getPrimaryContact( );
if (pc != null) {
PersonName pcName = pc.getPersonName( );
System.out.println(“ Contact name: “ +
pcName.getFullName( ));
Collection phNums =
pc.getTelephoneNumbers(pc.getType( ));
Iterator phIter = phNums.iterator( );
while (phIter.hasNext( )) {
TelephoneNumber num =
(TelephoneNumber) phIter.next( );
System.out.println(“ Phone number: “ +
num.getNumber( ));
}
Collection eAddrs = pc.getEmailAddresses( );
Iterator eaIter = eAddrs.iterator( );
while (phIter.hasNext( )) {
System.out.println(“ Email Address: “ +
(EmailAddress) eaIter.next( ));
}
}
// Display service and binding information
Collection services = org.getServices( );
Iterator svcIter = services.iterator( );
while (svcIter.hasNext( )) {
Service svc = (Service) svcIter.next( );
System.out.println(“ Service name: “ +
getName(svc));
System.out.println(“ Service description: “ +
getDescription(svc));
Collection serviceBindings =
svc.getServiceBindings( );
Iterator sbIter = serviceBindings.iterator( );
while (sbIter.hasNext( )) {
ServiceBinding sb =
(ServiceBinding) sbIter.next( );
System.out.println(“ Binding “ +
“Description: “ +
getDescription(sb));
System.out.println(“ Access URI: “ +
sb.getAccessURI( ));
}
}
// Print spacer between organizations
System.out.println(“ --- “);
}
} catch (Exception e) {
e.printStackTrace( );
} finally {
// At end, close connection to registry
if (conn != null) {
try {
conn.close( );
} catch (JAXRException je) {}
}
}
}
private static String getName(RegistryObject ro) throws JAXRException {
try {
return ro.getName().getValue( );
} catch (NullPointerException npe) {
return “”;
}
}
private static String getDescription(RegistryObject ro) throws JAXRException {
try {
return ro.getDescription().getValue( );
} catch (NullPointerException npe) {
return “”;
}
}
private static String getKey(RegistryObject ro) throws JAXRException {
try {
return ro.getKey().getId( );
} catch (NullPointerException npe) {
return “”;
}
}
}
JAXR uses
javax.xml.registry for the base package name for all of its classes. The main( ) method for this program parses a single parameter, which is the query string to use as the business name in the request:import javax.xml.registry.*;
import javax.xml.registry.infomodel.*;
import java.net.*;
import java.util.*;
/*
• This is the FindBusiness UDDI example implemented using
• the JAXR libraries and the reference implementation
• JAXR provider for accessing a UDDI registry.
*/
public class JAXRFindBusiness {
public JAXRFindBusiness( ) {}
public static void main(String[] args) {
// Parameter parsing, not entirely relevant
doQuery(queryString);
}
Najpierw tworzone jest polaczenie z dostarczycielem serwisu (tutaj jest to lokalny rejestr UDDI:
http://localhost:8080/wasp/uddi/inquiry/. ). Po ustanowieniu polaczenia z dostarczycielem serwisu, tworzone jest polaczenie z obiektem RegistryService (ten obiekt mowi nam z jakim rejestrem mamy do czynienia)..
10. Uzywanie WSDL z UDDI
WSDL jest uzywany do opisu interfejsu Web Serwisu. Dokument UDDI <tModel> udostepnia metadane bedace opisami Web Serwisu i wskazania do specyfikacji opisujacych ich implementacje. Dokumenty WSDL wiaza się ze strukturami UDDI w kilku miejscach:
Dla implementacji Web Serwisu z pojedynczym punktem dostepu zdefiniowanegi pojedynczym dokumentem WSDL powinien
być utworzony jeden <tModel>, jeden <bindingTemplate> i jeden <businessService>.Przykład:
<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>
URL do dokumentu WSDL opisujacego ten serwis jest zapisany jako wartosc <overviewURL>.