Wprowadzenie do SOA (Service Oriented Architecture)

Prezentacja na temat: "Wprowadzenie do SOA (Service Oriented Architecture)"— Zapis prezentacji:

1 Wprowadzenie do SOA (Service Oriented Architecture)
Wardziak Tomasz Wprowadzenie do SOA (Service Oriented Architecture) Tomasz Wardziak Seminarium magisterskie, 18 października 2004

2 Agenda Wprowadzenie Integracja: Usługi vs. Warstwy
Wardziak Tomasz Agenda Wprowadzenie Integracja: Usługi vs. Warstwy Komunikaty (Messages) i typy danych Reprezentacja danych Podsumowanie

3 Wprowadzenie

4 Dlaczego warto poznać SOA?
“By 2008, SOA will be a prevailing software engineering practice, ending the 40-year domination of monolithic software architecture (0.7 probability)”

5 SOA nie jest… technologią produktem protokołem standardem

6 SOA jest… Zestawem: przepisów dopuszczalnych praktyk frameworków
wzorców architektonicznych

7 SOA z lotu ptaka Monolit SOA

8 Wardziak Tomasz Czym jest “Usługa”? Słownik PWN: “[…] działalność służąca do zaspokajania potrzeb […]”. Dostawca usług (SP) wykonuje zadania na rzecz odbiorcy/konsumenta (C). Usługa jest zdefiniowana jako kontrakt pomiędzy dostawcą (SP) a odbiorcą/konsumentem (C).

9 SOA w zarysie Usługa posiada jasno określony interfejs
Dostawca usługi (SP) oraz konsument (C) zgadzają się co do formy interfejsu Tak naprawdę chodzi o „małe powiązania” (ang. low coupling) Konsument (C) nie wie nic o implementacji Dostawca usługi Konsument Interfejs

10 Filary SOA : PEACE Policy-based compatibility
Explicitness of boundaries Autonomy Contract Exchange Clemens Vasters CTO, newtelligence AG Don Box Architect, Microsoft Corp. Service Policy Schema and Contract

11 SOA i Web Services SOA nie potrzebuje Web Services
Nie każdy Web Service będzie budowany z myślą o SOA Ale… Web Services SOA Through 2008, SOA and Web services will be implemented together in more than 75 percent of new SOA or Web services projects (0.7 probability).

12 Integracja: Usługi vs. Warstwy

13 N-Tier Podział na warstwy wymuszony przez:
Kwestie projektowe (logical design) Skalowalność (scalability) Integracja takich rozwiązań musi być kontrolowana poprzez „ciało zarządcze” Problem jasnych granic Integracja bardzo zależna od wybranego środowiska programistycznego

14 Usługi Całkowicie autonomiczne Ważny jest contract oraz schema
Niezależne od środowiska Pełna enkapsulacja danych oraz logiki biznesowej wewnątrz usługi Przyszła wersja Windows (Longhorn) zawiera warstwę Indigo do łączenia różnych rozwiązań właśnie poprzez SOA Service Schema and Contract

15 Usługi vs. Komponenty i Obiekty
Podobieństwa Podobnie jak komponenty i obiekty, usługi udostępniają jeden lub więcej interfejs Dostawca i konsument zgodzili się na wspólny interfejs Różnica SOA bazuje na „schema”, nie na typach obiektów SOA wysyła komunikaty, nie wywołuje metod Relacja Usługi są budowane z użyciem komponentów i obiektów

16 Komunikaty (Messages) i typy danych

17 Sposób komunikacji usług
Wardziak Tomasz Sposób komunikacji usług Usługi komunikują się poprzez komunikaty Nic więcej! Usługi nie wiedzą o sobie nic poza tym… … czyli mogą być heterogeniczne Usługa-A Usługa-B

18 Zarys komunikacji Ziemia niczyja! MSG MSG MSG MSG MSG MSG MSG MSG
Wardziak Tomasz Zarys komunikacji Usługa MSG MSG MSG MSG MSG Ziemia niczyja! MSG MSG MSG

19 Dane wewnątrz usług i na zewnątrz
Wardziak Tomasz Dane wewnątrz usług i na zewnątrz Na zewnątrz Przekazywane jako komunikaty Rozumiane jednakowo przez nadawcę i odbiorcę Dowolny kształt wiadomości (schema) Możliwość rozszerzania Wewnątrz Prywatne dla usługi Enkapsulacja w kodzie usługi Dane SQL MSG Na zewnątrz Wewnątrz

20 Typy danych: Request/Response Data Reference Data Activity Data
Resource Data

