Technologie usług internetowych

Transkrypt

1 Technologie usług internetowych Tomasz Pawlak

2 2 Plan prezentacji Wprowadzenie do usług internetowych SOAP WSDL UDDI Inne standardy

3 3 Usługa internetowa

4 3 Usługa internetowa Wiele definicji Aplikacja dostępna przez interfejs internetowy Każdy fragment kodu z przypisanym URI! Aplikacja ze stabilnym i dobrze udokumentowanym (samopisującym) API Konsorcjum UDDI Samodzielna, modułowa aplikacja biznesowa, wyposażona w interfejs bazujący na otwartych, internetowych standardach Źródło: UDDI Consortium, UDDI Executive White Paper, 2001

5 4 Usługa internetowa (2) Konsorcjum World Wide Web (W3C) Aplikacja identyfikowana przez URI, której interfejsy i wiązania mogą być zdefiniowane, opisane i zaprezentowane jako dokumenty XML. Usługa internetowa wspiera bezpośrednią interakcję z innym oprogramowaniem wykorzystując komunikaty XML wymieniane przy użyciu protokołów internetowych. Źródło: W3C, Web Services Architecture Requirements, 2002

6 5 Usługa internetowa vs middleware Usługa internetowa Usługi w middleware Ogólnie obowiązujące standardy Własne standardy lub niepełne implementacje ogólnych standardów Zdecentralizowana architektura Brak globalnego zarządcy Każdy podmiot zarządza swoją częścią systemu Brak zaufania między podmiotami Zcentralizowana architektura Middleware pełni rolę globalnego zarządcy Istnieje podmiot posiadający władzę nad systemem Jedna domena zaufania Słabe powiązanie między usługami Mocne powiązanie między usługami Stan systemu może utrzymywać się długo (np.: akcje powodujące długotrwałe operacje fizyczne, opóźnienia) Stan systemu zmienia się szybko (małe, krótkie akcje)

7 6 Transakcyjność Blokowanie dwufazowe (2-Phase Commit, 2PC) Wymaga centralnego zarządcy Blokady na zasobach zarządzane przez jeden podmiot Problemy Brak zaufania między podmiotami Poufność informacji Długi czas trwania blokad w procesach biznesowych Rozwiązane: Protokoły koordynacji transakcji rozproszonej

8 7 Rozproszone transakcje Każda usługa posiada własnego zarządcę transakcji Peer-to-peer Usługi wspólnie negocjują przeprowadzenie transakcji Podział na Transakcje atomowe Krótkie operacje Aktywności biznesowe Długie operacje Wiele usług

9 8 Usługi internetowe w sieciach lokalnych Ta sama architektura, mniejsza skala Wiele komponentów Luźno powiązane Mało zależności Brak centralnego zarządcy Brak konieczności kupna systemu middleware Ale: Brak jednego miejsca zarządzania systemem Dobra integracja heterogenicznych komponentów systemu Standaryzacja Brak adapterów Brak problemów biznesowych Odpowiedzialność za system spoczywa po jednej stronie

10 9 Architektura nastawiona na usługi Service-Oriented Architecture (SOA) Założenie Firma realizuje swoją ofertę za pośrednictwem usług Aktorzy Usługa Klient usługi Katalog usług Usługa Procedura, metoda, obiekt Stabilne API Opublikowany interfejs Możliwość wywołania przez klienta (inną aplikację) Autonomiczna i izolowana od innych usług

11 10 Wymagania wynikające z architektury Wspólna składnia wszystkich specyfikacji Otwarty standard Zrozumiały format dla każdej strony komunikacji Powszechne biblioteki obsługi Przykład: extensible Markup Language (XML)

12 11 Wymagania wynikające z architektury (2) Komunikacja Zapewnienie słabego wiązania usług Jednakowa interpretacja wiadomości po obu stronach Kodowanie Powszechne biblioteki obsługi Przykład: HyperText Transfer Protocol (HTTP)

