Modelowanie, projektowanie i implementacja usług Web Services Maciej Zakrzewicz
Plan wykładów 2 Wprowadzenie do architektury SOA Przegląd technologii usług Web Services Przegląd technologii XML Schema Projektowanie i implementacja usług Web Services Strategie konstrukcji środowisk SOA Analiza systemowa zorientowana na usługi Przegląd pozostałych produktów Oracle wspomagających konstrukcję środowisk SOA Oracle Enterprise Service Bus Oracle Web Services Manager Oracle Service Registry
Literatura 3 Enterprise SOA: Service-Oriented Architecture Best Practices, Dirk Krafzig, Karl Banke, Dirk Slama, Prentice Hall PTR, 2004 Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services, Thomas Erl, Prentice Hall PTR, 2004 BPEL Cookbook: Best Practices for SOA-based Integration and Applications Development, editors: Harish Gaur, Markus Zirn, PACKT Publishing, 2006 Service-Oriented Architectures: Concepts, Technology, and Design, Thomas Erl, Prentice Hall PTR, 2005 SOA Technology Center, http://www.oracle.com/technology/tech/soa/index.html Elements of Service-Oriented Analysis and Design, http://www.ibm.com/developerworks/library/ws-soad1/ Understanding the Service Lifecycle within a SOA: Design Time, http://dev2dev.bea.com/pub/a/2006/08/soa-service-lifecycle-design.html Principles of Service Design: Service Patterns and Anti-Patterns, http://msdn2.microsoft.com/en-us/library/ms954638.aspx
Wprowadzenie do architektury SOA
Założenia architektury SOA 5 Service-Oriented Architecture - budowa systemów w oparciu o autonomiczne usługi Logika biznesowa nie stanowi części aplikacji użytkowej, nie ma postaci monolitycznej, lecz jest rozbita pomiędzy wiele rozproszonych komponentów nazywanych usługami Usługi są autonomiczne, bezstanowe, hermetyczne, współdzielone Aplikacje użytkowe są klientami wywołującymi rozproszone usługi w celu realizacji procesów biznesowych Powody, dla których stosuje się SOA: potrzeba szybkiej reakcji na zmiany w funkcjonowaniu przedsiębiorstwa potrzeba współdzielenia (reuse) zasobów w dużym przedsiębiorstwie
Założenia architektury SOA 6 konsument usług dostawca usług aplikacje usługi konsument usług internet dostawca usług
Założenia architektury SOA 7 Usługi mogą być: podstawowe - realizują pojedyncze zadania biznesowe procesowe - komponują usługi podstawowe w procesy biznesowe pośredniczące - pośredniczą w komunikacji z innymi usługami Usługi podstawowe implementowane w technologii Web Services Wykorzystywanie usług ma charakter wymiany komunikatów XML (SOAP) Składnia komunikatów XML opisana w języku XML Schema Interfejsy usług udokumentowane w języku WSDL Usługi procesowe implementowane w technologii BPEL
Własności usług 8 Usługi powinny być współdzielone (reusable) Usługi powinny opierać się na formalnym kontrakcie opisującym ich mechanizmy komunikacji Usługi powinny być słabo sprzężone z innymi usługami Usługi powinny ukrywać szczegóły wewnętrznej implementacji Usługi powinny być komponowalne do postaci usług bardziej złożonych Usługi powinny być autonomiczne Usługi powinny być bezstanowe Usługi powinny być skatalogowane
Rodzaje połączeń i style komunikacji 9 Połączenie RPC-style, komunikacja synchroniczna klient parametr1, parametr2,... wynik interfejs operacja1 oparacja2 operacja3 usługa Połączenie document-style, komunikacja synchroniczna klient usługa
Rodzaje połączeń i style komunikacji 10 Połączenie RPC-style, komunikacja asynchroniczna interfejs klient Message-Oriented Middleware operacja1 oparacja2 operacja3 usługa Połączenie document-style, komunikacja asynchroniczna klient usługa Message-Oriented Middleware
Semantyka wywołania 11 klient konwersjaplnnaeur(10) Semantyka ukryta w interfejsie public float konwersjaplnnausd(float kwota) public float konwersjaplnnaeur(float kwota) public float konwersjaplnnagbp(float kwota)... klient <konwersja> <kwota>10</kwota> <waluta>eur</waluta> </konwersja> public String service(string doc) Semantyka ukryta w komunikacie
Silne sprzężenie - słabe sprzężenie (tight coupling vs. loose coupling) 12 Połączenie silne sprzężenie = bezpośrednie połączenie sieciowe, np. RPC, obie strony komunikacji muszą być równocześnie aktywne i sprawne słabe sprzężenie = połączenie przez pośrednika, np. MOM, kolejki komunikatów pośredniczą w komunikacji, odbiorca może być nieaktywny lub niesprawny Styl komunikacji silne sprzężenie = komunikacja synchroniczna słabe sprzężenie = komunikacja asynchronicza Semantyka silne sprzężenie = semantyka ukryta w interfejsie słabe sprzężenie = semantyka ukryta w komunikacie
Silne sprzężenie - słabe sprzężenie (tight coupling vs. loose coupling) 13 Sterowanie silne sprzężenie = centralne zarządzanie logiką procesową słabe sprzężenie = rozproszone zarządzanie logiką procesową Wiązanie usług silne sprzężenie = usługi powiązane statycznie słabe sprzężenie = usługi powiązane dynamicznie, np. przez UDDI
Rodzaje wymian komunikatów 14 Request-response klient wysyła komunikat żądania do usługi, oczekuje komunikatu odpowiedzi od usługi One-way klient wysyła komunikat żądania do usługi, nie oczekuje odpowiedzi od usługi Solicit-response usługa wysyła komunikat odpowiedzi do klienta, oczekuje komunikatu żądania od klienta Notification usługa wysyła komunikat odpowiedzi do klienta, nie oczekuje komunikatu żądania od klienta Modele "solicit-response" i "notification" nie są zgodne z regułami WS-Interoperability
Składniki architektury SOA 15 interfejs użytkownika usługa usługa xml usługa xml usługa magistrala usług opcjonalne repozytorium usług wsdl
Składniki architektury SOA 16 Interfejs użytkownika (application frontend): moduł inicjujący i monitorujący procesy biznesowe implementowane przez usługi; może mieć zarówno charakter GUI, jak i aplikacji wsadowej (batch) Usługi: implementują operacje biznesowe na wysokim poziomie; usługa składa się z: kontraktu, który specyfikuje przeznaczenie, funkcjonalność, ograniczenia i sposób użycia usługi interfejsu, który udostępnia klientom funkcjonalność usługi implementacji, stanowiącej oprogramowanie funkcjonalności usługi logiki biznesowej, wchodzącej w skład implementacji danych, udostępnianych przez usługę
Składniki architektury SOA 17 Repozytorium usług - składnica opisów usług: nazwy i opisy usług, operacji, argumentów (WSDL, XML Schema) właściciele usług opisy uprawnień SLA właściwości transakcyjne Magistrala usług - łączy uczestników architektury SOA i interfejsy użytkownika zapewnia obsługę komunikacji ukrywa różnice technologiczne ukrywa różnice komunikacyjne dostarcza funkcji technicznych, np. bezpieczeństwo, transformacja komunikatów, transakcje, rejestracja
Klasyfikacja usług 18 Usługi podstawowe: zapewniają podstawową funkcjonalność usługi dano-centryczne - udostępniają dane usługi logiko-centryczne - implementują logikę biznesową lub reguły biznesowe Usługi pośredniczące: umożliwiają współpracę pomiędzy usługami heterogenicznymi technology gateways - umożliwiają komunikację pomiędzy niekompatybilnymi technologiami adaptery - konwertują wywołania usług pochodzące od klientów fasady - agregują interfejsy wielu usług Usługi procesowe: implementują logikę procesową Usługi publiczne: udostępniają interfejsy typu B2B
Klasyfikacja usług 19 usługi podstawowe usługi pośredniczące usługi procesowe usługi publiczne złożoność mała średnia średnia duża duża zależy od usługi zarządzanie stanem bezstanowe bezstanowe stanowe zależy od usługi współdzielenie częste rzadkie rzadkie częste zmienność mała średnia duża mała duża obowiązkowe w SOA tak nie nie nie
Alternatywna klasyfikacja usług 20 Usługi aplikacyjne: reprezentują implementację algorytmów przetwarzania danych, np. usługa dostępu do bazy danych, usługa uwierzytelniania użytkownika Usługi biznesowe: reprezentują logikę funkcjonowania biznesu, np. usługa obsługi zamówień publicznych, usługa obsługi kadrowej pracowników
Wielowarstwowy model usług 21 Biznesowa usługa procesowa Biznesowa usługa pośrednicząca... Biznesowa usługa podstawowa Biznesowa usługa podstawowa... Aplikacyjna usługa pośrednicząca Aplikacyjna usługa podstawowa Aplikacyjna usługa podstawowa
Wprowadzenie do usług Web Services
Technologia Web Services 23 Technologia konstrukcji rozproszonych komponentów usługowych, stanowiących podstawę dla realizacji aplikacji biznesowych w architekturze SOA Usługa Web Service: zwarty, samodokumentujący się komponent programowy, który może być przez swojego twórcę zarejestrowany w sieci komputerowej, a następnie przez twórcę aplikacji-konsumenta odkryty i wywołany w trybie zdalnego wykonania Dowolne języki programowania, dowolne platformy sprzętowo-systemowe
Technologia Web Services 24 klient Web Service call p1(2,5) serializacja wywołań deserializacja wyników komponent Web Service function p1(a,b) function p1(a,b) function p1(a,b)...<p1> <a>2</a> <b>5</b> </p>... komunikat SOAP wyślij żądanie sieciowe Internet deserializacja wywołań serializacja wyników serwer aplikacji HTTP...<p1> <a>2</a> <b>5</b> </p>...
Protokół SOAP 25 Simple Object Access Protocol Prosty protokół komunikacyjny oparty na języku XML, umożliwiający przekazywanie wywołań zdalnych komponentów Web Services Może współdziałać z dowolnym niskopoziomowym sieciowym mechanizmem transportowym, np. HTTP, HTTPS, SMTP, JMS, RMI Dwa tryby wywołań: RPC-style i dokumentowy (documentstyle)
Protokół SOAP 26 <?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:val2>2</m:val2> <?xml version="1.0"?> </m:multiply> <soap:envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" </soap:body> soap:encodingstyle="http://www.w3.org/2001/12/soap-encoding"> </soap:envelope> <soap:body xmlns:m="demo"> Odpowiedź: 6 <m:val1>3</m:val1> <m:multiplyresponse> <m:result>6</m:result> </m:multiplyresponse> </soap:body> </soap:envelope> Żądanie: multiply(2,3)
Pojęcia formalne: usługa Web Service 27 Usługi Web Services służą udostępnianiu zasobów za pośrednictwem komunikatów XML
Pojęcia formalne: komunikaty i operacje 28 Komunikacja z usługami Web Services wymaga precyzyjnego ustalenia interfejsu Podstawowa struktura komunikatów (messages) może być opisana w XML Schema XML Schema nie wystarcza do opisu powiązań pomiędzy komunikatami Wymiana komunikatów nazywana jest "operacją" (operation)
Pojęcia formalne: interfejsy i wiązania 29 Operacje są grupowane w interfejsy (interfaces) Z interfejsami wiązane są protokoły dostępowe Każdy interfejs może posiadać wiele wiązań (bindings) Każde wiązanie jest dostępne pod unikalnym adresem URI nazywanym punktem końcowym usługi (endpoint)
Opis interfejsu usługi w języku WSDL 30 WSDL jest językiem dokumentowania interfejsu usługi Web Services Zwykle WSDL jest jedynym dokumentem współdzielonym przez twórcę usługi i jej konsumenta XML Schema opisuje strukturę komunikatów WSDL umożliwia grupowanie komunikatów w operacje, a operacji w interfejsy WSDL umożliwia wiązanie interfejsów do protokołów i przypisywanie im adresów punktów końcowych
Struktura dokumentu WSDL 31 <definitions name="..." targetnamespace="..." xmlns="http://schemas.xmlsoap.org/wsdl/"> <!-- definicje abstrakcyjne --> <types>... <message>... <porttype>... <!-- definicje konkretne --> <binding>... <service>... </definitions>
Element <types> 32 Definicje typów w postaci schematów XML Do umieszczonych w tym miejscu definicji odwołują się definicje wyższego poziomu Mogą zawierać dowolną liczbę elementów <schema>
Element <message> 33 Definiuje abstrakcyjny komunikat, który ma służyć jako parametr wejściowy lub wyjściowy operacji Komunikat składa się z co najmniej jednego elementu <part> Z elementem <part> związany jest albo atrybut "element" (gdy treść komunikatu stanowi XML), albo atrybut "type" (gdy treść komunikatu to wywołanie RPC)
Element <porttype> 34 Definiuje interfejs (grupę operacji) Zawiera dowolną liczbę elementów <operation> Każdy element <porttype> musi posiadać unikalną nazwę Każdy element <operation> zawiera kombinację elementów <input> i <output> <input>, potem <output> oznacza operację "żądanie-odpowiedź" (request-response) <output>, potem <input> oznacza operację "zaproszenie-odpowiedź" (solicit-response) <input> oznacza operację jednokierunkową (one-way) <output> oznacza operację powiadomienia (notification)
Element <binding> Opisuje szczegóły stosowania konkretnego elementu <porttype> z wybranym protokołem (wiązanie) Dla każdej operacji w <porttype> element <binding> zawiera element <operation> oraz kilka elementów dodatkowych Wiązanie musi posiadać unikalną nazwę 35
Element <service> 36 Definiuje kolekcję elementów <port> i <endpoint>, które udostępniają poszczególne wiązania w sieci Każdy element <port> posiada nazwę i skojarzone wiązanie
Wprowadzenie do XML Schema
Zastosowania XML Schema 38 XML Schema to język znaczników XML służący do definiowania gramatyk dla dokumentów XML XML Schema pozwala określić nazwy dozwolonych znaczników XML, zasady ich zagnieżdżania, typy danych, wartości obowiązkowe, atrybuty Definicje XML Schema mogą być wykorzystywane do automatycznej kontroli poprawności składniowej dokumentów XML - tzw. walidacja XML XML Schema zastępuje starsze rozwiązanie: DTD XML Schema jest powszechnie wykorzystywany przez Web Services i BPEL do opisu struktury zmiennych przechowujących obiekty XML Do tworzenia definicji XML Schema można wykorzystać narzędzia graficzne, np. JDeveloper
XML Schema - przykład 39 <?xml version="1.0" encoding="windows-1250"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/xmlschema" xmlns="http://www.maciej.pl/demo1" targetnamespace="http://www.maciej.pl/demo1" elementformdefault="qualified"> <xsd:element name="zamowienie"> <xsd:complextype> <xsd:sequence> <?xml version="1.0" encoding="utf-8"?> <xsd:element name="produkt" type="string"/> <zamowienie> <xsd:element name="ilosc" type="int"/> <produkt> </xsd:sequence> Nokia E60 </xsd:complextype> </produkt> </xsd:element> <ilosc> </xsd:schema> 120 plik XML Schema (*.xsd) </ilosc> </zamowienie> dokument XML
Konstrukcja definicji XML Schema za pomocą JDevelopera 40
Konstrukcja definicji XML Schema za pomocą JDevelopera 41 przestrzeń nazw dla gramatyki (zwykle w formacie URL, wskaźnik na dokumentację, może być fikcyjny) typ wartości wewnątrz elementu zagnieżdżona sekwencja elementów element=znacznik XML
Wbudowane typy danych XML Schema 42 string boolean float double decimal integer non-negative-integer negative-integer int short byte unsigned-long unsigned-int unsigned-short unsigned-byte date time timeinstant timeduration recurringinstant long binary
Element <simpletype> (restriction) 43 Definicja typu opartego na typie istniejącym Umożliwia zawężenie zbioru dozwolonych wartości <restriction> - zakres wartości <list> - lista wartości <union> - połączenie istniejących typów Element "empid" zawiera wartość typu "empid_type", która reprezentuje liczby całkowite nie większe niż 1000:
Element <simpletype> (list) 44 Element "emailist" zawiera wartośc typu "emailist_type", która reprezentuje listę wartości typu string, oddzielanych spacjami <emailist> a@b.c d@e.f </emailist>
Element <simpletype> (union) 45 Element "all_element" zawiera wartości typu "all_type", który reprezentuje liczby całkowite nie większe niż 1000 lub listę wartości typu string, oddzielanych spacjami
Element <complextype> (sequence) 46 Definicja złożonego, strukturalnego typu danych Może opierać się na treści prostej <sequence> - sekwencji zagnieżdżonych elementów (kolejność określona) <choice> - wyborze jednego z możliwych zagnieżdżonych elementów <all> - zbiorze zagnieżdżonych elementów (kolejność dowolna) Typ "zamowienie_type" reprezentuje strukturę dwóch zagnieżdżonych elementów (znaczników): "produkt" i "ilosc"
Element <complextype> (choice) 47 Typ "faktura_type" reprezentuje jeden z dwóch zagnieżdżonych znaczników: "produkt" lub "usługa". Każdy z tych znaczników może zawierać wartość tekstową
Typy anonimowe 48 =
Definiowanie atrybutów 49 Element (znacznik) "zamowienie" może posiadać atrybut "kod" o wartości tekstowej
Projektowanie i implementacja usług w środowisku Oracle JDeveloper Rozpoczęcie od kontraktu WSDL
Przebieg projektowania i implementacji 51 1. Opracuj formaty XML dla parametrów wejściowych, wyjściowych i wyjątków 2. Opisz formaty XML w języku XML Schema 3. Utwórz dokument WSDL opisujący usługę, jej wiązania, interfejsy, operacje, komunikaty i wyjątki 4. Wygeneruj szkieletowy kod Java w oparciu o dokument WSDL 5. Uzupełnij szkielet Java o kod własnej logiki biznesowej
Opracuj formaty XML dla parametrów wejściowych, wyjściowych i wyjątków 52 <zamowienie> <produkt>nokia E60</produkt> <ilosc>120</ilosc> </zamowienie> klient Web Service <potwierdzenie> <id>567120</id> </potwierdzenie> <wyjatek>! <kod>500</kod> <tekst>brak na magazynie</tekst> </wyjatek>
Opisz formaty XML w języku XML Schema 53 <?xml version="1.0" encoding="windows-1250"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/xmlschema" xmlns="http://www.maciej.pl" targetnamespace="http://www.maciej.pl" elementformdefault="qualified"> <xsd:element name="zamowienie"> <xsd:complextype><xsd:sequence> <xsd:element name="produkt" type="xsd:string"/> <xsd:element name="ilosc" type="xsd:int"/> </xsd:sequence></xsd:complextype> </xsd:element> <xsd:element name="potwierdzenie"> <xsd:complextype><xsd:sequence> <xsd:element name="id" type="xsd:int"/> </xsd:sequence></xsd:complextype> </xsd:element> <xsd:element name="wyjatek"> <xsd:complextype><xsd:sequence> <xsd:element name="kod" type="xsd:int"/> <xsd:element name="tekst" type="xsd:string"/> </xsd:sequence></xsd:complextype> </xsd:element> </xsd:schema>
Opis interfejsu w języku WSDL 54
Dołączanie definicji XML Schema 55
Ręczne poprawki 56
Definiowanie typów komunikatów 57
Definiowanie interfejsu 58
Definiowanie wiązań 59 poprawić błąd:
Wybór formatu komunikatów SOAP 60 Document/Literal - argumenty wywołania przekazywane jako pojedynczy dokument XML, wykorzystywane przez BPEL, zalecany Document/Wrapped - argumenty zagnieżdżone w elemencie complextype RPC/Literal - argumenty przekazywane jako elementy XML RPC/Encoded - argumenty przekazywane jako elementy XML ze wskazaniem typu danych
Definiowanie usługi 61
Wygeneruj szkieletowy kod Java w oparciu o dokument WSDL 62 W oddzielnym projekcie!
Wygenerowane pliki 63 Interfejs Java deklarujący metody udostępnione jako operacje publiczne package wsproj01; public interface ObslugaZamowien extends java.rmi.remote { public pl.maciej.potwierdzenie przyjmijzamowienie(pl.maciej.zamowienie zamowienie) throws pl.maciej.wyjatek, java.rmi.remoteexception; } Klasa dla implementacji operacji package wsproj01; import pl.maciej.potwierdzenie; import pl.maciej.wyjatek; import pl.maciej.zamowienie; public class ObslugaZamowienImpl { public Potwierdzenie przyjmijzamowienie(zamowienie zamowienie) throws Wyjatek { return null; }}
Wygenerowane pliki 64 package pl.maciej; public class Zamowienie implements java.io.serializable { protected java.lang.string produkt; protected int ilosc; Klasy Java implementujące struktury danych reprezentujące typy zdefiniowane w XML Schema public Zamowienie() { } public java.lang.string getprodukt() { return produkt; } public void setprodukt(java.lang.string produkt) { this.produkt = produkt; } public int getilosc() { return ilosc; } public void setilosc(int ilosc) { this.ilosc = ilosc; }} <zamowienie> <produkt>nokia E60</produkt> <ilosc>120</ilosc> </zamowienie>
Wygenerowane pliki 65 package pl.maciej; public class Wyjatek extends Exception { private int kod; private java.lang.string tekst; Klasy Java implementujące wyjątki opisane w WSDL public Wyjatek() { } public Wyjatek(int kod, java.lang.string tekst) { super(tekst); this.kod = kod; this.tekst = tekst; } public void setkod(int kod) { this.kod = kod; } public void settekst(java.lang.string tekst) { this.tekst = tekst; } public int getkod() { return kod; } public java.lang.string gettekst() { return tekst; }}
Wygenerowane pliki 66... <java-xml-type-mapping> <java-type>pl.maciej.zamowienie</java-type> <anonymous-type-qname>{http://www.maciej.pl/}>zamowienie</anonymous-type-qname> <qname-scope>complextype</qname-scope> <variable-mapping> <java-variable-name>produkt</java-variable-name> <xml-element-name>produkt</xml-element-name> </variable-mapping> <variable-mapping> <java-variable-name>ilosc</java-variable-name> <xml-element-name>ilosc</xml-element-name> </variable-mapping> </java-xml-type-mapping>... Plik odwzorowań struktur XML Schema na klasy Java
Implementacja kodu Java dla usługi 67 Klasy wygenerowane automatycznie. Odwzorowują struktury komunikatów XML.
Testowanie usługi 68
Projektowanie i implementacja usług w środowisku Oracle JDeveloper Rozpoczęcie od projektu klasy usługi (JDeveloper 10.1.2)
Utworzenie diagramu klas 70
Generowanie usługi WebService 71
Projektowanie i implementacja usług w środowisku Oracle JDeveloper Rozpoczęcie od implementacji klasy usługi
Implementacja usługi Web Services 73 1. Utwórz klasę Java zawierającą metody logiki biznesowej 2. Skorzystaj z kreatora J2EE Web Service
Wybór formatu komunikatów SOAP 74 Document/Literal - argumenty wywołania przekazywane jako pojedynczy dokument XML, wykorzystywane przez BPEL, zalecany Document/Wrapped - argumenty zagnieżdżone w elemencie complextype RPC/Literal - argumenty przekazywane jako elementy XML RPC/Encoded - argumenty przekazywane jako elementy XML ze wskazaniem typu danych
Strategie konstrukcji środowisk SOA
Poziomy wdrażania SOA 76 Fundamental SOA dwie warstwy: interfejs użytkownika i usługi podstawowe dobry punkt startowy dla ekspansji SOA skomplikowany interfejs użytkownika (zawiera logikę procesową) Networked SOA trzy warstwy: interfejs użytkownika, usługi pośredniczące (fasady), usługi podstawowe odciążony interfejs użytkownika, wciąż jednak zarządza procesami biznesowymi Process-enables SOA cztery warstwy: interfejs użytkownika, usługi procesowe, usługi pośredniczące, usługi podstawowe lekki interfejs użytkownika ukryta złożoność procesów i usług podstawowych
Strategie realizacji SOA 77 Top-Down rozpoczęcie od kontraktu WSDL Bottom-Up rozpoczęcie od implementacji klasy usługi Agile mieszana
Strategia Top-Down Definiowanie klasyfikacji (ontologii) operacji biznesowych w przedsiębiorstwie Klasyfikowanie modeli biznesowych zgodnie z opracowaną strukturą Analiza systemowa zorientowana na usługi Projektowanie zorientowane na usługi Definicja formalnych interfejsów Implementacja usług biznesowych Testowanie wszystkich usług i operacji biznesowych Instalacja usług biznesowych Zalety: wysoka jakość architektury systemu, łatwe współdzielenie usług, łatwa komponowalność nowych procesów Wady: długi czas i wysoki koszt analizy, pierwsze wyniki pojawiają się z opóźnieniem 78
Strategia Bottom-Up 79 Modelowanie wybranych usług aplikacyjnych Projektowanie wybranych usług aplikacyjnych Implementacja wybranych usług aplikacyjnych Definicja formalnych interfejsów Testowanie usług Instalowanie usług Zalety: powszechnie stosowane podejście nie zmienia się architektura systemowa przedsiębiorstwa Wady: "bottom-up strategy is really no strategy at all..." nie prowadzi do nowoczesnej architektury SOA
Strategia Agile (meet-in-the-middle) 80 Rozpoczynamy analizę Top-Down, konstruując klasyfikację (ontologię) dla przedsiębiorstwa Analiza systemowa zorientowana na usługi Projektowanie zorientowane na usługi Definicja formalnych interfejsów Implementacja, testowanie, instalacja usług Kontynuacja strategii Top-Down, redefinicja i modyfikacja istniejących usług Zalety: łączy zalety Top-Down i Bottom-Up ciągła, periodyczna analiza, a mimo to dostarczane są nowe usługi Wady: wielokrotne modyfikacje tych samych usług
Strategia Agile: Shared Service Lifecycle (BEA) 81
Analiza systemowa zorientowana na usługi
Cele analizy systemowej 83 Główne cele analizy systemowej: jakie usługi powinny zostać zaimplementowane? jakie funkcje powinna udostępniać każda z usług? Pozostałe cele analizy systemowej: zdefiniowanie zbioru operacji-kandydatów do implementacji grupowanie operacji-kandydatów w konteksty; konteksty te staną się usługami-kandydatami wstępne określenie wyraźnych granic implementacji usług, aby nie kolidować z innymi już istniejącymi lub planowanymi usługami rozpoznanie fragmentów logiki biznesowej o dużym potencjale do współdzielenia zdefiniowanie wstępnych modeli kompozycji usług
Zakres analizy systemowej 84 Przeprowadzenie analizy wymagań Identyfikacja istniejących implementacji funkcji i procesów biznesowych Modelowanie usług-kandydatów task-centric skupiają się na realizacji pojedynczych zadań lub procesów biznesowych, np. weryfikacja faktury, wykonanie przelewu entity-centric skupiają się na kompleksowej obsłudze podmiotów działalności przedsiębiorstwa, np. obsługa płatności, obsługa zamówień
Kroki modelowania usług (1/2) 85 Dekompozycja procesów biznesowych na drobnoziarniste kroki Identyfikacja operacji-kandydatów dla usług biznesowych odrzucenie kroków manualnych odrzucenie kroków, które nie powinny być implementowane ze względów organizacyjnych Identyfikacja logiki aranżacyjnej (orchestration logic, workflow logic) Grupowanie operacji-kandydatów w grupy tematyczne, które staną się usługami-kandydatami Uszczegółowienie modelu i zastosowanie wzorców projektowych do usług-kandydatów współdzielenie, autonomia, bezstanowość, "odkrywalność" (reusability, autonomy, statelessness, discoverability)
Kroki modelowania usług (2/2) 86 Identyfikacja metod kompozycji usług-kandydatów potwierdza słuszność grupowania operacji-kandydatów pozwala wykryć brakujące operacje/usługi pokazuje zależności pomiędzy usługami biznesowymi a procesowymi Analiza wymagań aplikacyjnych jaka logika aplikacyjna powinna kryć się za operacjami-kandydatami usług-kandydatów? czy ta logika już istnieje, czy musi zostać zaimplementowana? Identyfikacja operacji-kandydatów dla usług aplikacyjnych Grupowanie operacji-kandydatów dla usług aplikacyjnych w grupy tematyczne, które staną się aplikacyjnymi usługamikandydatami Powrót do "Uszczegółowienie modelu"
Własności usług (powtórzenie) 87 Usługi powinny być współdzielone (reusable) Usługi powinny opierać się na formalnym kontrakcie opisującym ich mechanizmy komunikacji Usługi powinny być słabo sprzężone z innymi usługami Usługi powinny ukrywać szczegóły wewnętrznej implementacji Usługi powinny być komponowalne do postaci usług bardziej złożonych Usługi powinny być autonomiczne Usługi powinny być bezstanowe Usługi powinny być skatalogowane
Pozostałe zalecenia projektowe 88 Interakcja z usługą odbywa się tylko za pośrednictwem publicznego interfejsu Użycie usługi powinno być łatwe Należy unikać interfejsów RPC na rzecz wymiany dokumentów Interfejs publiczny powinien być skromny Szczegóły implementacyjne nie powinny być widoczne poprzez publiczny interfejs Usługi powinny być niezależnie instalowalne, wersjonowane, administrowalne (autonomiczne) Interfejs publiczny nie powinien być zmieniany
UML interaction diagrams/sequence diagrams 89 Często wykorzystywane do ilustracji przebiegu procesów biznesowych w architekturze SOA Przedstawiają wymianę komunikatów pomiędzy klientami a usługami Dostępne w środowisku JDeveloper
UML 2.0 Profile for Software Services 90 Rozwinięcie notacji języka UML w celu umożliwienia reprezentacji składników architektury SOA Dostępne w środowisku IBM Rational Software Architect message message attachment service service channel service collaboration (BPEL) service consumer service gateway service partition service provider service specification
SOA Governance 91 Wg Gartnera, najważniejszym powodem klęski projektów SOA w roku 2006 był brak odpowiednich mechanizmów nadzoru nad przedsięwzięciem Konieczne jest opracowanie ogólnofirmowych zasad tworzenia, monitorowania, adaptacji, propagowania informacji, kontroli jakości, itp. dla składników architektury SOA - SOA Governance "SOA has too many moving parts" Najważniejsze zagadnienia: zgodność ze standardami i regulacjami prawnymi zarządzanie zmianami zapewnianie jakości
Web Services Interoperability (WS-I) 92 Zbiór zaleceń opracowanych przez Web Services Interoperability Organization Maksymalizacja kompatybilności pomiędzy różnymi platformami sprzętowymi, systemowymi i programowymi Do badania zgodności usług Web Services z zaleceniami WS-I służą zautomatyzowane narzędzia - WS-I Testing Tools, posługujące się dyrektywami zapisanymi w plikach Test Assertion Document Narzędzia badania zgodności są udostępniane przez www.ws-i.org Możliwa integracja z Oracle JDeveloper
Weryfikacja WS-I w Oracle JDeveloper 93
Przegląd produktów Oracle wspomagających konstrukcję środowisk SOA
Oracle Enterprise Service Bus
Własności Oracle Enterprise Service Bus (ESB) 96 Część instalacji produktu Oracle SOA Suite Gotowa, konfigurowalna magistrala komunikacyjna obsługująca komunikację z usługami Konfiguracja ESB odbywa się z poziomu JDevelopera lub narzędzia ESB Control Umożliwia wirtualizację adresów usług (klient nie posługuje się fizycznym adresem usługi) Umożliwia komunikację z usługami niestandardowymi za pomocą adapterów (Database Adapter, File Adapter, FTP Adapter, JMS Adapter, Oracle Applications Adapter, AQ Adapter, MQ Adapter) Umożliwia dynamiczny routing wywołań usług Umożliwia automatyczną transformację komunikatów (XSLT)
Architektura Oracle ESB 97 interfejs (WSDL) Usługa WebService Klient Usługa WebService Usługa WebService... Klient Usługa PL/SQL Usługa FTP ESB...
Tworzenie projektu i systemu ESB 98
Definiowanie usług ESB 99 Wywołanie tej usługi ESB powoduje wywołanie oryginalnej, zdalnej usługi Web Service
Instalacja nowej konfiguracji na ESB 100
Podgląd aktualnej konfiguracji ESB za pomocą ESB Control 101
Podgląd aktualnej konfiguracji ESB za pomocą ESB Control 102 Nowy punkt dostępowy dla usługi
103 Definiowanie routingu wywołań i transformacji komunikatów
Definiowanie reguł routingu 104
105 Definiowanie reguł transformacji komunikatów
Oracle Web Services Manager
107 Własności Oracle Web Services Manager (WSM) Platforma bezpiecznej komunikacji sieciowej pomiędzy klientami a usługami Web Services Pozwala na bezinwazyjne szyfrowanie/deszyfrowanie, uwierzytelnianie, kontrolę dostępu, monitorowanie/rejestrację ruchu Opiera się na koncepcji agentów i gateway'ów instalowanych na drodze komunikacyjnej Konfiguracja i administracja za pomocą narzędzia Web Services Manager Control
108 Własności Oracle Web Services Manager (WSM) deszyfrowanie uwierzytelnianie autoryzacja szyfrowanie dane do uwierzytelniania agent WSM usługa klient agent WSM sieć usługa gateway WSM deszyfrowanie uwierzytelnianie autoryzacja usługa
Rejestrowanie agentów i gateway'ów 109
Definiowanie operacji realizowanych przez agentów lub gateway 110 Każdy agent lub gateway wykonuje sekwencje operacji zdefiniowanych przez administratora: pre-request: przed wysłaniem/otrzymaniem żądania request: przed wysłaniem/otrzymaniem żądania, po pre-request response: przed odebraniem/wysłaniem odpowiedzi post-response: przed odebraniem/wysłaniem odpowiedzi, po response Sekwencje operacji nazywane są "pipelines" Dostępne operacje
Definiowanie operacji realizowanych przez agentów lub gateway 111
Oracle Service Registry
Zastosowania Oracle Service Registry 113 Centralny katalog gromadzący i udostępniający informacje o istniejących usługach i ich charakterystyce Zarządzany za pomocą narzędzia Business Service Control
Rejestrowanie usługi (1/3) 114 Definicja grupy usług (provider)
Rejestrowanie usługi (2/3) 115
Rejestrowanie usługi (3/3) 116