Java 1 - Kolos

Transkrypt

Java 1 - Kolos

Uniwersytet Łódzki
Wydział Matematyki i Informatyki,
Katedra Analizy Nieliniowej
UDDI & WSDL
wykład 10
Programowanie w Javie 2
mgr inż. Michał Misiak
WSDL (1)





Web Services Description Language
Bazuje na XML
Służy do definiowania i opisu usług sieciowych
Opisuje serwis jako kolekcja punktów końcowych (URI,
na które wysyłane są żądania)
WSDL:



Opisuje jakie usługi są udostępniane przez WS
W jaki sposób wywoływać jego operacje
Gdzie można znaleźć WS
Wydział Matematyki i Informatyki UŁ, Katedra Analizy Nieliniowej, M.Misiak © 2008
WSDL (2)

Zawiera definicje i terminologie pozwalające na:
 Definiowanie
WS
 Definiowanie punktu końcowego
 Informacji o wyjściowych i wejściowych komunikatach
 Abstrakcyjny sposób deklarowania wiązań z
protokołami i formatami danych

WSDL umożliwia częściowe wygenerowanie
kodu usługi sieciowej
Elementy WSDL













<definitions>
<import>*
<types>
<schema></schema>*
</types>
<message>*
<part></part>*
</message>
<PortType>*
<operation>*
<input></input>
</service>
</definitions>












<output></output>
<fault></fault>*
</operation>
</PortType>
<binding>*
<operation>*
<input></input>
<output></output>
</operation>
</binding>
<service>*
<port></port>*
Przykłady elementów



<definitions> - kontener na opis serwisu.
<import> - zachowuje się podobnie do #include w C.
Umożliwia podział elementów serwisu do niezależnych
dokumentów. Zwiększa to modularność oraz czytelność
definicji serwisu.
<types> - kontener do definiowania typów danych, które
są używane w elemencie <message>. <message>
określa format komunikatów wymienianych miedzy
klientem i WS.
Przykłady elementów



<message> - element, który wykorzystywany jest do przesyłania danych
pomiędzy klientem, a WS. Element wykorzystuje typy zdefiniowane w sekcji
<types>. Komunikat zbudowany z jednego lub wielu pod elementów <part>.
Pojedyncze elementy <part> identyfikują poszczególne partie danych
<portType> - wyszczególnia zbiór operacji udostępnianych przez punkt
końcowy WS.
<operation> - abstrakcyjna definicja akcji wspieranej przez WS. Analogia
do definicji metody w Javie. Dana Operacja WSDL może używać
komunikatów wejściowych i wyjściowych jako części wykowywanej akcji.


<operation> definiuje nazwe operacji przy uzyciu atrybutu name,
komunikaty wejsciowe i wyjsciowe sa definiowane przez podelementy <input>
oraz <output>.
 Elementy <input> <output> odnoszą się do elementów <message>.
Przykład elementów (3)



<binding> - element określa konkretny protokół oraz
specyfikacje formatu danych dla danego elementu
<portType>. Wiązanie z HTTP, SOAP lub MIME
<service> - element znajdujący się na końcu dokumentu
WSDL, identyfikujący dany WS. Element <service>
może grupować jeden lub więcej elementów <port>.
Element <port> określa punkt końcowy (punkt dostępu)
do WS.
UDDI