13 12 Wymagania wynikające z architektury (3) Interakcja z usługą Komunikacja przez wiadomości Jednakowa interpretacja wiadomości po obu stronach Ustalony format Obsługa obiektowości Wywołanie metody Złożone struktury Argumenty Wartość zwracana Obsługa błędów Przykład: Simple Object Access Protocol (SOAP)

14 13 Wymagania wynikające z architektury (4) Opis interfejsu usługi Uniwersalny format Możliwy do zastosowania w różnych technologiach Standardowe typy danych Opisuje Metody Struktury danych Przykład: Web Service Description Language (WSDL)

15 14 Wymagania wynikające z architektury (5) Katalog usług Publikacja interfejsu/danych dostępowych usługi Odnalezienie usługi spełniającej kryteria Pobranie interfejsu usługi Standaryzowany interfejs dostępu do katalogu Proste operacje Standardowe typy danych Powszechne wsparcie w bibliotekach Przykład: Universal Description, Discovery and Integration (UDDI)

16 15 SOAP Simple Object Access Protocol

17 16 Historia SOAP V1.0: 1999 V1.1: 2000 V1.2: 2003 Całkowicie bazuje na HTTP Dowolny protokół transportowy Głównie poprawki edycyjno językowe Ujednolicenie specyfikacji Wyjaśnienie niepewności

18 17 Cele powstania SOAPa Zwalczenie problemów w integracji systemów przez Internet Firewalle Brak standaryzacji protokołów Silne wiązanie usług

19 18 Specyfikacja SOAP Format wiadomości Zapis informacji w XML Specyfikacja ignoruje semantykę wiadomości Zbiór konwencji wykorzystania wiadomości SOAP Implementacja rozwiązania RPC Definicja jak wywoływać zdalne procedury Jak formułować odpowiedź Wysłanie wiadomości zwrotnej Wymiana dokumentów

20 19 Specyfikacja SOAP (2) Zbiór reguł przetwarzania wiadomości SOAP Obowiązkowe elementy XML do odczytania i interpretacji Sposób interpretacji elementów XML Akcje do podjęcia, jeśli element jest niezrozumiały Opis transportu wiadomości SOAP Bezstanowa komunikacja HTTP SMTP TCP

21 20 Specyfikacja formatu wiadomości SOAP Użycie XML Schema Ograniczenia na strukturę dokumentu XML Jeden format wiadomości Żądanie Odpowiedź

22 21 Struktura wiadomości SOAP Koperta SOAP Nagłówek (opcjonalny) Ciało Błąd (opcjonalny) Załącznik (opcjonalny)

23 22 Przykład wiadomości SOAP <?xml version="1.0"?> <soap:envelope xmlns:soap=" xmlns:w=" <soap:header> </soap:header> <soap:body> <w:getforecast> <w:city>poznan</w:city> </w:getforecast> </soap:body> </soap:envelope>

24 23 Podział: nagłówek/ciało Wynika z typowego podziału w protokołach komunikacyjnych Nagłówek Ciało Informacje infrastrukturalne Przetwarzane przez odpowiednie węzły komunikacji Pośredniczący Docelowy Informacje aplikacyjne Zrozumiałe dla odbiorcy

25 24 Nagłówek Opcjonalny Specyfikacja nie definiuje zapisanych informacji Sekwencja bloków Dane uwierzytelniające Nazwa użytkownika/hasło Token Certyfikat Dane o nadawcy i odbiorcy Routing Informacje o węzłach pośredniczących Dopisane w trakcie transmisji Identyfikator transakcji

26 25 Ciało wiadomości Wymagane Sekwencja bloków Informacje aplikacyjne Nazwa wywołanej procedury Parametry procedury Wartość zwracana

27 26 Sposób konstrukcji nagłówka/ciała Style interakcji Dokumentowy Strony interakcji negocjują strukturę dokumentów SOAP transport dla dokumentów Asynchroniczna komunikacja Nagłówek: informacje o nadawcy, odbiorcy RPC Zdalne wywołania procedur Komunikacja synchroniczna Żądanie Wywołanie operacji Odpowiedź Wartość zwrócona Opcjonalny błąd Nagłówek: np.: identyfikator transakcji

