Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

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

Podobne prezentacje


Prezentacja na temat: "Wprowadzenie do SOA (Service Oriented Architecture) Tomasz Wardziak Seminarium magisterskie, 18 października 2004."— Zapis prezentacji:

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ą produktemprotokołemstandardem

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

7 SOA z lotu ptaka SOA Monolit

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 Filary SOA : PEACE Policy-based compatibility Explicitness of boundaries Autonomy Contract Exchange Clemens Vasters CTO, newtelligence AG Don Box Architect, Microsoft Corp. Service PolicyPolicy Schema and Contract Schema and Contract

11 SOA i Web Services 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). SOA nie potrzebuje Web Services Nie każdy Web Service będzie budowany z myślą o SOA Ale… Web Services SOA

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 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 Usługi komunikują się poprzez komunikaty Nic więcej! Usługi nie wiedzą o sobie nic poza tym… … czyli mogą być heterogeniczne Usługa-AUsługa-B

18 Zarys komunikacji MSG Ziemia niczyja! Usługa

19 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 cacheowanie 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 Ref Vers#23 of Employee Data Update! Ref Vers#24 of Employee Data Authoritative Employee Data – Vers#23 Authoritative Employee Data – Vers#24 Sales Service Authoritative Customer Data HR Service 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 XML Uschematyzowana reprezentacja komunikatów Schema wspiera dowolność definicji i rozszerzalność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 Rządzący Triumwirat Niewykonalne: Nie widać danych! Problem: Niespójność schema Dosknonale! Dowolne zapytania Niewykonalne: Nie widać danych! Doskonale! Niewykonalne: Centralizacja Niezależna definicja danych Doskonale! Niewykonalne: Otwarty schema Nie poprzez SQL; Zapewnia DBMS Enkapsulacja 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 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 MSDN Architecture Centre The ServerSide for.NET Blog Clemensa Vastersa Blog Dona Boxa

31 Dziękuję za uwagę!


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

Podobne prezentacje


Reklamy Google