1 / 58

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

silver
Download Presentation

Architektura SOA

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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="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>

  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) RemoteProcedureCall (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 parsowaniaXML-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 DescriptionLanguage), 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>

  28. WSDL • Interfejs <portType>

  29. WSDL • Przesyłanie wiadomości <message>

  30. WSDL • „Linki partnerujące“ <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. BPEL4WS • Linki partnerujące <PartnerLinkType>

  36. BPEL4WS • Określenie zmiennych <variables>

  37. BPEL4WS Element otrzymania <receive> • Połączenia <link>

  38. BPEL4WS • Element przełącznik <switch>

  39. BPEL4WS • Podstawienie zmiennych <assign>

  40. BPEL4WS • Wywołanie usługi sieciowej <invoke>

  41. BPEL4WS • Element wyboru <pick>

  42. BPEL4WS • Element wyboru <pick>

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

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

  45. Tworzenie serwisu

More Related