28 27 Interakcja typu dokument vs RPC Dokument RPC Koperta SOAP Koperta SOAP Koperta SOAP Koperta SOAP Ciało SOAP Ciało SOAP Ciało SOAP Ciało SOAP Dokumentzamówienie produkt ilość Potwierdzenie zamówienia identyfikator Nazwa metody zamów Parametr 1 produkt Parametr 2 ilość Zwrot z metody Wartość zwrócona identyfikator

29 28 Załącznik Rozszerzenie standardu w wersji 1.2 Abstrakcyjny model Nie definiuje sposobu kodowania danych Mało i rozbieżne implementacje Bloki danych Dane binarne Typ MIME (Multipurpose Internet Mail Extensions) Dane osadzone we wiadomości Dane zewnętrzne Dostępne przez URI zapisane we wiadomości Efektywny sposób przesłania dużej ilości danych

30 29 Message Transmission Optimization Mechanism (MTOM) Alternatywa dla załączników SOAP Specyfikuje sposób przesłania danych typu xs:base64binary Format negocjowany między węzłami transmisji Możliwość dynamicznej zmiany formatu

31 Message Transmission Optimization Mechanism (MTOM) 30 Złożenie funkcjonalności Abstract SOAP Transmission Optimization Feature Dane binarne osadzone w XMLu Dane binarne przesłane osobno i referowane w XMLu Forma kanoniczna znaków użytych w base64 Usunięcie białych znaków Optimized MIME Multipart/Related Serialization of SOAP Messages Użycie XML-binary Optimized Packing (XOP) Opakowanie wiadomości i danych w dodatkowy kontener Dane binarne oddzielone od ich opisu Referowane w XMLu HTTP SOAP Transmission Optimization Feature Sposób przesłania danych MIME i XOP przez HTTP

32 31 MTOM przykład MIME-Version: 1.0 Content-Type: Multipart/Related;boundary=MIME_boundary;... --MIME_boundary Content-Type: application/xop+xml;... <soap:envelope... <soap:body>... <m:photo xmlmime:contenttype='image/png'> <xop:include xmlns:xop=' href='cid: --MIME_boundary Content-Type: image/png Content-Transfer-Encoding: binary Content-ID: < // Dane binarne pliku PNG Źródło:

33 32 Kodowanie SOAP SOAP Encoding Zalecenie (element standardu) Aplikacje mogą zignorować Sposób kodowania w XML podstawowych typów danych Integer Float/Double String Tablice Struktury złożone z powyższych

34 33 Przetwarzanie wiadomości SOAP Przetwarzanie wiadomości przez węzeł infrastruktury Wynika ze struktury wiadomości Rola węzła Zbiór zadań stojących przed węzłem Związana z blokami w nagłówku wiadomości Jeden węzeł może mieć wiele ról

35 34 Role w SOAP none next Blok nie będzie przetwarzany samodzielnie przez żaden węzeł Ale może być odczytany w wyniku przetwarzania innego bloku Blok przeznaczony dla następnego węzła na trasie W szczególności każdy węzeł może odczytać blok ultimatereceiver Odczytywany wyłącznie przez odbiorcę wiadomości Bloki w ciele zawsze mają rolę ultimatereceiver

36 35 Flaga mustunderstand Flaga bloku Wskazuje na obowiązkowość przetworzenia bloku Jeśli węzeł implementuje rolę związaną z blokiem: Blok musi zostać przetworzony W przeciwnym wypadku przetwarzanie kończy się błędem Brak flagi Węzeł może zdecydować o przetworzeniu lub zignorowaniu bloku

37 36 Wiązanie SOAP z protokołem transportowym Przypomnienie SOAP nie definiuje protokołu transportowego Zwykle używany HTTP SMTP TCP

38 37 Role protokołu transportowego Przesyłanie wiadomości Adresowanie stron komunikacji Adres nie jest zapisany we wiadomości SOAP Adres to np.: URL w HTTP Pole To: w SMTP TCP:?

