architektura soa

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


• 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


• 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


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


• 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


• 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


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

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

architektura soa

Documents