Service Oriented Architectures Rafal Lukawiecki, Project Botticelli rafal@projectbotticelli.co.uk www.projectbotticelli.co.uk 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!

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-41352 Korschenbroich http://www.newtelligence.com info@newtelligence.com 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

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

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

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

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

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

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!

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

Wprowadzenie do Service-Oriented Architectures (SOA)

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

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

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

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

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)

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 "http://gdzieśtam/"

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

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, …

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

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

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

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

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

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

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

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

Jak? Przechodzenie na service-oriented architecture

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

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!

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!

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 ?

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

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