UDDI & WSDL wykład 10

Transkrypt

1 Uniwersytet Łódzki Wydział Matematyki i Informatyki, Katedra Analizy Nieliniowej UDDI & WSDL wykład 10 Programowanie w Javie 2 mgr inż. Michał Misiak

2 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

3 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

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

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

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

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

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

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

10 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

11 REPLIKACJA Architektura UDDI Specyfikacja UDDI Rejestr operatorów UDDI Schema Rejestr operatorów Ogólny Rejestr UDDI (UDDI Business Registry) Rejestr operatorów

12 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

13 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: w wersji 2.0

14 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 , zapewnienie spójności danych przy kasowaniu Dokument ten nie posiada API oraz nie musi być implementowany przez węzły prywatne

15 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

16 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

17 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

18 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

19 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

20 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

21 Przykłady zapytań Operator node Inquiry URL Publishing URL HP IBM Test Microsoft Production Microsoft Test 3.ibm.com/services/uddi/inquirya pi ire 3.ibm.com/services/uddi/protect/publish api

22 Struktury danych UDDI

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

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

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

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

27 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

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

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

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

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

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

33 Przykład <find_business> <uddi:find_business generic="2.0" maxrows="10"> <uddi:name> UŁ </uddi:name> </uddi:find_business>

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

35 Publikowanie do rejestru UDDI Różnice w przypadku zapytania i publikowania: Autoryzacja 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

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

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