Service Oriented Architectures

Prezentacja na temat: "Service Oriented Architectures"— Zapis prezentacji:

1 Service Oriented Architectures
Rafal Lukawiecki, Project Botticelli This presentation was created by Clemens Vasters of newtelligence GmbH. It is copyright by Newtelligence GmbH and by Microsoft and has been translated and presented with their permission. Thank you, Clemens!

2 Informacja o Copyright, czyli o Prawach Autorskich
3/26/2017 Informacja o Copyright, czyli o Prawach Autorskich © 2003 newtelligence Aktiengesellschaft newtelligence AG Gilleshütte 99 D Korschenbroich The presentation content is provided for your personal information only. Any commercial or non-commercial use of the presentation in full or of any text or graphics requires a license from newtelligence AG. This presentation is protected by the German Copyright Act, EU copyright regulations and international treaties. Newtelligence permited Project Botticelli Ltd to deliver this presentation. Full Copyright is also held by Microsoft Corp © 2003, with whose additional explicit permission this presentation is delivered by Project Botticelli Ltd

3 Cele Pokazać niedaleką przyszłość paradygmatów programowania i projektowania architektur informatycznych Dać kilka rad jak przygotować się na ten kierunek zmian

4 Plan sesji Kilka rzeczy dobrych, kilka złych Wprowadzenie do SOA
Enterprise Service Bus Jak? Podsumowanie

5 Kilka rzeczy dobrych, kilka złych Podejścia do programowania - Paradygmaty

6 Architektury Strukturalne
Dobre podejście Obietnica: organizacja i powtórne użycie kodu Procedury, funkcje i dane Informatyka wyszła z ery lodowcowej W swoim czasie osiągnięto wiele: Monolityczne, odizolowane aplikacje serwerowe Asynchroniczne serwisy przetwarzania wsadowego (batch) Synchroniczne serwisy terminalowe

7 Obiektowe-zorientowanie (OO)
Bardzo dobre Obietnica: organizacja i powtórne wykorzystanie kodu Klasy (dane i fukcje razem ze sobą) Zwiększenie produktywności developerów W swoim czasie osiągnięto wiele: Monolityczne aplikacje klient-serwer Bogate, interakcyjne interfejsy graficzne (GUI) Stan-zachowujące (stateful) serwery o dużej wydajności lecz niskiej skalowalności

8 Zorientowanie na komponenty
Bardzo, bardzo dobry pomysł Obietnica: organizacja i powtórne wykorzystanie kodu Komponenty (grupowanie interfejsów) Niezależność od implementacji Współpraca między-aplikacyjna stała się rzeczywistością Super! Wielo-poziomowe, wielo-warstwowe aplikacje Duże osiągi wydajności i wysoka skalowalność OLE!

9 SP, OOP, COP Programowanie Strukturalne, Programowanie OO, Programowanie Komponentowe
Złe pomysły... Paradygmaty „programowania” One opisywały jak programować, a nie jak projektować architektury Architektura była wymuszana przez styl programowania Abstrakcja koncepcji lecz konkretne nie-elastyczne rzutowanie w języki Reprezentacje w Pascalu, C++, CORBA, COM Wtórne wykorzystanie kodu ograniczone wewnątrz domenu Wtórne wykorzystywanie między domenami bardzo bolesne w planowaniu i realizacji Kłopot przekraczania granic domen abstrakcji Zbędne wymuszanie rozwiązań synchronicznych

10 Wprowadzenie do Service-Oriented Architectures (SOA)

11 Czego dziś potrzebujemy?
Mało jest już projektów aplikacji typu „zielone działka” („od zera”), większość to „brązowa działka” Nowe rozwiązania z reguły wykorzystują istniejące Istniejące systemy potrzebują nowych Systemy heterogeniczne Upgrade-y i ulepszenia nie są synchronizowane Brak jednej rodziny systemów operacyjnych i architektur sprzętowych Efekt „Big Bang” Wszystko umyka coraz to dalej od wszystkiego Wszystko chce dostępu i prawa manipulacji każdą bazą danych...

12 Czego ponadto chcielibyśmy?
Organizacji i powtórnego wykorzystanie kodu... Wzdłóż warstw i aplikacji Wszerz organizacji biznesowych i granic zaufania Niezależności od implementacji Współpraca oparta o standardy Niezależność od języka programowania i platformy Dynamicznego grupowania Koncentracja lub rozproszenie klasterowe zależnie od potrzeb

