Pobierz prezentację
Pobieranie prezentacji. Proszę czekać
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
Podobne prezentacje
© 2024 SlidePlayer.pl Inc.
All rights reserved.