Architektura SOA.

Prezentacja na temat: "Architektura SOA."— Zapis prezentacji:

1 Architektura SOA

2 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

3 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

4 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

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

6 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

7 Architektura zorientowana na usługi

8 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

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

10 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

11 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

12 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

13 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

14 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

15 Architektura wywołania komponentu Web Service

16 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

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

18 Komunikat SOAP zawierający wywołanie komponentu Web Service
<?xml version="1.0"?> <soap:Envelope xmlns:soap=" soap:encodingStyle=" <soap:Body xmlns:m="demo"> <m:multiply> <m:val1>3</m:val1> <m:val2>2</m:val2> </m:multiply> </soap:Body> </soap:Envelope>

19 Komunikat SOAP zawierający wynik wywołania komponentu Web Service

20 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

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

22 Kod klienta Web Service w języku Java

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

24 Dynamiczne wywołanie komponentu usługowego Web Service

25 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

26 Struktura znaczników dokumentu WSDL

27 WSDL Element definiujący <definitions>
<?xml version="1.0" encoding="UTF-8"?> <wsdl:definitions name="dyskusja" targetNamespace=" xmlns:tns=" xmlns:bpws=" xmlns:soapenc=" xmlns:plnk=" xmlns:xsd=" xmlns:soap=" xmlns:wsdl="

28 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:output message="tns:zapisaneopiniealert"/> </wsdl:portType>

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

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

31 Przykładowy dokument WSDL

32 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

33 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

34 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

35

36

37

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

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

40 BPEL4WS Element otrzymania <receive> Połączenia <link>
<receive createInstance="yes" name="ReceiveNowaOpinia" operation="wymienienieopini" partnerLink="DodaneOpiniePLT" portType="ns1:WymianaOpinii" variable="nowaopinia"> <links> <link name="L6"/> </links> (...) <source linkName="L6"/>

41 BPEL4WS Element przełącznik <switch> <switch>
<target linkName="L6"/> <case condition="bpws:getVariableData('DeadlineDyskusji') !=0"> (...) </case> <otherwise> </otherwise> </switch>

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

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

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

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

46

47

48 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

49 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

50 Tworzenie serwisu

51 Przykładowy serwis

52

53

54

55

56 Programowe wywołanie usługi

57 Wynik

58 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