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

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

Wprowadzenie

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)”

SOA nie jest… technologią produktem protokołem standardem

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

SOA z lotu ptaka Monolit SOA

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

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

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

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

Integracja: Usługi vs. Warstwy

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

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

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

Komunikaty (Messages) i typy danych

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

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

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

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

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!

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

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

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

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.

Reprezentacja danych

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

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.

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”

Źródła MSDN SOA Resources MSDN Architecture Centre 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

Wardziak Tomasz Dziękuję za uwagę!