13 Czego nie chcemy Obsługiwać zdolności (tranzakcje, bezpieczeństwo itd.) Topić się w logice wyszukiwania, wywoływania i niezawodnej obsługi serwisów Tracić czas na pisanie nowych schematów pracy (workflow) dla serwisów infrastrukturalnych

14 Zorientowanie na serwisy (Service-Orientation)
Czym jest „Serwis”? Jakaś dostępna funkcjonalność Lokalizacja, platforma i styl kodowania nie mają znaczenia Wnioski Zakładaj: zawsze zdalny (remote) dostęp Zakładaj: zawsze oczekuj dostępu z przeróżnych platform Zignoruj wewnętrzną implementację serwisu

15 Unikaj tych założeń Nie myśl o serwisie jako o: Bo serwisy mogą być:
Transakcji, obiekcie czy funkcji Synchronicznym czy asynchronicznym Zachowującym-stan czy bezstanowym Adresie, który wywołujesz Bo serwisy mogą być: Odbiorcami wiadomości (aplikacje) Obsługą i przetwarzaniem wiadomości (infrastruktura) Nośnikami wiadomości (transport)

16 Terminologia Wiadomość (message) Contekst (context)
Dane wymieniane między serwisami Nie obiekty! Kod podróżuje źle. Contekst (context) Definiuje zakres (scope) działania i konwersjacji Dla stanu i infrastrukturalnych ustawień Odbiorcy (destinations) Docelowy serwis lub klasa serwisów Nie "

17 Więc, czym są serwisy? Naprawdę są tylko dwa typy serwisów
3/26/2017 Więc, czym są serwisy? Naprawdę są tylko dwa typy serwisów Producenci wiadomości Działaj i dodawaj do wiadomości Konsumenci wiadomości Zjadaj kawałki wiadomości i reaguj na nie Wiadomości płyną przez rurociągi Rurociąg (pipeline) jest szeregiem serwisów Czyli szeregi producentów i konsumentów Wiadomości rosną i kurczą się przepływając

18 Przykłady serwisów Infrastruktury podstawowe
Transport, autentykacja, autoryzacja, tranzakcyjność, itd. Monitoring i wsparcie operacyjne Statystyka i śledzenie wydajności, serwisy konfiguracyjne, zdobywanie-i-instalacja (provisioning) Serwisy biznesowe Integracja procesu obsługi zamówień, logistyka, śledzenie, przenośne zbieranie danych w fabryce, …

19 Współpraca niezależnie od wybranej technologii
SOAP i XML jak na razie jedyną praktyczną naszą nadzieją COM, CORBA, RMI zakładają wiedzę o konkretnej platformie Cokolwiek ustalone na poziomie binarnym zakłada wybór platformy Dowolny transport zakłada platformę... W tej chwili koncentrujemy się na XML InfoSet

20 Authen- tication, Authz.
Serwisy w rurociągu C Runtime A Runtime B C XML XML XML XML XML XML XML XML XML A B Tx Sec UDDI ERP Sec Tx Proxy Trans-action prop. Security context prop. Digital Signing Rou-ting Signat. verifi-cation Authen- tication, Authz. Tx Enlist-ment Dis-patch

21 Services Bus – Magistrala Serwisowa
3/26/2017 Services Bus – Magistrala Serwisowa Komponenty Oś Domen Prezentacja – Interfejs Zewnętrzny Workflow Orchestration i Business Logic Customer Data UI Orders Data UI Shipping Data UI Poziomy Funkcjonalne Message Dispatch Service Bus (Broker) Serwisy Message "Servicing" Customer Data Logic Orders Data Logic Shipping Data Logic Service Discovery The most interesting aspect of service-oriented architectures is that they are "self-similar". A complete application with a full-featured, internal SOA infrastructure looks like "just another service" to another application. This picture/animation illustrates how a "classic" multi-layer application compares to and can indeed be "morphed" into a service-oriented architecture. The most important takeaway is, that SOA systems do not necessarily differ in their internal implementation. Much of the code in an SOA environment looks exactly as it does in a current "n-tier" implementation approach. The "new" in SOA is that the communication between all components is strictly standards-based (which mandates XML), free of assumptions about infrastructure behaviors (which mandates that services may only act on messages) and that endpoint-selection is dynamic by default. The "service bus" which is shown here, is, by itself, nothing but an aggregate of services. Customer Service My Company Orders Service My Company Shipping Service FedEx/UPS Customer Service J2EE Customer Data Data Access Orders Service .NET Orders Data Data Access Shipping Service CICS Shipping Data Data Access Customer Service London Orders Service Paris Shipping Service Düsseldorf Customer Service (Provider) Orders Service (Provider) Shipping Service (Provider) Service Registry Oś Infrastruktury

