Komponentowe systemy rozproszone Interludium czyli krótki wykład o rozpraszaniu
Trudne pytania proste odpowiedzi? Sens życia ? 42 Jak realizować systemy rozproszone? SOA SOA 2.0, EDA SOA
Po co rozpraszać? skalowalność ? niezawodność ?? aspekt sprzętowy geograficzny łatwość utrzymania i rozwoju ??? częściowy outage wdrazanie częsciowe rozwół niezależnych części bo mozna ????
Krotka historia rozpraszania Komunikacja pakietowa Komunikacja strumieniowa (gniazda) Komunikacja obiektowa (obiekty rozproszone, CORBA, (D)COM+), RMI Architektura Zorientowana na Serwisy SOA, SOA 2.0, EDA, ESB, SOA Drugi wymiar: Chmury, silniki wyszukiwawcze bazy dokumentowe, kolumnowe, hurtownie danych, bigdata
Obiekty rozproszone obiekty+komunikacja = system rozproszony? CORBA, COM(+), EJB Współdzielenie obiektów Na poziomie kodu lub binariów Pomiędzy podsystemami Pomiędzy gui i serwerem Problemem nie jest technologia! Problemem jest rozproszenie!
Połączeń nie można ignorować … Typowe założenia deweloperów (i archi- tektów) dla systemów rozproszonych: Sieć jest niezawodna Opóźnienia nie są problemem Pasmo nie jest problemem Sieć jest bezpieczna Topologia się nie zmienia Administrator zawsze wie co robić Koszty transportu danych nie są problemem Sieć jest jednorodna P. Deutsch 94 J.Gosling 97
Suplement Typowe założenia deweloperów (i architektów) dla systemów rozproszonych: System jest atomowy/monolityczny System jest skończony Logika biznesowa może (i powinna) być scentralizowana Neward 06
System ≠ aplikacja Aplikacja: jeden proces, jeden system op., jeden komputer System: wiele procesów (czesto) wiele komputerów (czasem) wiele systemów operacyjnych. System = N*aplikacja + połączenia
3 wymiary systemu Scalability Availiability Reliability
Atrubuty jakościowe które SOA może pomóc zapewnić Reusability Adaptability Maintainability
Kilka luźnych uwag nt. SOA SOA to jakiś czas temu jedno z najbardziej nadużywanych “buzzword” W tym sensie “SOA” przypomina “object oriented” SOA ma kilkanascie lat (obecnie mówi sie już o SOA 2.0, event driven architecture, SOA/ S) OOA i SOA to różne poziomy abstrakcji SOA, to nie technologia – to nie webserwisy, to nie WCF
Marketing SOA
Czym SOA nie jest sposobem na pogodzenie wymgań IT i wymagań biznesowych aplikacją, która ma interfejs w postaci usługi www (web serwis) zbiorem technologii (np. SOAP, REST, WS-I itd) strategią reużycia gotowym rozwiązaniem (“z pudełka”)
A - oznacza architekturę Definicja wg. IEEE: “Podstawowe koncepcje lub własności systemu ujęte w jego elementach, relacjach, zasadach projektowania i ewolucji” (IEEE 42010).
A - oznacza architekturę DEFINICJA Architektura oprogramowania to zbiór fundamentalnych decyzji nt. produktu lub rozwiązania programowego mających na celu zapewnienie pewnych atrybutów jakościowych (-> wymagania architektoniczne). Architektura obejmuje główne komponenty, ich podstawowe własności oraz wzajemne zależności (interakcje i zachowania) w kontekście wspomnianych atrybutów jakściowych. Architektura może, i zwykle powinna, być wyrażona na kilku poziomach abstrakcji, przy czym liczba tych poziomów zależy od rozmiaru i komplikacji projektu ARNON ROTEM-GAL-OZ
A - oznacza architekturę Architektura jest cechą każdego system. Architektura powinna zaistnieć wcześnie. Architektura narzuca podział na komponenty i ustala granice między nimi. Architektura określa relacje i interakcje między komponentami. Architektura objąśnia racje stojące za decyzjami. Architektura to nie pojedyncza struktura, rysunek czy nawet grupa rysunków.
SOA DEFINICJA: Service-oriented architecture (SOA) jest stylem architektonicznym pozwalającym na budowę systemów opartych na interakcjach luźno powiązanych, zgrubnych, autonomicznych komponentów nazywanych serwisami. Każdy serwis udostepnia procesy i zachowania ujete w formie kontraktów i wyrażone w formie komunikatów. Komunikaty dostępne są pod odkrywalnymi adresmi - punktami dostępowymi (endpoint). Zachowanie serwisu jest określane przez zewnętrzne (w stosunku do niego) polityki. Kontrakt i komunikaty są używane przez inne komponenty systemu nazywane konsumentami serwisu. ARNON ROTEM-GAL-OZ
Styl Architektoniczny Styl architektoniczny – zespół wytycznych na temat jakie decyzje i rozwiązania sa akceptowalne I pożądane w ramach architektur definiowanych systemów
Kilka ważnych wyrazów SOA (serwisy rozproszone): Autonomiczne usługi Jawne granice Wspoóldzielenie kontraktu a nie klas/typów Kontrakt jest dostępny poprzez komunikaty wysyłane na adres endpoint-ów przez konsumentów serwisu. Polityka pozwala określić takie atrybuty jak bezpieczeństwo, audyty, SLA i ew. kompatybilność wsteczną. Polityka vs kontakt (interfejs): Polityka może zmieniać sie w trakcie rune-time-u.
Serwis ws. moduł Serwis ma tożsamość (adres) moduł (dll) niekoniecznie koszt utrzymania serwisu jest niezerowy, koszt istnienia (nie mowimy o developmencie/destowaniu/dystrybucji) koszt komunikacji z serwisem może być znaczący moduł może istnieć w przestrznie adresowej nie można udawać, że komunikacji nie ma!!! Wołanie zdalne może się nie powieść na różne sposoby.
Dlaczego SOA jest trudne Problemy Utrzymywanie wersji (serwisu!!!) nie jest darmowe Sztywność architektury + trudne zmiany kontraktu – ale w sumie chodzi o to aby tego nie zmieniać Co z kompatybilnością ? jeśli zmiany są konieczne – wersjonowanie Diagnostyka, Deploymenty, Dokumentacja Stabilność systemu opartego na synchronicznych wołaniach zależy (czy powinna?) od stabilności sieci/komunikacji