Web services

Architektura zorientowana na usługi
ang. Service Oriented Architecture
Architektura oparta na
usługach
• SOA (ang. Service Oriented Architecture) to architektura dla aplikacji
biznesowych tworzonych jako zestaw samodzielnych komponentów,
organizowanych tak, aby dostarczyć usługi, działające według
określonych kryteriów, wspierające realizację procesów biznesowych
• Usługa w ujęciu SOA jest pojedynczym komponentem dostarczanym
przez IT do biznesu, wspierającym realizację określonego zadania
występującego w jednym lub więcej procesów biznesowych
• System w architekturze SOA to kolekcja usług, świadczonych przez
niezależne komponenty, które realizują jakąś funkcję biznesową
• SOA to koncepcja a nie technologia
2
Architektura zorientowana
na usługi
Architektura oparta na
usługach
• Sposób działania każdej usługi jest w całości zdefiniowany
przez interfejs ukrywający szczegóły implementacyjne niewidoczne i nieistotne z punktu widzenia klientów
• Interfejsy usług są zazwyczaj definiowane w sposób
abstrakcyjny i niezależny od platformy programistycznej
• Istnieje wspólne medium komunikacyjne, umożliwiające
swobodny przepływ danych pomiędzy komponentami
• Usługi są często implementowane na bazie różnych
technologii i udostępniane za pomocą niezależnego
protokołu komunikacyjnego
Cechy SOA (1)
http://simplicable.com/new/the-9-principles-of-soa-design
• Standaryzowane kontrakty
• Luźne powiązania
(minimalna zależność
usług od siebie)
• Warstwa abstrakcji
(usługa ukrywa swoja
wewnętrzną logikę przed klientem)
5
Cechy SOA (2)
• Ponowne użycie
(podział logiki na usługi
sprzyja ponownemu użyciu)
• Autonomia
(usługa ma całkowitą kontrolę
nad swoją logiką)
• Bezstanowość
6
Cechy SOA (3)
• Możliwość wyszukiwania usług
• Możliwość komponowania usług
• Interoperacyjność usług
7
Web services
• Web services (czyli usługi sieciowe) – realizacja wizji
jaką proponuje model SOA
• Usługi sieciowe to komponenty programowe (obiekty)
reprezentujące funkcje biznesowe dostępne dla innych
aplikacji (klienta, serwera, czy innej usługi) za
pośrednictwem sieci publicznej i przy użyciu ogólnie
dostępnych, powszechnych protokołów (np. HTTP)
Web services
• Usługi sieciowe wykorzystują standard XML do definiowania
danych i operacji
• Standardy:
–
–
–
–
SOAP – protokół komunikacyjny
WSDL – język opisu usług
UDDI – język do opisu infrastruktury do wykrywania usług
WS-BPEL – język opisujący integrację usług
Web services
• SOAP (Simple Object Acces Protocol) definiuje protokół komunikacyjny
XML dla podstawowych operacji wymiany komunikatów pomiędzy
komponentami za pośrednictwem tzw. kopert zawierających instrukcje
dla poszczególnych żądań
• WSDL (Web Services Description Language) to opracowany przez firmę
Microsoft specjalny język opisu usług
• UDDI (Universal Description, Discovery, and Integration) jest
standardem opisującym infrastrukturę do publikowania i przeszukiwania
usług w uporządkowany sposób
• WS-BPEL - deklaratywny język znaczników XML służący do opisu
wykonywania procesów biznesowych korzystających z usług sieciowych
Web services
• Z usługami sieciowymi związanych jest szereg organizacji
standaryzacyjnych, takich jak W3C, OASIS (Organization
for the Advanced of Structured Information Standards)
• Wszystkie znaczące firmy (Microsoft, Sun, IBM, Oracle,
Hewlett-Packard, BEA Systems) uczestniczą w rozwoju
nowej technologii i każda z nich chce dostarczać w miarę
kompletną platformę dla usług sieciowych
Web services
• Implementacja systemu w technologii usług sieciowych jest
możliwa w dowolnym z języków programowania
• W celu ułatwienia implementacji obsługi protokołu SOAP,
programiści Java mogą korzystać z biblioteki Java API for
XML-based RPC (JAX-RPC), która wyręcza ich z
konieczności konstrukcji, przesyłania i parsowania XMLowych komunikatów SOAP
•
Analogiczne biblioteki są dostępne dla innych popularnych
języków programowania (np. SOAP::Lite dla Perla, gSOAP
dla C/C++, ZSI dla Pythona, WCF dla .NET).
Web services
• Usługi sieciowe umożliwiają budowę prostych,
rozproszonych aplikacji, niezależnych od platformy
• Dostęp do usług sieciowych jest również niezwykle prosty,
dzięki zastosowaniu standartowych protokołów, takich jak
HTTP czy SOAP
• Usługi sieciowe mogą być wykorzystywane do integracji
aplikacji tworzonych w rozmaitych językach programowania,
na różnych platformach deweloperskich
Web Services
• Jedną z ich najważniejszych zalet jest fakt, że aplikacja
kliencka, która chce skorzystać z udostępnianej usługi, nie
musi być stworzona w tym samym języku co usługa
sieciowa, co więcej – nie musi nawet posiadać wiedzy na
temat budowy usługi
• Jedyne co jest potrzebne do wykorzystywania tej technologii
to internetowy adres usługi oraz nazwy metod przez nią
udostępnianych
Tworzenie serwisu
Przykładowy serwis
Programowe wywołanie
usługi
Wynik
Zalecenia projektowe
• Wymienianie danych w usługach sieciowych jest dość kosztowne,
ponieważ wykorzystuje komunikację sieciową
• Lepiej więc korzystać z usługi rzadziej, za to za jednym razem żądając
większej ilości danych wynikowych
• Dane mogą być przesyłane przez sieć w sposób niezaszyfrowany,
wykorzystując format XML, co ułatwia ich odczytanie przez
nieuprawnione osoby
• Projektując tego typu usługę musimy wziąć pod uwagę fakt, że może
być ona jednocześnie używana przez setki, a nawet tysiące osób
• Trzeba więc myśleć o skalowalności aplikacji, aby była ona w stanie
obsłużyć określoną ilość użytkowników
SOAP (Simple Object
Access Protocol)
• Prosty protokół komunikacyjny oparty na języku XML,
umożliwiający przekazywanie wywołań zdalnych
komponentów usług sieciowych
• SOAP może współdziałać z dowolnym niskopoziomowym
sieciowym mechanizmem transportowym, np. HTTP,
HTTPS, SMTP, JMS, RMI
SOAP (Simple Object
Access Protocol)
• Protokół SOAP umożliwia wywoływanie komponentów Web
Service w dwóch trybach: (1) Remote Procedure Call (RPC)
i (2) dokumentowym (document-oriented)
• W trybie RPC wywołanie ma charakter tradycyjny –
komponentowi przekazywana jest lista parametrów
formalnych wraz z ich bieżącymi wartościami
• W trybie dokumentowym usługa otrzymuje tylko jeden
parametr wywołania, którym jest dokument XML
SOAP (Simple Object
Access Protocol)
• Podstawowymi znacznikami wykorzystywanymi do budowy
komunikatów SOAP są:
–
–
–
–
<Envelope> – otacza cały komunikat
<Header> – zawiera informacje nagłówkowe
<Body> – zawiera informacje o żądaniu i odpowiedzi
<Fault> – opisuje błędy, jakie wystąpiły podczas przetwarzania
wywołania
Komunikat SOAP zawierający
wywołanie usługi sieciowej
<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Body xmlns:m="demo">
<m:multiply>
<m:val1>3</m:val1>
<m:val2>2</m:val2>
</m:multiply>
</soap:Body>
</soap:Envelope>
Komunikat SOAP zawierający
wynik wywołania usługi
sieciowej
WSDL
• WSDL (Web Service Description Language) jest językiem
znaczników XML przeznaczonym do opisu usług sieciowych
• Podstawowe elementy dokumentu WSDL
– types – definicje typów danych
– message – dane wymieniane pomiędzy dostawcą usługi a jej
konsumentem
– portType – kolekcja operacji udostępnianych przez usługę
– binding – wiązanie operacji z protokołami
29
Struktura znaczników
dokumentu WSDL
Wzorce wymiany
komunikatów w WSDL
• Request-Responce – żądanie (klient) – odpowiedź (serwis)
• One-Way – komunikat w jedną stronę
• Notification - powiadomienie
• Solicit-Responce – prośba (serwis) – odpowiedź (klient)
31
Wzorce komunikatów w
WSDL – przykład
• Serwis usług pogodowych dostarcza prognozy pogody dla
swoich klientów
• Klient serwisu musi zasubskrybować się do serwisu aby
móc otrzymywać prognozę pogody
• Serwis pogodowy po otrzymaniu żądania subskrypcji
weryfikuje klienta wysyłając do niego żądanie i oczekując
odpowiedzi
• Serwis przesyła co pewien ustalony czas dane pogodowe
do klienta
• W dowolnym momencie klient może zażądać zmiany
danych pogodowych, jakie do niego są przesyłane
32
Request-Responce
Request<input>
Responce<output>
Client
Service
<portType name="WetherSubscribingPT">
<operation name="subscribe">
<input message="tns:subscribe"/>
<output message="tns:subscribeResponse"/>
</operation>
</portType>
33
One-Way
Request<input>
Client
Service
<portType name="UpdatePT">
<operation name="weatherUpdate">
<input message="tns:weatherUpdate"/>
</operation>
</portType>
34
Notification
Responce<output>
Klient
Usługa
<portType name="WetherPT">
<operation name="weatherNotification">
<output message="tns:weatherNotification"/>
</operation>
</portType>
35
Solicit-Responce
Request<output>
Responce<input>
Client
Service
<portType name="SubscriptionPT">
<operation name="verifySubscription">
<output message="tns:verifySubscription"/>
<input message="tns:verifySubscriptionResponse"/>
</operation>
</portType>
36
Integracja usług
• Udostępnienie usług to jednak dopiero pierwszy krok do
realizacji bardziej złożonych scenariuszy współpracy systemów
informatycznych
• Do realizacji bardziej złożonych scenariuszy wymagane jest by
usługi współpracowały ze sobą w pewien uporządkowany
sposób, tj. zgodnie z opracowanym wcześniej modelem procesu
współpracy
• Procesowe podejście do architektury SOA wymaga języka
opisującego jak usługi sieciowe mogą być komponowane w
większe struktury, aby umożliwić realizację bardziej złożonych
procesów
37
Aranżacja usług
• Istnieje centralny komponent koordynujący wywołania usług
składowych
• Usługi składowe nie mają świadomości uczestniczenia w procesie
wyższego poziomu
Usługi
sieciowe
3. invoke
koordynator
1. receive
2. invoke
4. reply
38
Choreografia usług
• Brak centralnego koordynatora
• Usługi komunikują się ze sobą bezpośrednio
• Każda usługa posiada cząstkową wiedzę o procesie w którym
uczestniczy
• Komunikacja pomiędzy usługami jest typu peer-to-peer
Usługi
sieciowe
2. invoke
3. invoke
4. reply
1. invoke
39
Aranżacja vs. Choreografia
Aranżacja
Choreografia
Bardziej elastyczna
Mniej elastyczna
Kolejny proces nie wymaga
modyfikacji kodu źródłowego
Każdy kolejny proces wymaga
ingerencji w kod usługi
Wymaga dodatkowego
komponentu koordynującego
Nie jest potrzebny żaden
dodatkowy komponent
40
Web Service Business Process
Execution Language (WSBPEL)
•
Deklaratywny język znaczników XML służący do opisu wykonania procesów
biznesowych korzystających z usług sieciowych (Web services)
•
Powstał z połączenia rozwiązań Microsoftu (XLANG) oraz IBM (WSFL) w
2003 roku (BPEL4WS 1.0)
•
Obecnie jest utrzymywany i rozwijany przez organizację OASIS (WS-BPEL
2.0)
•
Nie posiada formalnej notacji graficznej, niemniej każdy dostawca taką
notację do swojego produktu wprowadza
•
BPEL jest używany do integracji procesów wewnątrz organizacji, pomiędzy
organizacjami (B2B), ale również w systemach gridowych
•
BPEL wspiera integrację usług w oparciu o model aranżacji
41
Typowy proces BPEL
• Proces otrzymuje żądanie od klienta
• Aby zrealizować żądanie, korzysta z partnerskich usług sieciowych
• Po wykonaniu wszystkich koniecznych kroków przekazuje wynik do
klienta
Proces
BPEL
Partnerskie
usługi sieciowe
Aplikacja
klienta
Silnik
BPEL
42
Przykład* – sformułowanie
problemu
• Opis otoczenia
– Sprzedawcy udostępniają usługę sieciową działającą w trybie
asynchronicznym, która po przesłaniu danych produktu zwraca jego
aktualna cenę
– Dostępna jest również usługa sieciowa składowania danych w
repozytorium, która może być użyta do zapisywania wyników
zapytania o cenę – usługa działa w trybie synchronicznym
• Cel procesu
–
–
–
–
Odebranie danych o produkcie do sprawdzenia
Sprawdzenie ceny u dwóch sprzedawców i wybrane lepszej oferty
Zachowanie najlepszej oferty w repozytorium
Przekazanie wyników do klienta
* Na podstawie http://www.oracle.com/technetwork/articles/matjaz-bpel1-090575.html
43
Specyfikacja procesu w
BPMN
Uruchomienie procesu
z argumentem Query
Asynchroniczne wywołanie
usługi z argumentem Query
Proces BPEL
2.1. invoke
3.1. invoke
2.2. callback
3.2. callback
Partner: SellerB
Partner: SellerA
Usługa przekazuje
wynik - AnswerB
Synchroniczne
wywołanie usługi
1. invoke
4.1 invoke
4.2. reply
Partner: Repository
4. callback
Partner: Client
44
Proces przekazuje
wynik - Answer
Opis procesu i usług
• Specyfikacja procesu
– BestOffer.bpel – zawiera definicję procesu wykonywalnego w
języku WS-BPEL
• Specyfikacja usług
– Seller.wsdl – dokument WSDL usługi udostępnianej przez
sprzedawców (zakładamy, że wszyscy sprzedawcy udostępniają
identyczną usługę )
– Repository.wsdl – dokument WSDL usługi repozytorium
– BestOffer.bpel.wsdl – dokument WSDL usługi, którą tworzy
proces WS-BPEL (proces BPEL jest usługą sieciową!)
45
Specyfikacja procesu w WSBPEL
<process name="FindBestOffer" ... >
<partnerLinks> ... </partnerLinks>
<variables> ... </variables>
<sequence>
<receive ... />
<flow>
<sequence>
<invoke ... />
<receive ... />
</sequence>
<sequence>
<invoke ... />
<receive ... />
</sequence>
</flow>
<if>
<condition>...</condition>
<assign .../>
<else>
<assign .../>
</else>
</if>
<invoke ... />
<invoke ... />
</sequence>
</process>
46
Koniec
47