22 Opublikowywanie i znajdowanie (Publishing & Discovery)
Serwisy trzeba udostępnić Jakie serwisy są dostępne? Klasy, taksonomie... Lokalizacja Separacja środowiska deweloperskiego i produkcyjnego Granice regionalne, prawa, wiarygodności lub zuafania Potrzeba znaleźć serwis Statycznie i dynamicznie

23 Zdolności (Capabilities)
Potrzeba możliwości negocjacji zdolności Bezpieczeństwo (możliwości i potrzeby) Kontekst Tranzakcyjność Niezawodność komunikacji Potrzeba znaleźć możliwości nawiązywania komunikacji

24 Rola Pośrednika Serwisów (Service Broker)
Broker może być konceptualny, nie koniecznie konkretnym systemem Może się składać z kilku serwisów Może być rozdystrybuowany Raczej będzie oparty o rurociągi Utrzymuje rejestr serwisów Do tego wymyślono UDDI Zajmuje się najlepszym „załatwieniem” takich rzeczy jak: Routing, QoS (jakość serwisu), wywoływanie, zaufanie, bezpieczeństwo, monitoring...

25 Rola Dostarczyciela Serwisów (Service Provider)
Oferuje wiele serwisów Funkcjonalności biznesowe, lub Infrastrukturalne Implementuje kontrakty dobrze-znane (well-known), czyli te, na których można zawsze polegać Wiadomości, konwersacja i komunikacja Objawia zdolności Kontekst, tranzakcyjność... Implementacja zostaje sekretem

26 Rola Konsumenta Serwisów (Service Consumer)
Łączy się z serwisami i nimi steruje Interakcja z użytkownikiem Interakcja automatycznie sterowana schematami pracy (workflow) Może być serwisem  Agregacja (Aggregation) Nie interesuje go typ implementacji Tylko go interesują kontrakty Wiadomości Żądana jakość serwisu (QoS) Pożądane zdolności

27 Jak? Przechodzenie na service-oriented architecture

28 Oczywiście: Zaimplementuj rejestr serwisów
UDDI jest dobry, LDAP też UDDI zostało na to stworzone Windows Server 2003 ma w sobie UDDI Server LDAP jest szeroko znany Implementacja w Active Directory Pomyśl o klasach serwisów Infrastruktura, biznesowe Kategorie, funkcjonalność, dopasowanie do potrzeb Lokalizacja Odkrywanie-znajdowanie (discover) Zacznij statycznie w czasie budowania systemu ale planuj na dynamiczne

29 Oczywiście: Zaimplementuj router
WSE SDK dobrym początkiem bo używa standardy WS-* WS-Security, WS-Routing Buduje na wydajności ASP.NET Ważne: Rób nie więcej niż trzeba Nie przesadź w planach Nie buduj na wieczność Proste jest dobre Weź pod uwagę architekturę store-and-forward BizTalk Server oczywiście już jest routerem, i więcej!

30 Nieoczywiste: Implementuj N-tier (n-warstw)
Fasada serwisów w ASP.NET Najlepszy wybór do serwisów w .NET WSE SDK do routing i bezpieczeństwa XSD  WSDL  Kod Odizoluj warstwy biznesu i danych Korzystaj z Enterprise Services (Windows Server 2003), także dla starszych aplikacji COM+ Korzystaj z Serviced Components Dalej używaj stored procedures dla danych Czyli, po staremu jak na razie!

31 Encapsulate (owijaj) Istniejący kod (Windows)
Owiń w fasadę w ASP.NET COM+ : Owiń i udostępnij jako serwis DLL/COM : Owiń w Serviced Comp's Istniejący kod (Unix itd.) Zawiń w fasadę Apache Axis WebSphere: używaj najnowszej WebLogic: używaj najnowszej Inne UNIXy: używaj Axis ...a może by przenieść do .NET ?

32 Siła = Wydajność Praca Czas SOA raczej wymaga XML
Droższy w wydajnośći niż dane binarne Więcej poziomów pośrednich Weź pod uwagę dwa prawa: Prawo Moore, siła procesorów podwaja się co 18 miesięcy, oraz… Siła = Praca Czas

33 Podsumowując SOA to ewolucja Wiadomość jest sednem!
Nic tu bardzo radykalnego Zespolenie doskonałych idei, które dawniej nie były ze sobą związane Wiadomość jest sednem! Myśl „wiadomość” a nie „wywołanie” XML jest lepszy niż dane binarne Asynchroniczność jest dobra