Universal Description, Discovery and Integration
Projekt UDDI specyfikuje standardowy sposób publikowania i
odkrywania informacji na temat usług sieciowych
Projekt jest dostępny na stronie www.uddi.org
Projekt jest prowadzony przez UDDI Community składające się z:
Working Group (rozwój specyfikacji)
 Advisory Group (określanie wymagań oraz akceptacja specyfikacji


Sposoby odkrywania usług oferowanych przez partnerów
biznesowych:
Ręczne – dobre w prostych sytuacjach, komplikuje się przy wielu
usługach i partnerach biznesowych
 Automatyczne -> UDDI

Rejestr UDDI


Rejestr UDDI jako uniwersalne miejsce do wymiany informacji o
usługach pomiędzy partnerami biznesowymi
Rejestr UDDI przechowuje 3 typy informacji:
White pages – podstawowa informacja kontaktowa oraz identyfikator
firmy zawierający nazwę, adres, dane kontaktowe oraz unikalny
identyfikator (np. NIP). Informacja ta pozwala innym na odkrycie usług
po przez rodzaj i nazwę firmy.
 Yellow pages – informacja, która opisuje usługi z wykorzystaniem
różnej kategoryzacji – taksonomia. Odkrywanie usługi odbywa się na
bazie podziału taksonomicznego np. fabryka, czy wypożyczalnia
samochodów
 Green pages – informacja techniczna, która opisuje zachowanie oraz
wspierane funkcje usług sieciowych dostarczanych przez firmę. Dane te
zawierają wskaźnik na WS oraz gdzie są zlokalizowane.

Używanie UDDI

Sposób wykorzystania w zależności od perspektywy, kto
je wykorzystuje:


Analityk biznesowy – przeglądarka pozwalająca wyszukać
odpowiadający proces biznesowy. Analityk może chcieć
przeglądać różne UDDI oraz specyfikacje różnych WS
Programiści – wykorzystują API UDDI do publikacji WS oraz
odkrywania WS na bazie określonych kryteriów. Możliwe do
wyobrażenia, że aplikacja sama odkryje usługę i użyje jej bez
interakcji człowieka
Architektura UDDI
Specyfikacja
UDDI
UDDI
Schema
REPLIKACJA
Rejestr
operatorów
Rejestr
operatorów
Ogólny
Rejestr UDDI
(UDDI Business Registry)
Rejestr
operatorów
Rejestry UDDI




UBR – UDDI Business Registry – „chmura rejestrów”
Możliwość tworzenia prywatnych rejestrów operatorów
nie wchodzących w skład UBR
Prywatne rejestry UDDI wykorzystywane przy obsłudze
procesów biznesowych wewnętrznych bądź B2B
Aktualnie wiele produktów pozwala na kreację
prywatnych jak i również publicznych rejestrów UDDI:


BEA WebLogic Server, IBM WebSphere – serwer UDDI jako
część platformy J2EE
Systinet, HP, Oracle, SAP, Cape Clear – serwer UDDI
współpracujący z serwerem aplikacyjnym
Specyfikacja UDDI


UDDI definiuje szereg standardowych XML
Schema, które zawierają formaty danych
wykorzystywane przez różne API
XML Schema dla UDDI dostępne pod adresem:
http://www.uddi.org w wersji 2.0
Zawartość specyfikacji UDDI


Replikacja UDDI – dokument opisuje proces replikacji danych oraz
interfejsy, do których musi się dostosować operator w celu, aby móc
replikować dane w UDDI. Specyfikacja określa jedynie używany do
replikacji w węzłach
Operator UDDI – dokument opisuje zachowanie oraz parametry
operacyjne wymagane przez operatora węzła UDDI. Określa
wymagania związane z zarządzaniem danymi, do których operator
musi się dostosować
Odpowiedzialność operatora: zachowanie i bezpieczeństwo danych,
każda rejestracja posiada poprawny e-mail, zapewnienie spójności
danych przy kasowaniu
 Dokument ten nie posiada API oraz nie musi być implementowany
przez węzły prywatne

Zawartość specyfikacji UDDI (1)

Programistyczne API UDDI




określa zbiór funkcji, które rejestr UDDI dostarcza przy
odpytywaniu usług przechowanych w rejestrze oraz publikacji
danych biznesowych lub usług w UDDI.
Definiuje zbiór wiadomości SOAP, które serwer UDDI akceptuje,
przetwarza i odsyła
Schema z UDDI XML API oraz struktury danych UDDI stanowią
pełen interfejs dla rejestru UDDI
Struktura danych UDDI


Specyfikuje struktury danych używane w wiadomościach SOAP
Specyfikacja zawiera 5 podstawowych struktur oraz relacje
pomiędzy nimi
Java API dla UDDI


Specyfikacja UDDI nie definiuje bezpośrednio API Javy,
jedynie wiadomości, które UDDI może akceptować
Kilka podejść do realizacji API Javy dla UDDI





Wykorzystać API Javy dla SOAP
Wykorzystać API Klienta dla UDDI dostarczone przez niezależne
firmy
Użyć JAXR
API UDDI zostały zaprojektowane w celu zapewnienia
prostoty
Każde żądanie do UDDI jest synchroniczne oraz ma
postać żądanie-odpowiedź, jest bezstanowe
Wykorzystanie API Javy dla SOAP



Wykorzystanie API do tworzenia wiadomości
SOAP zawierających dokument XML dla UDDI
Programista może tworzyć ręcznie dokumenty,
które będą umieszczane w ciele wiadomości
SOAP
Wymagana jest znajomość struktury wiadomości
SOAP akceptowanych przez UDDI oraz
poprawne jej formatowanie
Wykorzystanie API klienta UDDI




API dostarczane przez niezależnych producentów
wykorzystywane do dostępu do rejestru UDDI
API posiada klasy, które reprezentują struktury danych
oraz wspierają tworzenie wiadomości obsługiwanych
przez UDDI
API pozwala na interakcje z UDDI bez konieczności
znajomości specyfikacji SOAP lub wiadomości XML oraz
struktur danych
Dostarczone API jest zgodne ze specyfikacją UDDI co
pozwala na współpracę z różnymi rejestrami UDDI
Wykorzystanie JAXR




Specyfikacja JAXR definiuje standardowy
sposób dostępu z Javy do rejestru
JAXR pozwala na pisanie programów
posiadających dostęp do kilku różnych rejestrów
włączenie z UDDI i ebXML
Minusem możliwości wykorzystania do różnych
rejestrów jest konieczność wprowadzenia przez
JAXR warstwy abstrakcji.
JAXR jest w fazie wczesnego rozwoju
Programowanie UDDI







Specyfikacja opisuje dwa rodzaje API (publikacji i zapytania), które
wykorzystują różne dokumenty XML, struktury danych oraz punkty dostępu.
API Zapytanie (inquiry API) lokalizuje informacje na temat biznesu, usługi,
którą oferuje, jej specyfikacji tej usługi oraz postępowania w sytuacji
wystąpienia błędów
API zapytania nie wymaga autentykacji i jest przenoszone w ramach HTTP
API Publikacji (publishing API) – wykorzystywane do tworzenia,
przechowywania oraz aktualizacji informacji zlokalizowanej w UDDI
Wszystkie funkcje w API Publikacji wymagają autoryzacji w rejestrze UDDI
Rejestr UDDI przechowuje informacje na temat uprawnień. Dane potrzebne
do autoryzacji muszą być umieszczane jako parametr w XML, dla każdego
wołania
Zachowanie bezpieczeństwa wymaga zastosowania protokołu HTTPS
Przykłady zapytań
Operator
node
Inquiry URL
Publishing URL
HP
http://uddi.hp.com/inquire
https://uddi.hp.com/publish
IBM Test
http://www3.ibm.com/services/uddi/inquirya
pi
https://www3.ibm.com/services/uddi/protect/publish
api
Microsoft
Production
http://uddi.microsoft.com/inquire
https://uddi.microsoft.com/publish
Microsoft
Test
http://test.uddi.microsoft.com/inqu
ire
https://test.uddi.microsoft.com/publish
Struktury danych UDDI
<businessEntity>

Element reprezentuje podstawową informacje biznesową, która
zawiera:



Informacje kontaktowe
Wybraną kategorię
Identyfikatory
 Opis
 Relacje do innych elementów


Element ten pozwala firmom ustanowić relacje z innym na różne
sposoby.
Spółka matka może odwoływać się do spółek córek, deklarując
partnerstwo. Dana firma musi ustanowić unikalne <businessEntity> i
osobno zapisać relacje do innej firmy posiadającej własną strukturę
<businessEntity>.
<publisherAssertion>


Struktura <publisherAssertion> używana jest do
ustanowienia relacji pomiędzy dwoma
strukturami <businessEntity>.
Relacja widziana jest jedynie w sytuacji, gdy
obie firmy utworzą te samo skojarzenie w
oddzielnych dokumentach niezaleznie.
<businessService>


<businessEntity> zawiera jedną lub więcej struktur
<businessService>. <businessService> reprezentuje pojedynczy
logiczną usługę. Element <businessService> jest używany do opisu
zbioru usług udostępnianych biznesowi. Usługa ta może być WS lub
normalną usługą nie elektroniczną. Dokument <businessService>
jest ponownie wykorzystywany przez klika <businessEntity>.
UŁ może utworzyć usługę sieciową rejestracji i opublikować tą
usługę jako część „WS rejestracja studentów UŁ” struktury
<businessService>. Dodatkowo UŁ może wybrać każdą z jednostek
podległych jako osobny <businessEntity> od momentu, gdy każdy
wydział będzie miał własną infrastrukturę IT.
<bindingTemplate>







<businessService> zawiera jedno lub więcej struktur <bindingTemplate>.
<bindingTemplate> zawiera wskaźnik do nietechnicznych opisów i wskaźnik
do punktu dostępu URL, jednak nie zawiera szczegółów specyfikacji usługi.
<bindingTemplate> zawiera opcjonalnie opis w postaci tekstu, adres URL
punktu dostępu i referencje do <tModel>.
<tModel> jest abstrakcyjną opisem danej specyfikacji lub zachowania usługi
sieciowej.
<tModel> jest cyfrowym odciskiem określającym specyfikę jak korzystać z
WS.
<tModel> nie udostępnia w sposób bezpośredni specyfikacji usługi, ale
zawiera wskaźnik do lokalizacji aktualnych specyfikacji.
Firmy mogą wykorzystywać informacje wskazywaną przez <tModel> w celu
określenia, czy usługa jest kompatybilna z wymaganiami biznesowymi.
UUID




Instancje struktur danych UDDI identyfikowane są i
wskazywane przez uniwersalny identyfikator UUID
UUIDs są przypisywane, w momencie, gdy struktura
danych wstawiana jest do rejestru UUID.
UUID jest szesnastkowym ciągiem znaków, którego
struktura oraz algorytm generacji został zdefiniowany w
ISO/IEC 11578:1996. Standard gwarantuje unikalność
identyfikatora
Element <publisherAssertion> nie posiada UUID
Przeglądanie podstawowych
informacji


Zbiór wiadomości pozwala odpytywać UDDI w
zakresie informacji biznesowych, usługi
sieciowej lub meta danych
Elementy wykorzystywane w wiadomościach
przesyłanych do UDDI posiadają w swojej
nazwie find. Elementy te wykorzystywane są
jako element korzeń w żądaniu SOAP.
Przykłady żądań (1)

Żądanie: <find_binding>



<bindingDetail>
Zwraca UUID dla elementu <businessService>. Wiadomość ta
może odebrać zero lub więcej <bindingTemplate> z
pojedyńczym wpisem <bindingDetail> w zależności od kryteriów
podanych w argumentach wejściowych.
Żądanie: <find_business>


<businessList>
Zwraca wyrażenie regularne, dla kategorii usług, identyfikator
dostawcy usług lub <tModel>. Wiadomość ta odbiera zero lub
więcej elementów <businessInfo> zawartych w pojedynczym
elemencie <businessList>.
Przykłady żądań (2)

Żądanie <find_relatedBusinesses>



<relatedBusinessesList>
Zwraca UUID <businessEntity>. Wiadomość ta zwraca dla listę
UUID, które zawarte są w elemencie <relatedBusinessList> dla
dostawcy usług, który był powiązany z danym dostawcą usług.
Żądanie <find_service>


<serviceList>
Zwraca UUID <businessEntity> i nazwę usługi <tModel>
zaimplementowanej specyfikacji lub kategorię usługi.
Struktura odpowiedzi UDDI



UDDI zwraca dokument XML, który zawiera
podstawowe struktury UDDI, rzadziej jako same
struktury
Np. <find_business> zwraca 0 lub więcej
struktur <businessInfo> jednakże w strukturze
<businessList>
Struktury takie jak <businessList> istnieją
jedynie w celu grupowania elementów, podobnie
jak w kolekcjach Javy.
Przykład <find_business>



Zapytanie <find_business> zwraca <businessList>
Jako serwer UDDI można wykorzystać Systinet WASP UDDI
Systinet WASP UDDI zawiera:
Lokalny rejestr UDDI, który uruchmiany jest jako serwlet pod Apache
Tomcat 3.2.3
 Skrypty bazodanowe do Oracle, PostgreSQL, Cloudscape, Microsoft
SQL Server, IBM DB2. Bazy te przechują dane rejestrowe.
 API w Javie dla klienta UDDI
 Prosty kod ilustrujący jak użyć API klienta w Javie


Do tworzenia wiadomości wykorzystywany jest biblioteka Apache’a
Przykład <find_business>
<uddi:find_business generic="2.0" maxRows="10">
<uddi:name> UŁ </uddi:name>
</uddi:find_business>
Definicja <businessList>, <businessInfos>,
<businessInfo> w UDDI Schema
<element name="businessList" type="uddi:businessList" />
<complexType name="businessList">
<sequence>
<element ref="uddi:businessInfos" />
</sequence>
<attribute name="generic" use="required" type="string" />
<attribute name="operator" use="required" type="string" />
<attribute name="truncated" use="optional" type="uddi:truncated" />
</complexType>
<element name="businessInfos" type="uddi:businessInfos" />
<complexType name="businessInfos">
<sequence>
<element ref="uddi:businessInfo" minOccurs="0" maxOccurs="unbounded" />
</sequence>
</complexType>
<element name="businessInfo" type="uddi:businessInfo" />
<complexType name="businessInfo">
<sequence>
<element ref="uddi:name" maxOccurs="unbounded" />
<element ref="uddi:description" minOccurs="0" maxOccurs="unbounded" />
<element ref="uddi:serviceInfos" />
</sequence>
<attribute name="businessKey" use="required" type="uddi:businessKey" />
</complexType>
Publikowanie do rejestru UDDI

Różnice w przypadku zapytania i publikowania:
– wszystkie żądania publikacji wymagają
autoryzacji. Proces autoryzacji nie jest
wyspecyfikowany w UDDI i jest charakterystyczny dla
operatora węzła.
 Punkty dostępu – żądania publikacji i autoryzacji
wymagają różnych punktów dostępu. HTTP dla
zapytania HTTPS dla publikowania
 Ograniczenie miejsca – operator może zastrzec
 Przywiązanie do węzła operatora
 Autoryzacja
Przykłady żądań przy publikowaniu (1)



Żądanie <add_publisherAssertions>
<dispositionReport>
Zwraca ważny token autentykacyjny oraz dokument
<publisherAssertion>. Wiadomość ta dodaje
<publisherAssertion> do indywidualnego zbioru
bezpieczeństwa. Autoryzacja publikującego tworzy
asocjacje pomiędzy dwoma biznesami. Jeśli obydwoje
publikujący dodają dokument <publisherAssertion> do
ich kolekcji relacja staje się widoczna publicznie.
Przykłady żądań przy publikowaniu (2)

Żądanie <delete_business>
 <dispositionReport>
 Zwraca
ważny token autentykacyjny i UUID jednego
lub więcej dokumentów <businessEntity>.
Wiadomość ta kasuje dokumenty <binding-Template>
z rejestru UDDI. Kasowanie dokumentu wywołuje
kasowanie zawartych danych dla <businessService>
lub <bindingTemplate>. Dodatkowo każdy
<publisherAssertions> utworzony z UUID dla
<businessEntity> zostanie usunięty.

Java 1 - Kolos

Transkrypt

Podobne dokumenty

Wykład nr 6: Wyszukiwanie usług WWW w sieci.

bezpowrotnie - Aptekarz Polski

dziedzina Dziedzictwo kulturowe nr 12 (pdf.)

4 950 EUR 450 m2

4 950 PLN 150 m2 - NAI Estate Fellows

Formularz do wydania tematu dyplomu inżynierskiego

Program Konferencji Edukacyjnej cyklu Uruchamiamy Dzieciaki w

Wprowadzenie do technologii Web Services: SOAP, WSDL i