Wprowadzenie do S OA (Service Oriented Architecture)

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

2. 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. 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. Policy Filary SOA : PEACE • Policy-based compatibility • Explicitness of boundaries • Autonomy • Contract Exchange Clemens VastersCTO, newtelligence AG Don BoxArchitect, Microsoft Corp. Service 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. Komponentyi 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. Usługa-A Usługa-B 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

18. Usługa Usługa Usługa Usługa Usługa Usługa Usługa Usługa Usługa MSG MSG MSG MSG MSG MSG MSG MSG Zarys komunikacji Ziemia niczyja!

19. Dane MSG MSG SQL Na zewnątrz Wewnątrz 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

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

21. Usługa-A Raz wysłane dane pozostają niezmienne! 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

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

23. Ref Vers#24of EmployeeData Vers#24 UpdateEmployees Reference Data • Reference Datapublikowane 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 Authoritative CustomerData Authoritative EmployeeData – Vers#24 Authoritative EmployeeData – Vers#23 Ref Vers#23of EmployeeData Update! Ref Vers#24of EmployeeData

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. Data SQL XML, SQL, i Obiekty • XML • Uschematyzowana reprezentacja komunikatów • „Schema” wspieradowolność 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

28. SQL Niezastąpiony do wykonywania dowolnych zapytań na zbiorzedanych 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. Dowolne zapytania Niezależna definicja danych Enkapsulacja Silne i słabestrony SQL Dosknonale! Niewykonalne: Centralizacja Nie poprzez SQL; Zapewnia DBMS XML Problem: Niespójność „schema” Doskonale! Niewykonalne:Otwarty„schema” Obiekty Niewykonalne: Nie widać danych! Niewykonalne: Nie widać danych! Doskonale! Rządzący Triumwirat 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? • 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 • http://msdn.microsoft.com/architecture/soa • MSDN Architecture Centre • http://msdn.microsoft.com/architecture • The ServerSide for .NET • http://www.serverside.net • Blog Clemens’a Vasters’a • http://staff.newtelligence.net/clemensv/ • Blog Don’a Box’a • http://www.gotdotnet.com/team/dbox

31. Dziękuję za uwagę!