Wprowadzenie do usług internetowych

Transkrypt

1 Wprowadzenie do usług internetowych Tomasz Pawlak

2 2 Plan prezentacji Wprowadzenie do usług internetowych Technologie usług internetowych Architektura usług internetowych Statystyki

3 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 ConsorPum, UDDI ExecuPve White Paper, 2001

4 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

5 5 Usługa internetowa cechy W założeniu zewnętrzny punkt wejścia do lokalnego systemu Redukcja heterogeniczności systemu Nowe paradygmaty programowania Nowe architektury Service- Oriented Architecture (SOA) Słabe powiązanie komponentów systemu Możliwość wielokrotnego wykorzystania

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

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

8 8 Transakcyjność Blokowanie dwufazowe (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

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

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

11 11 Technologie usług internetowych

12 12 Opis usługi (middleware) Interface DefiniPon Language (IDL) Własne standardy producentów W middleware opisuje dostępne funkcje Typy argumentów Typ wartości zwracanej Brak informacji o semantyce Założenie: znana z innego źródła Dokumentacja Od twórcy usługi Brak informacji o sposobie komunikacji Realizowany przez middleware

13 13 Elementy opisu usługi internetowej Wspólny język bazowy (ang. common base language) Meta- język Pozwala na opis każdego aspektu usługi (ogólność) Otwartość Maszynowe przetwarzanie Popularne rozwiązanie: XML JSON

14 14 Elementy opisu usługi internetowej (2) Interfejs Wykorzystanie języka bazowego Opisują dostępne metody Argumenty Typ zwracany Struktury i typy danych Adres usługi (URI) Protokół dostępu (np.: HTTP) Występuje w middleware Kontekst Przykład Web Services DescripPon Language (WSDL) Web ApplicaPon DescripPon Language (WADL)

15 15 Elementy opisu usługi internetowej (3) Protokół biznesowy Zbiór reguł dla konwersacji Sekwencja operacji wymagana do osiągnięcia celu biznesowego, np.: Zapytanie ofertowe Złożenie zamówienia Realizacja płatności Odbiór towaru Operacje dostępne w danym stanie przetwarzania Kompozycja usług Standardy Web Services ConversaPon Language (WSCL) Business Process ExecuPon Language for Web Services (BPEL)

16 16 Kompozycja usług Usługa podstawowa (ang. basic service) Samodzielnie wykonuje wszystkie operacje Usługa złożona (ang. composite service) Korzysta z innych usług Różni dostawcy Różne fizyczne lokalizacje Z punktu widzenia klienta usługi podział nie ma znaczenia

17 17 Elementy opisu usługi internetowej (4) Właściwości i semantyka Dodatkowe informacje o działaniu usługi, np.: Koszt korzystania z usługi Polityka zwrotów zakupionego towaru Universal DescripPon, Discovery and IntegraPon (UDDI) Standard opisu właściwości usługi Rejestr usług W założeniu globalny W praktyce stosowany wewnątrz przedsiębiorstw Wymaga centralnego zarządcy

18 Universal Description, Discovery and Integration (UDDI) 18 White pages Sposób uzyskania dostępu do usługi Nazwa usługodawcy Koszty Polityki Yellow pages klasyfikacje przemysłowe usług Standard Industrial ClassificaPon (SIC) North American Industry ClassificaPon System (NAICS) United NaPons Standard Products and Services Code (UNSPSC) Green pages URI Opis interfejsu Inne informacje techniczne

19 19 Protokoły komunikacji usług Protokół transportowy Ukrywa aspekty techniczne komunikacji Najczęściej HTTP TCP SMTP Named pipes Windows Obsługa komunikacji między komputerami

20 20 Protokoły komunikacji usług (2) Protokół wymiany wiadomości Ustandaryzowany sposób przekazania danych między usługami Np.: Simple Object Access Protocol (SOAP) REpresentaPonal State Transfer (REST)

21 21 SOAP Format wiadomości: XML Nagłówek Informacje specyficzne dla aplikacji Uwierzytelnienie Płatność Ciało Wywołanie procedury Argumenty Wartość zwracana Błąd = Wyjątek Binarne załączniki Koperta SOAP Nagłówek (opcjonalny) Ciało (wymagane) Błąd (opcjonalny) Załącznik (opcjonalny)

22 22 REST Brak narzuconego formatu wiadomości, zazwyczaj XML JSON Operacje typu CRUD na zasobach Zasób charakteryzowany przez URI Metody HTTP POST (C) Wstawienie GET (R) Odczyt PUT (U) nadpisanie DELETE (D) usunięcie Rzadziej PATCH częściowa aktualizacja OPTIONS lista dostępnych operacji

23 23 Protokoły komunikacji usług (3) Meta- protokoły (infrastruktura) Koordynacja wykonania usług Negocjacja protokołu wymiany wiadomości Wybór strony nadzorującej wykonanie usługi Ustalenie sposobu osadzenia identyfikatorów we wiadomościach Kontrola wykonania usług Zgodność z protokołami biznesowymi Przydział wiadomości do konwersacji Rozliczenia Np.: WS- CoordinaPon Precyzuje sposób użycia WSDL i SOAP

24 24 Protokoły komunikacji usług (4) Protokoły pośredniczące (poziome) Zapewnienie niezawodności Np.: WS- Reliability Transakcyjność Np.: WS- TransacPon Zarządzane przez infrastrukturę Ukryte przed programistą

25 25 Standardy WS- * Wymienione wcześniej to tylko wierzchołek góry lodowej Patrz: następny slajd

26 26 Biznesowe Systemy Rozproszone Źródło: hlps:// standards- poster/

27 27 SOAP vs REST co lepsze? SOAP Stanowość usług Możliwa Zdalne wywołanie procedur Tak Operacje na zasobach (np.: usługi typu CRUD) Format wiadomości Tak Standaryzowany XML Ograniczenia: XML Schema REST Tak Brak ograniczeń Zazwyczaj JSON, XML Dostępne operacje Dowolne Ustalone GET, POST, PUT, DELETE, OPTIONS Transakcyjność Infrastruktura Ręczna Kompozycja usług Infrastruktura Ręczna Zapewnienie niezawodności Infrastruktura Infrastruktura* W zakresie redundancji serwerów, HTTP Brak wsparcia na poziomie aplikacyjnym

28 28 REST plusy? Niska złożoność infrastruktury Wiele rozwiązań open source Powszechne technologie Niskie koszty wejścia Brak opłat licencyjnych Niewielki nakład pracy Proste założenia Zasoby i kolekcje zasobów Operacje CRUD Łatwość integracji nieskomplikowanych usług

29 29 SOAP vs REST wnioski SOAP REST Zastosowanie Zastosowanie Skomplikowany interfejs usługi Dużo metod Rozbudowane typy danych Kompozycja usług Komunikacja systemów Prosty interfejs usługi Wyrażalny przez CRUD Niska złożoność typów danych Samodzielne usługi Usługi dodatkowe Np.: Strony internetowe

30 30 Architektura usług internetowych

31 31 Dwie perspektywy architektury SOA Perspektywa wewnętrzna Usługa internetowa jest punktem wejścia do wewnętrznego systemu Ukrywa złożoność systemu System zarządzany przez middleware Wiele usług składowych (innych niż internetowe) Raczej homogeniczne Perspektywa zewnętrzna Wiele usług internetowych Brak centralnego zarządcy Meta- protokoły koordynacji usług Zazwyczaj udostępnione publicznie

32 32 Dwie perspektywy architektury SOA (2) Perspektywa zewnętrzna Dostawca usług A Perspektywa wewnętrzna Usługa internetowa Adapter Middleware Klient Aplikacja kliencka Internet Dostawca usług C Usługa C1 Usługa C2 Usługa C3 Usługa 1 Usługa 2 UDDI Dostawca usług B Dostawca usług D Usługa B1 Usługa B2

33 33 Dwie perspektywy architektury SOA (3) Podział architektury Nie musi wynikać z różnych dostawców Można wykorzystać podobne rozgraniczenie wewnątrz jednego przedsiębiorstwa Ważny dla zrozumienia przeznaczenia technologii Technologie/produkty wyłącznie do zastosowań wewnętrznych Technologie dla zastosowań zewnętrznych Standaryzacja Głównie perspektywa zewnętrzna

34 34 Perspektywa wewnętrzna Usługa internetowa Kolejny poziom w architekturze n- Per Spina funkcjonalność poziomów niższych Rola komponentu prezentacji Rola adaptera formatu wiadomości

35 35 Perspektywa zewnętrzna Usługa internetowa Autonomiczny, izolowany komponent Połączenia peer- to- peer Katalog usług (UDDI) Może być postrzegany jako globalny zarządca Opcjonalny Brak wglądu w szczegóły implementacyjne usługi Brak kontroli nad wykonaniem usług Kontrola nad dostępem do definicji interfejsów usług, ale nie do usług!

36 36 Wiązanie usług internetowych Statyczne Dynamiczne

37 37 Wiązanie statyczne Lokalna konfiguracja klienta URI usługi Dane dostępowe Opis interfejsu Parametry protokołów biznesowych Silne związanie klienta z usługą Dobra wydajność Nie trzeba wyszukiwać usługi Ponowne wdrożenie (zmiana konfiguracji) klienta Przerwy techniczne, awarie Zmiana adresu usługi Zmiana interfejsu usługi Zmiana parametrów protokołów biznesowych Trudno zapewnić jawne równoważenie obciążenia (przez świadomy wybór innej usługi przez klienta)

38 38 Wiązanie dynamiczne Lokalna konfiguracja usługi URI katalogu usług Konfiguracja pobierana z katalogu usług URI usługi Dane dostępowe Opis interfejsu usługi Parametry protokołów biznesowych Dodatkowy poziom abstrakcji Gorsza wydajność wymaga odpytania dodatkowej usługi Dodatkowe ogniwo podatne na awarie Większa elastyczność Zmiana w usługach nie pociąga za sobą zmiany w kliencie

39 39 Garść statystyk

40 40 ProgrammableWeb Nietypowa usługa katalogowa Portal katalogujący publiczne API usług Wyszukiwarka usług Przykłady użycia usług Ponad usług

41 41 Źródło: hlp:// research

42 42 Źródło: hlp:// research

43 43 Standardy w użyciu Źródło: hlp:// losing- its- flair- rest- api- alternapves/analysis/2013/12/19

44 44 Źródło: hlp:// glue- conmay2010

45 45 Źródło: hlp:// glue- conmay2010

46 46 Popularność wśród programistów Źródło: hlps://

47 47 Popularność wśród programistów (2) Źródło: hlps://

48 48 Dziękuję za uwagę Proszę o pytania