21 Request/Response Data #1
Komunikaty muszą być niezmienne! Nie można „cofnąć” wysłanego komunikatu Czasami trzeba ponownie nadać wiadomość Możliwość wielokrotnego otrzymania tego samego komunikatu Usługa-A Raz wysłane dane pozostają niezmienne!

22 Request/Response Data #2
Identyfikacja komunikatu Unikalny klucz ID Częścią klucza może być wersja Niezmienne dane Dane przypisane do danego klucza ID nie mogą być zmienione! Łatwe cache’owanie Niezmienne dane zawsze pozostaną w tej samej postaci „Stabline” komunikaty Każda ze stron rozumie wysłane dane w ten sam sposób

23 Reference Data Reference Data publikowane są poza granicę usługi
Jedna usługa publikuje dane Druga usługa okresowo je odbiera Cel „reference data” Fakty historyczne Niezbędne jest wersjonowanie! timestamp unikalny numer wersji HR Service Sales Service Ref Vers#24 of Employee Data Authoritative Customer Data Authoritative Employee Data – Vers#23 Authoritative Employee Data – Vers#24 Ref Vers#23 of Employee Data Update! Ref Vers#24 of Employee Data Update Employees Vers#24

24 Activity Data Są umieszczone WEWNĄTRZ usługi
Potrzebne do koordynacji długich zadań wymagających wielokrotnej komunikacji Przykład: koszyk w sklepie internetowym Activity Data pozostają w systemie jako aktywne, tak długo jak dana transakcja jest realizowana Po zakończeniu transakcji z reguły nie są kasowane, ale dla celów statystycznych/urzędowych zostają zarchiwizowane

25 Resource Data Są umieszczone WEWNĄTRZ usługi
Dane opisujące „zasoby” istniejące w obszarze logiki biznesowej Są potrzebne i istnieją tak długo, jak długo dany zasób istnieje w dziedzinie problemowej – późnej są kasowane Przykłady: Pokoje do wynajęcia – system obsługi hotelu Towary w magazynie – system inwentaryzacji Pracownicy – system HR Klienci – system CRM Etc.

26 Reprezentacja danych

27 XML, SQL, i Obiekty Data XML SQL Obiekty SQL
Wardziak Tomasz XML, SQL, i Obiekty XML Uschematyzowana reprezentacja komunikatów „Schema” wspiera dowolność definicji i rozszerzalność SQL Dane są połączone relacjami Bardzo zaawansowane możliwości zapytań Dojrzałe systemy DBMS Obiekty Bardzo potężne narzędzie Inżynierii Oprogramowania Bazują na enkapsulacji Data SQL

28 Niezależna definicja danych
Wardziak Tomasz Rządzący Triumwirat SQL Niezastąpiony do wykonywania dowolnych zapytań na zbiorze danych XML Posiada możliwość niezależnej definicji „schema” dla danych. Każdy może rozszerzać „schema” o nowe elementy! Komponenty/ Obiekty Dostarczają enkapsulację danych. Zespolone z logiką biznesową. Zapewniają wypełnienie zasad biznesowych. Obiekty XML SQL Silne i słabe strony Niewykonalne: Nie widać danych! Problem: Niespójność „schema” Dosknonale! Dowolne zapytania Niewykonalne: Nie widać danych! Doskonale! Centralizacja Niezależna definicja danych Doskonale! Niewykonalne: Otwarty „schema” Nie poprzez SQL; Zapewnia DBMS Enkapsulacja Silne strony każdego modelu są zarazem jego słabościami! SQL, XML oraz Obiekty stanowią współgrający zespól.

29 Podsumowanie Dlaczego warto zająć się SOA? Dlaczego jeszcze nie teraz…
Prawdopodobna przyszłość oprogramowania (wsparcie gigantów) Najlepsze na chwilę obecną podejście do integracji Idealnie pasuje do modelowania procesów biznesowych Łatwość wprowadzania zmian – istotne dla biznesu! Low coupling – coarse grained Nowe ideologie – np. Metropolis Dlaczego jeszcze nie teraz… Brak standardów komunikacji pomiędzy przedsiębiorstwami Główna technologia, na której SOA bazuje (WS) ciągle jest niedoskonała. Brak dobrych narzędzi programistycznych. Niedojrzałe „best practices”

30 Źródła MSDN SOA Resources MSDN Architecture Centre
MSDN Architecture Centre The ServerSide for .NET Blog Clemens’a Vasters’a Blog Don’a Box’a

31 Wardziak Tomasz Dziękuję za uwagę!