39 37 Role protokołu transportowego Przesyłanie wiadomości Adresowanie stron komunikacji Adres nie jest zapisany we wiadomości SOAP Adres to np.: URL w HTTP Pole To: w SMTP TCP:? IP + Port

40 38 SOAP + HTTP Metoda POST Wywołanie procedury Jeden kanał komunikacyjny Żądanie Odpowiedzi Komunikacja blokująca

41 39 Implementacja klienta/serwera SOAP Logika aplikacji klienckiej Wywołanie metody na lokalnym obiekcie o interfejsie usługi Klient usługi Silnik SOAP Silnik HTTP Wywołanie generycznego API silnika SOAP Zlecenie wysłania sformatowanej wiadomości metodą POST pod zadany URI Logika aplikacji usługi Wywołanie metody z interfejsu usługi Szablon usługi Silnik SOAP Serwer HTTP Generyczne wywołanie utworzonego lub pobranego obiektu ze zdekodowanymi parametrami Przekazanie sformatowanej wiadomości SOAP

42 40 Implementacja klienta/serwera SOAP Logika aplikacji klienckiej Wywołanie metody na lokalnym obiekcie o interfejsie usługi Klient usługi Silnik SOAP Silnik HTTP Wywołanie generycznego API silnika SOAP Zlecenie wysłania sformatowanej wiadomości zadaną metodą pod zadany adres Do zaprogramowania Wygenerowany kod Infrastruktura Logika aplikacji usługi Wywołanie metody z interfejsu usługi Szablon usługi Silnik SOAP Serwer HTTP Generyczne wywołanie utworzonego lub pobranego obiektu ze zdekodowanymi parametrami Przekazanie sformatowanej wiadomości SOAP

43 41 Asynchronizm w SOAP Specyfikacja Asynchroniczna jednostronna komunikacja Protokół bezstanowy Realizacja zależy od protokołu transportowego HTTP Żądanie Odpowiedź w tym samym kanale komunikacyjnym SMTP Żądanie Odpowiedź w oddzielnym kanale komunikacyjnym

44 42 Asynchroniczna komunikacja SOAP Możliwe w komunikacji typu RPC Najczęściej realizowane mechanizmami silnika SOAP klienta Brak np.: gwarancji trwałości Lepsze rozwiązanie: komunikacja przez dokumenty

45 43 WSDL Web Services Description Language

46 44 WSDL Język opisu usługi Język bazowy: XML Interfejs usługi Metody Typy danych Punkty świadczenia usługi Endpoint URL Wiązania RPC/Dokument Protokół transportowy

47 45 WSDL vs Interface Definition Language Funkcjonalnie WSDL = IDL + Punkty świadczenia usług Wiązania Pozafunkcjonalnie WSDL Otwarty standard Powszechna implementacja formatu (XML) Wiele protokołów dostępu Brak patentów IDL Rozwiązanie konkretnego producenta

48 46 Historia WSDL Wersja 1.0/1.1 (2001r) Połączenie Microsoft SOAP Contract Language (SCL) Microsoft Service Description Language (SDL) IBM Network Accessible Service Specification Language (NASSL) Wersja 2.0 (2007r) Wynik prac Massachusetts Institute of Technology The European Research Consortium for Informatics and Mathematics Keio University

49 47 Zmiany w WSDL 2.0 Brak kompatybilności wstecz Dodatkowy opis semantyki języka Uproszczenie Eliminacja pewnych konstrukcji języka Brak przeciążania operatorów Zmiany nomenklatury Port Endpoint PortTypes Interfaces Wsparcie dla usług REST WSDL 1.1 obsługuje metody GET i POST, 2.0 wszystkie metody HTTP

50 48 Struktura dokumentu WSDL Źródło:

51 49 Cześć abstrakcyjna/konkretna Część abstrakcyjna Definiuje sposób interakcji z abstrakcyjnym interfejsem usługi Część konkretna Definiuje sposób dostępu do konkretnej instancji usługi Definiuje reguły kodowania danych dla konkretnej instancji usługi

