Service Oriented Architecture SOA Service Oriented Architecture AGH, Informatyka, Studia niestacjonarne, III rok, Mariusz Czarnecki
Wstęp Biznes i informatyka Zrozumienie biznesu Wsparcie biznesu Wspólny cel Wspólny sukces
Wstęp Typowe cele biznesowe Typowe problemy biznesowe Optymalizacja kosztów Elastyczność w obsłudze klienta Szybka adaptacja do zmian ekonomicznych Typowe problemy biznesowe Adaptacja istniejących rozwiązań informatycznych do zmian Integracja systemów Przepływ i wymiana informacji Wysokie koszty obsługi
Typowa architektura oprogramowania przedsiębiorstwa
Wstęp Typowe problemy informatyczne Obsługa zmian w aplikacji Hermetyczność rozwiązań Ograniczone możliwości wymiany i przepływu informacji Integracja wielu systemów Złożona infrastruktura
SOA Czym jest SOA? Odpowiedź informatyki na potrzeby biznesu w zakresie: Wykorzystania posiadanych atutów/zasobów/środków Stworzenia nowych możliwości Łatwej adaptacji i wsparcia zmian biznesowych
SOA Nadrzędny cel architektury SOA Łatwe i szybkie tworzenie i rozszerzanie systemów informatycznych precyzyjnie wspierających osiąganie celów biznesowych przez przedsiębiorstwo w zmiennych warunkach ekonomicznych
Model referencyjny
SOA Podział architektury Warstwa biznesowa Bezpośrednio wspierająca działania biznesowe poprzez interakcję z użytkownikami, systemami, urządzeniami, itd. Warstwa instalacyjna/robocza Zaplecze dla warstwy biznesowej
Skupienie na procesach i biznesie Business logic Application a Application b Application c Application logic
Skupienie na procesach i biznesie Application layer interface layer Services process layer Business Application-oriented services Business-oriented .NET J2EE Legacy
Skupienie na procesach i biznesie Application layer interface layer Services process layer Business .NET orchestration service layer business service layer application service layer
Główne punkty SOA (1) Ludzie Procesy Informacje Interakcja i współpraca Procesy Narzędzia i usługi dla zwiększenia wydajności w zarządzaniu procesami biznesowymi Informacje Dostęp do kompleksowej i różnorodnej informacji
Główne punkty SOA (2) Połączenie Ponowne użycie Połączenie ludzi, procesów i informacji w biznesie Ponowne użycie Zwiększenie wartości posiadanych już zasobów i środków inwestycyjnych
Cechy SOA Wyłącznie dla aplikacji biznesowych Architektura komponentowa czarnych skrzynek Luźno połączone komponenty Komponenty są połączone w celu uzyskania pożądanej funkcjonalności i efektywności procesu
Ponowne wykorzystanie Wiele różnych firm Wiele różnych procesów Podobieństwa na różnym poziomie procesów Komponent jako usługodawca świadczący usługi niezależnie od innych komponentów
Jakość usług Bezpieczeństwo Dokładne dopasowanie do oczekiwań Przewidywalność
Główne składniki SOA
Architektura SOA (IBM)
Enterprise Service Bus Współpraca pomiędzy usługami Wymiana komunikatów Wymagania w stosunku do obsługi komunikatów Szybkość Pewność doręczenia (lack of service)
ESB IBM
SOA Register Katalog usług Połączenie dla Środowiska operacyjnego Service broker – połączenie komponentów poprzez reguły związane z każdym z nich Środowiska programistycznego i analityków biznesowych Wybór i tworzenie aplikacji z komponentów
SOA Register Centralny punkt referencyjny dla całej architektury Metadata Definicja domeny architektury Publikacja komponentów – Web serwisów
Zarządzanie procesami Zmiany w biznesie Stały przedmiot biznesu Zmiana sposobu realizacji biznesu Sposób opisu biznesu BPM – Business Process Management BPMN – Busines Process Management Notation BPEL – Business Proces Execution Language
Enkapsulacja logiki
Współpraca pomiędzy usługami Usługa A ma dostęp do opisu usługi B Nazwa usługi Parametry oczekiwane Parametry zwracane Podobieństwo do innych rozwiązań (np. CORBA, RMI, COM, DCOM)
Szablony wiadomości Jednokierunkowa. Adresat otrzymuje wiadomość. Żądanie odpowiedzi. Adresat otrzymuje wiadomość i wysyła wiadomość - odpowiedź. Odpowiedź-prośba. Adresat wiadomości wysyła odpowiedź-pytanie i sam też otrzymuje odpowiedź. Powiadomienie. Nadawca wysyła wiadomość.
Wiadomości w SOA 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
Projektowanie usług
Zasady tworzenia usług (1) Luźne powiązanie z minimalizacją zależności ograniczoną do świadomości istnienia innych usług Umowa serwisowa w zakresie uzgodnień komunikacji z innymi usługami i zgodnie z odpowiednią dokumentacją
Zasady tworzenia usług (2) Autonomia serwisu polegająca na samodzielnej kontroli logiki w nim zawartej Abstrakcja ukrywa logikę wewnętrzną udostępniając wyłącznie to co wynika z opisu usługi Ponowne użycie poprzez podział logiki na usługi
Zasady tworzenia usług (3) Zdolność do tworzenia złożonych i skoordynowanych usług kompozytowych „Bezpaństwowość” w celu ograniczenia przechowywanych informacji do specyficznych dla działania usługi Wyszukiwalność zapewniona zewnętrznym opisem w celu umożliwienia znalezienia usługi poprzez dostępne mechanizmy wyszukiwania
Budowa serwisów 20 lat terminu „service-oriented” Web Services a SOA SOA to nie Web Services Najlepiej przystosowana obecnie technologia do wykorzystania w architekturze SOA Otwarty Standard opisujący interfejs usług (http://www.w3.org/TR/wsdl)
Narzędzia dla SOA SOAP przez HTTP (Simple Object Access Protocol) Lekki protokół dla Web Serwisów Wspierany przez Visual Studio i IIS Pracuje z wieloma protokołami komunikacyjnym, np. NNTP, ale prawie zawsze wykorzystywany jest w połączeniu z HTTP Niezależny od języka i systemu operacyjnego SW-* Rozszerzenie (opcjonalnie) Zestaw rozszerzeń dla Web Serwisów
Ogólna charakterystyka SOA Stanowi podstawę platform zorientowanych na usługi Zwiększa jakość usług Z założenia autonomiczna Oparta na otwartych standardach Wspiera różnorodność dostawców Wspiera nierozerwalnie współpracę
Ogólna charakterystyka SOA Wspiera wyszukiwanie Wspiera powiązania Wspiera architekturę kompozytową Zapewnia nierozerwalnie ponowne użycie Kładzie nacisk na rozszerzalność Wspiera założenie modelowania biznesowego poprzez uslugi
Ogólna charakterystyka SOA Implementuje poziomy abstrakcji Wspiera luźne powiązania w ramach przedsiębiorstwa Wspiera elastyczność przedsiębiorstwa Jest elementem konstrukcyjnym Jest ewolucją rozwiązań Rozwija się Jest dążeniem do idealnego rozwiązania
Inne definicje SOA Architektura Platforma Fundacja, organizacja (IBM) Nowoczesna platforma SOA reprezentuje architekturę, która promuje zorientowanie na usługi poprzez użycie Web serwisów
Podniesienie jakości usług Bezpieczeństwo realizacji zadań, ochrona zawartości komunikatów, dostęp do poszczególnych usług Gwarancja dostarczenia komunikatu lub powiadomienia o braku doręczenia Zapewnienie wydajności przetwarzania zadań niezależnie od technologii przetwarzania komunikatów (narzuty SOAP, XML) Zapewnienie transakcyjności w celu ochrony integralności działań biznesowych włącznie z generowaniem wyjątków
Autonomiczność usług Wymagania niezależności i samowystarczalności usług w ramach realizowanej logiki Wykorzystanie komunikatów do zapewnienia niezależności
Otwarte standardy w SOA Wykorzystanie otwartych standardów w Web serwisach dla celów wymiany komunikatów Ograniczenie roli technologii w implementacji i utrzymaniu logiki aplikacji zawartej w usługach
Dywersyfikacja dostawców usług Umożliwienie wyboru najlepszego z dostępnych rozwiązań niezależnie od technologii
Klient SOA Wymagania Porównanie do serwisów SOA Zakleszczenia Architektura Przepływ wiadomości Struktura rozwiązania
Wymagania klienta SOA Klient może być aktualizowany z różnych źródeł włączając użytkownika Żadna akcja nie powinna wstrzymywać innej akcji Wybór pozycji menu przez użytkownika nie oznacza, że przyjęcie komunikatu obniżającego cenę powinno zostać opóźnione Wszystko musi być logowane Jeśli coś pójdzie nie tak musimy wiedzieć jak do tego doszło Niektóre gałęzie przemysłu wymagają pozostawienia informacji z wykonania akcji dla celów audytu
Klient vs. Serwis SOA Serwisy SOA powinny być bezstanowe Klient musi zachowywać stan Serwisy nie muszą być wielowątkowe, mogą przetwarzać jedną wiadomość w czasie Klienta musi być wielowątkowy – musi odpowiadać na akcje użytkownika równocześnie obsługując wiadomości Jak zapobiegać zakleszczeniom klienta?
Zakleszczenia klienta Są możliwe trzy poziomy obsługi/zapobiegania zakleszczeniom: Architektura Projekt Kod
Zakleszczenia - kod Obsługa zakleszczeń w kodzie: Mutex Monitor ReaderWriterLock ManualResetEvent / AutoResetEvent Interlocked WaitHandle Jeśli w kodzie pojawiają się powyższe obiekty to oznacza to problemy…
Obsługa zakleszczeń klienta Obsługa zakleszczeń poprzez odpowiednie projektowanie: Używaj synchronization domains (SD) do rozdzielenia zachowania systemu w czasie pracy Wszystkie klasy klasy używane w wielu wątkach należy dziedziczyć z ContextBoundObject Umieść atrybut [Synchronization] we wszystkich tych klasach Zalety: Zapewnienie dostępu tylko jednego wątku do grupy obiektów w tym samym czasie bez zakleszczeń Wady: Zły podział/wybór SD może prowadzić do słabej wydajności negując wymagania
Obsługa zakleszczeń klienta Obsługa zakleszczeń poprzez architekturę – Micro SOA: Wymaga minimalnej ilości specyficznego kodu wielowątkowego Używa kolejek w celu separowania wątków i komunikacji Wszystkie obiekty (za wyjątkiem kolejek) są dostępne wyłącznie dla jednego obiektu Wyjątek: wątek interaktywny i wątek aktualizujący UI współdzielą obiekty Następstwa: Wszystkie wątki potrzebują ich własnych kopii danych Zapis do bazy i zapis logów powinien odbywać się z wykorzystaniem własnych wątków Wysyłanie wiadomości z dużą szybkością obciąża system – oddzielne wątki
Architektura klienta Kolejka prezentacji Kolejka logiki Kolejka komunikacji Serwis prezentacji Serwis logiki Serwis komunikacyjny Wątek prezentacji Wątek logiki Wątek komunikacji Wątek interaktywny Kolejka dostępu do danych Serwis dostępu do danych Wątek dostępu do danych Żółte linie oznaczają operacje DeQueue, czerwone operacje EnQueue, Białe to bezpośrednie wywołania. Małe kółka reprezentują obiekty w pamięci. DB Tutaj należy użyć synchronizacji domen
Klient SOA – przepływ wiadomości Data Access Messages Communications Logic Presentation
Korzyści SOA Sukces poprzez cele biznesowe Zbliżenie biznesu i informatyki Modelowanie procesów narzędziami informatycznymi Skupienie na celu biznesowym w miejsce działającej aplikacji
Typowe błędy wdrożenia SOA Brak oparcia SOA na standardach Brak planu przejścia do SOA Brak solidnego planu architektury opartej na XML’u i brak umiejętności Niezrozumienie wymagań wydajnościowych SOA Niezrozumienie zasad bezpieczeństwa Web Serwisów
Czym nie jest SOA Magiczną sztuczką Czarodziejską różdżką Receptą na wszystkie problemy przedsiębiorstwa Gotowym szablonem dla wszystkich
Teraźniejszość SOA (IBM) 7 z 10 największych banków światowych Każdy z 10 największych producentów samochodów 2/3 z 25 największych firm telekomunikacyjnych Połowa z 50 największych firm elektronicznych 6 z 10 największych światowych ubezpieczycieli 80% największych producentów medycznych USA Połowa z 10 największych światowych sieci detalicznych Ponad 2500 partnerów biznesowych SOA
Literatura SOA for Dummies – Limited edition by IBM SOA – Concepts, Technology and Design – Thomas Erl http://www-01.ibm.com/software/solutions/soa/ www.oracle.com 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 www.wikipedia.org
Pytania Czym jest SOA? Dla kogo jest SOA a dla kogo nie? Jakie są główne elementy SOA? Czym jest usługa? Jakie są korzyści z SOA?