Modelowanie, projektowanie i implementacja usług Web Services. Maciej Zakrzewicz

Transkrypt

1 Modelowanie, projektowanie i implementacja usług Web Services Maciej Zakrzewicz

2 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

3 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, Elements of Service-Oriented Analysis and Design, Understanding the Service Lifecycle within a SOA: Design Time, Principles of Service Design: Service Patterns and Anti-Patterns,

4 Wprowadzenie do architektury SOA

5 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

6 Założenia architektury SOA 6 konsument usług dostawca usług aplikacje usługi konsument usług internet dostawca usług

7 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

8 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

9 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

10 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

11 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

12 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

13 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

14 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

15 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

16 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ę

17 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

18 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

19 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

20 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

21 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

22 Wprowadzenie do usług Web Services

23 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

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

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

26 Protokół SOAP 26 <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:body xmlns:m="demo"> <m:multiply> <m:val2>2</m:val2> <?xml version="1.0"?> </m:multiply> <soap:envelope xmlns:soap=" </soap:body> soap:encodingstyle=" </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)

27 Pojęcia formalne: usługa Web Service 27 Usługi Web Services służą udostępnianiu zasobów za pośrednictwem komunikatów XML

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

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

30 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

31 Struktura dokumentu WSDL 31 <definitions name="..." targetnamespace="..." xmlns=" <!-- definicje abstrakcyjne --> <types>... <message>... <porttype>... <!-- definicje konkretne --> <binding>... <service>... </definitions>

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

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

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

35 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

36 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

37 Wprowadzenie do XML Schema

38 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

39 XML Schema - przykład 39 <?xml version="1.0" encoding="windows-1250"?> <xsd:schema xmlns:xsd=" xmlns=" targetnamespace=" 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

40 Konstrukcja definicji XML Schema za pomocą JDevelopera 40

41 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

42 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

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

44 Element <simpletype> (list) 44 Element " ist" zawiera wartośc typu " ist_type", która reprezentuje listę wartości typu string, oddzielanych spacjami < ist> </ ist>

45 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

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

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

48 Typy anonimowe 48 =

49 Definiowanie atrybutów 49 Element (znacznik) "zamowienie" może posiadać atrybut "kod" o wartości tekstowej

50 Projektowanie i implementacja usług w środowisku Oracle JDeveloper Rozpoczęcie od kontraktu WSDL

51 Przebieg projektowania i implementacji 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

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

53 Opisz formaty XML w języku XML Schema 53 <?xml version="1.0" encoding="windows-1250"?> <xsd:schema xmlns:xsd=" xmlns=" targetnamespace=" 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>

54 Opis interfejsu w języku WSDL 54

55 Dołączanie definicji XML Schema 55

56 Ręczne poprawki 56

57 Definiowanie typów komunikatów 57

58 Definiowanie interfejsu 58

59 Definiowanie wiązań 59 poprawić błąd:

60 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

61 Definiowanie usługi 61

62 Wygeneruj szkieletowy kod Java w oparciu o dokument WSDL 62 W oddzielnym projekcie!

63 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; }}

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

65 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; }}

66 Wygenerowane pliki <java-xml-type-mapping> <java-type>pl.maciej.zamowienie</java-type> <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

67 Implementacja kodu Java dla usługi 67 Klasy wygenerowane automatycznie. Odwzorowują struktury komunikatów XML.

68 Testowanie usługi 68

69 Projektowanie i implementacja usług w środowisku Oracle JDeveloper Rozpoczęcie od projektu klasy usługi (JDeveloper )

70 Utworzenie diagramu klas 70

71 Generowanie usługi WebService 71

72 Projektowanie i implementacja usług w środowisku Oracle JDeveloper Rozpoczęcie od implementacji klasy usługi

73 Implementacja usługi Web Services Utwórz klasę Java zawierającą metody logiki biznesowej 2. Skorzystaj z kreatora J2EE Web Service

74 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

75 Strategie konstrukcji środowisk SOA

76 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

77 Strategie realizacji SOA 77 Top-Down rozpoczęcie od kontraktu WSDL Bottom-Up rozpoczęcie od implementacji klasy usługi Agile mieszana

78 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

79 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

80 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

81 Strategia Agile: Shared Service Lifecycle (BEA) 81

82 Analiza systemowa zorientowana na usługi

83 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

84 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ń

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

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

87 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

88 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

89 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

90 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

91 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

92 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 Możliwa integracja z Oracle JDeveloper

93 Weryfikacja WS-I w Oracle JDeveloper 93

94 Przegląd produktów Oracle wspomagających konstrukcję środowisk SOA

95 Oracle Enterprise Service Bus

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

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

98 Tworzenie projektu i systemu ESB 98

99 Definiowanie usług ESB 99 Wywołanie tej usługi ESB powoduje wywołanie oryginalnej, zdalnej usługi Web Service

100 Instalacja nowej konfiguracji na ESB 100

101 Podgląd aktualnej konfiguracji ESB za pomocą ESB Control 101

102 Podgląd aktualnej konfiguracji ESB za pomocą ESB Control 102 Nowy punkt dostępowy dla usługi

103 103 Definiowanie routingu wywołań i transformacji komunikatów

104 Definiowanie reguł routingu 104

105 105 Definiowanie reguł transformacji komunikatów

106 Oracle Web Services Manager

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

109 Rejestrowanie agentów i gateway'ów 109

110 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

111 Definiowanie operacji realizowanych przez agentów lub gateway 111

112 Oracle Service Registry

113 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

114 Rejestrowanie usługi (1/3) 114 Definicja grupy usług (provider)

115 Rejestrowanie usługi (2/3) 115

116 Rejestrowanie usługi (3/3) 116