52 50 Część abstrakcyjna (1) Typy danych Kompletny opis struktur danych Wykorzystanie typów prostych Import z XML Schema

53 51 Część abstrakcyjna (2) Wiadomość (v1.1, v2.0 brak wyróżnienia typu) Jednostka wymiany informacji Struktura danych złożona z innych struktur Służy przekazywaniu danych z/do metod Przykład: Dla metody dwuargumentowej Argument 1: integer Argument 2: double Wiadomość Krotka dwóch wartości

54 52 Część abstrakcyjna (3) Definicja operacji Opis wymiany wiadomości Typy operacji One-way Klient wywołuje usługę wysyłając wiadomość Request-response Klient wywołuje usługę wysyłając wiadomość Usługa odsyła odpowiedź do klienta Solicit-response Usługa wysyła wiadomość do klienta Usługa oczekuje odpowiedzi klienta Notification Usługa wysyła wiadomość do klienta

55 53 Część abstrakcyjna (4) Interfejs (v1.1: Port Type) Kolekcja operacji Grupuje operacje Wynika z grupowania przygotowanego przez programistę Zazwyczaj wynika z semantyki operacji

56 54 Część konkretna (1) Wiązania interfejsów Kodowanie wiadomości, np.: Styl komunikacji Dokument/RPC Sposób kodowania Dosłowny (literal) SOAP Surowe struktury danych Opakowanie w kopertę SOAP Wiązania protokołów, np.: SOAP dla wymiany wiadomości HTTP jako transport

57 55 Część konkretna (2) Endpoints (v1.1: ports) Adresy poszczególnych operacji Metody dostępu GET/POST (v1.1) GET/POST/PUT/DELETE/ (v2.0)

58 56 Część konkretna (3) Usługi Logiczne zgrupowanie endpoint ów Uwaga! Poszczególne operacje należące do jednego interfejsu usługi Mogą być udostępnione pod różnymi adresami i przez różne serwery Zwykle Grupowanie wynika z interfejsu Wszystkie operacje świadczone przez jeden serwer Inne zastosowanie Dostęp do usługi wieloma kanałami

59 Przykład WSDL <?xml version="1.0" encoding="utf-8"?> <definitions xmlns=" xmlns:tns=" xmlns:whttp=" xmlns:wsoap=" targetnamespace=" <types> <xs:schema xmlns:xs=" xmlns=" targetnamespace=" <xs:element name="request">... </xs:element> <xs:element name="response">... </xs:element> </xs:schema> </types> <interface name="interface1"> <fault name="error1" element="tns:response"/> <operation name="get" pattern=" <input messagelabel="in" element="tns:request"/> <output messagelabel="out" element="tns:response"/> </operation> </interface> 57 Część abstrakcyjna <binding name="httpbinding" interface="tns:interface1" type=" <operation ref="tns:get" whttp:method="get"/> </binding> <binding name="soapbinding" interface="tns:interface1" type=" wsoap:protocol=" wsoap:mepdefault=" <operation ref="tns:get" /> </binding> <service name="service1" interface="tns:interface1"> <endpoint name="httpendpoint" binding="tns:httpbinding" address=" <endpoint name="soapendpoint" binding="tns:soapbinding" address=" </service> </definitions> Źródło: Część konkretna

60 58 Implikacje wynikające z modelu WSDL Usługa może zainicjować komunikację Wynika z wymiany dokumentów Separacja interfejsu od punktu dostępu Brak założenia o konkretnym sposobie dostępu do usługi Elastyczność Ponowne wykorzystanie interfejsu Np.: na wielu adresach Modularyzacja Separacja dokumentów definicji interfejsu i punktów dostępowych

61 59 Implikacje wynikające z modelu WSDL (2) Wysoka zgodność WSDL z SOAP Opis wystarczający do Konstrukcji wiadomości SOAP Bezpośrednie przełożenie z WSDL na SOAP Stylu komunikacji Kodowania XML Wiązań transportowych Uwaga! WSDL nie jest przeznaczony wyłącznie dla SOAPa

