Post on 13-Jan-2016
description
Architektura SOA
Architektura oparta na usługach
• (ang. Service Oriented Architecture, SOA) jest to koncepcja tworzenia systemów informatycznych, w której główny nacisk stawia się na definiowanie usług, które spełnią wymagania użytkownika
• Pojęcie SOA obejmuje zestaw metod organizacyjnych i technicznych mający na celu lepsze powiązanie biznesowej strony organizacji z jej zasobami informatycznymi
• Mianem usługi określa się tu każdy element oprogramowania, mogący działać niezależnie od innych oraz posiadający wyspecyfikowany interfejs, za pomocą którego udostępnia realizowane funkcje
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
• Dodatkowo, istnieje wspólne, dostępne dla wszystkich medium komunikacyjne, umożliwiające swobodny przepływ danych pomiędzy elementami platformy
• Architektura SOA podobna jest do obiektów rozproszonych, jednak opisuje rozwiązanie na wyższym poziomie abstrakcji.
• Interfejsy usług są zazwyczaj definiowane w sposób abstrakcyjny i niezależny od platformy programistycznej
Architektura oparta na usługach
• Również same usługi są często implementowane na bazie różnych technologii i udostępniane za pomocą niezależnego protokołu komunikacyjnego
• Do modelowania procesów biznesowych realizowanych w SOA można wykorzystywać notację BPMN przygotowaną m. in. do opisu tej klasy zagadnień
• W modelach takich komunikacja z usługami jest modelowana jako zdarzenia typu wyślij/odbierz wiadomość (komunikat) zawierająca odpowiednie dane wysłane/pobierane do/od usługi
Architektura oparta na usługach
• SOA, czyli architektura zorientowana na usługi nie jest pojęciem nowym, ale dopiero seria standardów Web services pozwala na jej poważne stosowanie w produkcyjnie działających środowiskach
• System w architekturze SOA to kolekcja niezależnych usług, komponentów, które realizują jakąś funkcję biznesową
Architektura oparta na usługach
• Poszczególne usługi mogą być wywoływane i "konsumowane" współbieżnie z innymi usługami w ramach SOA wliczając w to zewnętrzne systemy wspierające tą architekturę
• Dzięki temu raz napisana funkcjonalność może być wielokrotnie wykorzystywana i łatwo zintegrowana z innymi usługami
Architektura zorientowana na usługi
Web services
• Web services (czyli usługi sieciowe) to tak naprawdę pierwsza technologia , która ma szanse zrealizować w pełni wizję jaką proponuje model SOA
• WS 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) i transportów internetowych
Web services
• Web services wykorzystują standard XML do definiowania zarówno danych, jak i zbiorów instrukcji dla serwera
• Od niego odchodzą trzy podstawowe "odnogi",czyli SOAP (Simple Object Acces Protocol), WSDL (Web Services Description Language) i UDDI (Universal Description, Discovery and Integration)
Web services
• SOAP (Simple Object Acces Protocol) definiuje protokół komunikacyjny XML dla podstawowych operacji wymiany komunikatów pomiędzy serwerami 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
Web services
• UDDI (Universal Description, Discovery, and Integration) jest standardem opisującym infrastrukturę do publikowania i przeszukiwania usług w uporządkowany sposób
• SOAP, WSDL, UDDI razem pozwalają się nawzajem widzieć i współdziałać zgodnie z luźno związanym modelem niezależnym od platformy
Web services
• Z Web services związanych jest szereg organizacje standaryzacyjnych, takich jak WC3, IEFT, OASIS (Organization for the Advanced of Structured Information Standards) czy UN/CEFACT, które stawiają sobie za cel zaprojektowanie zestawu specyfikacji pozwalających realizację koncepcji B2B i e-collaboration
• Takie formy jak Microsoft, Sun, IBM, Oracle, Hewlett-Packard czy BEA Systems - uczestniczą w rozwoju nowej technologii i każdy z nich chce dostarczać w miarę kompletną platformę Web services
Protokoły biznesowe
• Protokoły biznesowe opisują zachowania zależne od danych, np. kształt protokołu stosowany do realizacji dostaw jest zależny od liczby linii zamówienia, globalnej wartości zamówienia czy terminu realizacji
• Definiując proces należy korzystać z konstrukcji warunkowych i zależnych od upływu czasu
• Konieczne jest przewidywanie wyjątków i opis procedur postępowania w przypadkach nietypowych
Protokoły biznesowe
• Długotrwałe interakcje dotyczą wielu, często powiązanych obiektów posiadających własną strukturę
• Protokoły biznesowe muszą uwzględniać koordynację działań na obiektach w zależności od wyników realizowanych na nich procesów na różnym poziomie agregacji
Architektura wywołania komponentu Web Service
SOAP (Simple Object Access Protocol)
• Prosty protokół komunikacyjny oparty na języku XML, umożliwiający przekazywanie wywołań zdalnych komponentów Web Services
• SOAP może współdziałać z dowolnym niskopoziomowym sieciowym mechanizmem transportowym, np. HTTP, HTTPS, SMTP, JMS, RMI
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 komponentu Web Service
<?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 komponentu Web Service
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
Web Services - implementacja
• Implementacja środowiska aplikacyjnego w technologii Web Services 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 XML-owych 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, .NET).
Kod klienta Web Service w języku Java
Web Service Description Language
• Koncepcja automatycznego generowania kodu komunikacyjnego w oparciu o zestaw parametrów sieciowych opisujących komponent usługowy
• Twórca komponentu Web Service opisuje jego interfejs w języku WSDL (Web Service Description Language), a twórca klienta Web Service dokonuje zautomatyzowanej transformacji tego opisu do kodu źródłowego obsługującego komunikację sieciową z komponentem (tzw. Web Service Proxy) w wybranym języku programowania.
Dynamiczne wywołanie komponentu usługowego Web Service
Strukturę znaczników dokumentu WSDL
• Role znaczników WSDL: • <definitions> otacza całą zawartość dokumentu
• <service> wraz ze znacznikami <port> definiują adresy punktów dostępowych dla usługi
• <portType> służą do deklaracji funkcji biznesowych oferowanych przez usługę
• <binding> określają metody kodowania parametrów wywołania i parametrów zwrotnych usługi
Struktura znaczników dokumentu WSDL
WSDL
• Element definiujący <definitions>
<?xml version="1.0" encoding="UTF-8"?><wsdl:definitions name="dyskusja" targetNamespace="http://firma.pl" xmlns:tns="http://firma.pl" xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/business-process/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
WSDL
• Interfejs <portType>
<wsdl:portType name="PowiadomSystem"> <wsdl:operation name="powiadomienie"> <wsdl:input message="tns:nowaopinia"/> <wsdl:output message="tns:zapisaneopinie"/> </wsdl:operation> </wsdl:portType>
<wsdl:portType name="WymianaOpinii"> <wsdl:operation name="wymienienieopini"> <wsdl:input message="tns:nowaopinia"/> <wsdl:output message="tns:zapisaneopinie"/> </wsdl:operation> <wsdl:operation name="wymienienieopini_alert"> <wsdl:input message="tns:nowaopinia"/> <wsdl:output message="tns:zapisaneopiniealert"/> </wsdl:operation> </wsdl:portType>
WSDL
• Przesyłanie wiadomości <message>
<wsdl:message name="zapisaneopinie"> <wsdl:part name="dotychczasoweopinie" type="xsd:string"/> </wsdl:message>
<wsdl:message name="nowaopinia"> <wsdl:part name="opinia" type="xsd:string"/> <wsdl:part name="zaznaczone" type="xsd:anyURI"/> </wsdl:message>
WSDL
• „Linki partnerujące“ <PartnerLinkType>
<plnk:partnerLinkType name="DodaneOpiniePLT"> <plnk:role name="dodawanieRO"> <plnk:portType name="tns:WymianaOpinii"/> </plnk:role></plnk:partnerLinkType>
<plnk:partnerLinkType name="ZapisWSystemiePLT"> <plnk:role name="zapis"> <plnk:portType name="tns:PowiadomSystem"/> </plnk:role></plnk:partnerLinkType>
Przykładowy dokument WSDL
BPEL4WS
• Rozwijany w ramach organizacji OASIS i zatwierdzony w 2003 r. standard Business Process Execution Language for Web Services 1.1 (BPEL4WS, BPEL) to uniwersalny język opisu procesów biznesowych oparty na koncepcji SOA i standardach Web Services
• Budowanie środowisk integracyjnych opartych na koncepcji SOA nie jest na razie powszechne
The Business Process Execution Language for Web Services
(BPEL4WS) • BPEL4WS definiuje model i gramatykę opisu procesów
biznesowych w oparciu o interakcje zachodzące między nimi i ich uczestnikami
• Interakcje zachodzące pomiędzy wszystkimi użytkownikami Web Service na poziomie interfejsu są kapsułkowane w obiekcie zwanym partner link
• Proces BPEL4WS definiuje sposób koordynacji interakcji serwisowych realizowanych dla potrzeb osiągania celów biznesowych oraz przejścia stanowe i logikę niezbędną do tej koordynacji
The Business Process Execution Language for Web Services
(BPEL4WS) • BPEL4WS wprowadza także systematyczny
mechanizm obsługi wyjątków i błędnie działających procesów
• BPEL4WS wprowadza mechanizm definiowania jak pojedyncze czynności wewnątrz procesów mogą być zastępowane w przypadku wystąpienia wyjątków lub zmiany potrzeb użytkownika
• BPEL4WS wykorzystuje notację XML i pozwala tworzyć wykonywalne aplikacje
BPEL4WS
• Linki partnerujące <PartnerLinkType>
<partnerLinks> <partnerLink myRole="dodawanieRO" name="DodaneOpiniePLT" partnerLinkType="ns1:DodaneOpiniePLT"/> <partnerLink name="ZapisWSystemiePLT" partnerLinkType="ns1:ZapisWSystemiePLT" partnerRole="zapis"/> <partnerLink myRole="orderProcess" name="orderProcessPLT" partnerLinkType="ns2:orderProcessPLT"/> </partnerLinks>
BPEL4WS
• Określenie zmiennych <variables>
<variables> <variable messageType="ns1:nowaopinia" name="nowaopinia"/> <variable messageType="ns1:zapisaneopinie" name="zapisaneopinie"/> <variable messageType="ns1:nowaopinia" name="nowaopiniasys"/> <variable messageType="ns1:zapisaneopinie" name="zapisaneopiniesys"/> <variable name="DeadlineDyskusji" type="xsd:dateTime"/> <variable messageType="ns1:nowaopinia" name="nowaopinia1"/> <variable messageType="ns1:zapisaneopiniealert" name="zapisaneopiniealert"/> </variables>
BPEL4WS
Element otrzymania <receive>
• Połączenia <link> <links> <link name="L6"/> </links> (...) <source linkName="L6"/>
<receive createInstance="yes" name="ReceiveNowaOpinia" operation="wymienienieopini" partnerLink="DodaneOpiniePLT" portType="ns1:WymianaOpinii" variable="nowaopinia">
BPEL4WS
• Element przełącznik <switch>
<switch> <target linkName="L6"/> <case condition="bpws:getVariableData('DeadlineDyskusji') !=0"> (...) </case> <otherwise> (...) </otherwise> </switch>
BPEL4WS
• Podstawienie zmiennych <assign>
<assign name="AssignDodajDoOpinii"> <target linkName="L4"/> <source linkName="L5"/> <copy> <from expression="bpws:getVariableData('zapisaneopiniesys', 'dotychczasoweopinie') + bpws:getVariableData('nowaopiniasys', 'opinia')"/> <to variable="zapisaneopiniesys"/> </copy> </assign>
BPEL4WS
• Wywołanie usługi sieciowej <invoke>
<invoke inputVariable="nowaopiniasys" name="InvokePowiadomInnych" operation="powiadomienie" outputVariable="zapisaneopiniesys" partnerLink="ZapisWSystemiePLT" portType="ns1:PowiadomSystem"> <source linkName="L4"/> <source linkName="L1"/> </invoke>
BPEL4WS
• Element wyboru <pick>
<pick> <target linkName="L1"/> <source linkName="L7"/> <onMessage operation="wymienienieopini_alert" partnerLink="DodaneOpiniePLT" portType="ns1:WymianaOpinii" variable="nowaopiniasys"> <assign name="GdyWPorzadku"> <copy> <from expression="concat("Ustalono koniec dyskusji na ", bpws:getVariableData('DeadlineDyskusji') )"/> <to variable="zapisaneopiniealert"/> </copy> </assign> </onMessage>
BPEL4WS
• Element wyboru <pick></onMessage> <!-- Gdy zostanie osiagnieta zmienna DeadlineDyskusji system powiadomi o tym --> <onAlarm for="bpws:getVariableData('DeadlineDyskusji')"> <assign name="GdyCzasMinal"> <copy> <from expression="concat("Wlasnie minal ustalony czas dyskusji ", bpws:getVariableData('DeadlineDyskusji'))"/> <to variable="zapisaneopiniealert"/> </copy> </assign> </onAlarm> </pick>
Web Services
• Web Service’y, określane również jako usługi sieciowe, umożliwiają budowę prostych, rozproszonych aplikacji, niezależnych od platformy. W swoim działaniu wykorzystują one powszechnie znany standard XML
• Dostęp do usług sieciowych jest również niezwykle prosty, dzięki zastosowaniu standartowych protokołów, takich jak HTTP czy SOAP
• Web Service’y 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 Web Service, co więcej – nie musi nawet posiadać wiedzy na temat budowy usługi
• Jedyne, co jest potrzebne, do wykorzystywania tej technologii, jest internetowy adres usługi, oraz nazwy metod przez nią udostępnianych
Tworzenie serwisu
Przykładowy serwis
Programowe wywołanie usługi
Wynik
Uwagi końcowe
• Wymienianie danych w ten sposób 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 są 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