62 60 Przypadki użycia WSDL WSDL jako IDL definiuje kontrakt Usługa wypełnia kontrakt Klient korzysta z kontraktu WSDL jako dane wejściowe kompilatora Kompilator generuje szablon klienta/usługi WSDL jako dane wyjściowe kompilatora/infrastruktury Kompilator generuje WSDL na podstawie interfejsu usługi WSDL jako nośnik informacji semantycznej Niepełna informacja o funkcjonalności usługi Separacja funkcjonalności

63 61 Scenariusze użycia WSDL Web Service Description Usage Scenarios 36 scenariuszy użycia WSDL Jednostronna i dwustronna wymiana wiadomości Operacje RPC Wymiana metadanych Komunikacja synchroniczna i asynchroniczna

64 62 Alternatywne standardy Electronic Data Interchange (EDI) SWIFT Mniej przejrzysty format zapisu Specjalizowany format dla transakcji bankowych Web Application Description Language (WADL) WSDL dla REST Health Level 7 (HL7) Specjalizowany format dla wymiany danych medycznych

65 63 UDDI Universal Description, Discovery and Integration

66 64 UDDI Specyfikacja opisu semantycznego usługi Struktury danych Specyfikacja katalogu usług Struktury danych Format zapytania Format odpowiedzi Specyfikacja katalogu firm Universal Business Registry (UBR) Międzynarodowy katalog Dostęp dla każdego, bez opłat API zapisane w WSDL + SOAP

67 65 Cele UDDI Wsparcie programistów Odnalezienie informacji o usługach Uzyskanie wiedzy, jak napisać klienta usługi Dynamiczne wiązanie usług Odnalezienie działających instancji usług Dynamiczna zmiana adresów usług Nawiązanie połączenia

68 66 Historia UDDI Pierwsza wersja: 2000r Efekt połączenia prac nad Rozwiązania B2B IBM i Ariba XML, SOAP IBM i Microsoft cxml Microsoft i Ariba Obecnie standard utrzymywany przez OASIS Wersja 3 (2002r)

69 67 Informacje w katalogu UDDI White pages informacje biznesowe Tożsamość usługodawcy Dane kontaktowe (adres, telefon, ) Koszty Polityki Yellow pages klasyfikacje przemysłowe usług Standard Industrial Classification (SIC) North American Industry Classification System (NAICS) United Nations Standard Products and Services Code (UNSPSC) Green pages informacje techniczne URI Opis interfejsu

70 68 Struktury danych w katalogu UDDI (1) businessentity (white page) Opis organizacji świadczącej usługę Nazwa Adres Telefon

71 69 Struktury danych w katalogu UDDI (2) businessservice (yellow page) Grupa powiązanych usług świadczonych przez businessentity Zwykle jedna usługa Świadczona Wieloma kanałami dostępu W wielu wersjach Informacje o klasyfikacji usług businessservice należy do dokładnie jednej businessentity

72 70 Struktury danych w katalogu UDDI (3) bindingtemplate (green page) Informacje techniczne Adres usługi Referencje dokumentów (tmodel) wykorzystywanych przez usługę Parametry operacyjne Sposób użycia Wartości domyślne bindingtemplate należy do dokładnie jednej bussinessservice

73 71 Struktury danych w katalogu UDDI (4) tmodel (green page) Skrót od Technical Model Generyczny kontener dla dowolnych danych technicznych, np.: WSDL Opis semantyki Niezależny od innych encji Może być referowany przez inne encje Może podlegać osobnej standaryzacji

74 72 Organizacja katalogu UDDI Źródło:

75 73 tmodel najważniejsza struktura UDDI Każdy opublikowany tmodel Unikalny identyfikator Opisuje np.: interfejs usługi Może być referowany przez wiele usług Wskazanie, że usługa implementuje dany interfejs (lub wiele interfejsów wiele tmodeli) Niezależny od Standardów specyfikacji interfejsu Języka zapisu interfejsu Hierarchia tmodeli tmodele mogą się referować UDDI przewiduje predefiniowany katalog typów tmodeli Np.: klucz o URI uddi-org:types i wartości wsdlspec oznacza WSDL Dopuszczone wykorzystanie typu spoza katalogu

76 74 tmodel najważniejsza struktura UDDI 2 Przykład 1: Programista wykorzystuje dane z tmodelu (np.: referowany WSDL) do przygotowania klienta usługi Użytkownik wybiera w czasie pracy z katalogu usługodawcę świadczącego usługę zgodną z tmodelem Przykład 2: Zamiast polegać na standardach klasyfikacji usług/funkcjonalności tmodel jest wykorzystywany do klasyfikacji i identyfikacji usług Każdy może zdefiniować swoje własne pojęcie tmodel Otwartość na niesklasyfikowane pojęcia Trudność w ustaleniu równoznaczności pojęć

77 75 API katalogu usług UDDI (1) UDDI Inquiry API Wyszukanie wpisów spełniających kryteria Wykorzystane w przeglądarce UDDI Wyszukiwanie usług przez programistów Dynamiczne wiązanie usług Pobranie poglądowych informacji nt. powyższych wpisów find_business find_service find_binding find_tmodel Pobranie szczegółowych informacji nt. wpisów get_businessdetail get_servicedetail get_bindingdetail get_tmodeldetail

78 76 API katalogu usług UDDI (2) UDDI Publishers API Dla dostawców usług Manipulacja wpisami w katalogu Dodanie i Aktualizacja save_business save_service save_binding save_tmodel Usuwanie delete_business delete_service delete_binding delete_tmodel Uwaga! Modyfikacje możliwe wyłączenie w katalogu, w którym wpis był dodany

79 77 API katalogu usług UDDI (3) UDDI Security API Zarządzanie tokenami uwierzytelniającymi W komunikacji z katalogiem get_authtoken discard_authtoken

80 78 API katalogu usług UDDI (4) UDDI Custody and Ownership Transfer API Przeniesienie nadzoru nad wpisem między dostawcami get_transfertoken transfer_entities (zmiana dostawcy właściciela wpisu) transfer_custody (zmiana katalogu właściciela wpisu)

81 79 API katalogu usług UDDI (5) UDDI Subscription API Monitorowanie zmian w katalogu Zdarzenia dot. wpisów Dodanie Aktualizacja Usunięcie get_subscriptions save_subscriptions delete_subscription get_subscriptionresults (pobranie zdarzeń)

82 80 API katalogu usług UDDI (6) UDDI Replication API Replikacja informacji między katalogami Synchronizacja katalogów

83 81 Punkty dostępu UDDI Poszczególne API dostępne pod innymi URI Powód: Bezpieczeństwo Niektóre interfejsy nie wymagają uwierzytelnienia Inne wymagają uwierzytelnienia Uporządkowanie funkcjonalności Komunikacja najczęściej przez SOAP + HTTP Szczegóły ukryte przez infrastrukturę

84 82 Rozszerzenia API UDDI Standard Np.: Minimalne API katalogu Dopuszcza rozszerzenia Wyszukiwanie po dodatkowych kryteriach Dodatkowe poziomy dostępu do wpisów API dostępne za opłatą

85 83 UDDI Search Markup Language (USML) UDDI Inquiry API Pozwala na wyszukiwanie po jednym kryterium Dostawca Interfejs usługi W jednym katalogu Wyszukiwania nie są propagowane na inne katalogi Katalogi jedynie synchronizują swoją zawartość USML: Rozszerzenie standardu Obsługa złożonych zapytań Zapytania jako dokumenty XML Implementacja: IBM Business Explorer for Web Services (BE4WS)

86 84 Przykładowy wpis w katalogu <?xml version="1.0" encoding="utf-8"?> <tmodel tmodelkey="uddi:uddi.org:v3_security"> <name>uddi-org:security_v3</name> <description>uddi Security API V3.0</description> <overviewdoc> <overviewurl usetype="wsdlinterface"> </overviewurl> </overviewdoc> <overviewdoc> <overviewurl usetype="text"> </overviewurl> </overviewdoc> <categorybag> <keyedreference keyname="uddi-org:types:wsdl" keyvalue="wsdlspec" tmodelkey="uddi:uddi.org:categorization:types"/> <keyedreference keyname="uddi-org:types:soap" keyvalue="soapspec" tmodelkey="uddi:uddi.org:categorization:types"/> <keyedreference keyname="uddi-org:types:xml" keyvalue="xmlspec" tmodelkey="uddi:uddi.org:categorization:types"/> <keyedreference keyname="uddi-org:types:specification" keyvalue="specification" tmodelkey="uddi:uddi.org:categorization:types"/> </categorybag> Biznesowe </tmodel> Systemy Rozproszone

87 85 Publiczne i prywatne katalogi UDDI v1 & v2 Universal Business Registry (UBR) Publiczny (główny) katalog Publiczne usługi Sieć katalogów UBR Synchronizacja zmian UDDI v3 Dostosowane do zastosowań wewnętrznych organizacji Wsparcie integracji wewnętrznych systemów

88 86 Usługi internetowe w działaniu Dostawca usług Logika usługi Szablon serwera Generator WSDL Dokumenty WSDL Silnik SOAP Silnik HTTP Kompilator WSDL Moduł publikacji UDDI businessentity businessservice bindingtemplate tmodel Inquiry API Katalog UDDI Publishers API Źródło: G. Alonso et.al., Web Services: Concepts, Architectures and Applications

89 87 Powiązane standardy

90 88 WS-Addressing Adresowanie usług Adres Wewnątrz wiadomości SOAP Niezależne od protokołu URI Wskazuje na aplikacje Zbiór właściwości unikalnie identyfikujących instancję Zapisane w nagłówkach SOAP Np.: identyfikator sesji Aplikacja rozdziela żądania do instancji na podstawie właściwości

91 89 Uzasadnienie użycia WS-Addressing Alternatywa: poleganie na protokole transportowym Protokół może nie obsługiwać przesyłania metadanych Np.: SMTP URI można zapisać w polu To: Gdzie zapisać identyfikator sesji? Wymagałoby oddzielnej obsługi adresacji dla każdego protokołu WS-Addressing Standaryzuje sposób zapisu w/w informacji Jedna procedura obsługi, niezależna od protokołu

92 90 WS-Routing Definicja drogi przesłania wiadomości Zapisana w nagłówkach SOAP Sekwencja węzłów Przetwarzanie Węzeł usuwa z nagłówka wpis o sobie Węzeł może dodać nowe wpisy Węzeł przesyła wiadomość do kolejnego na drodze

93 91 WS-Security Kontrola dostępu Nagłówki UsernameToken i BinarySecurityToken Podpis cyfrowy pod wiadomością Zapisany w nagłówku SOAP Zapewnienie integralności Szyfrowanie wiadomości Zapewnienie poufności

94 92 Uzasadnienie użycia WS-Security HTTPS niewystarczający Zapewnia bezpieczeństwo na odcinkach komunikacji Np.: między proxy, a bramą HTTP Dowolny pośrednik może rozszyfrować komunikację Szyfruje całą wiadomość WS-Security Zapewnia bezpieczeństwo na całej trasie komunikatu Szyfruje wybrany fragment wiadomości

95 93 WS-Policy Sposób wyrażenia polityki komunikacji Przez klienta i usługę Polityka Wymagania Możliwości Preferencje Zbiór generycznych asercji Możliwe łączenie w warunki And/or/xor Standard nie definiuje jak połączyć politykę z usługą

96 94 WS-PolicyAttachment Definicja połączenia Polityki Wpisów w dokumencie WSDL

97 Dużo, dużo innych 95

98 96 Dziękuję za uwagę Proszę o pytania