Komponentowe systemy rozproszone Interludium czyli krótki wykład o rozpraszaniu.

Prezentacja na temat: "Komponentowe systemy rozproszone Interludium czyli krótki wykład o rozpraszaniu."— Zapis prezentacji:

1 Komponentowe systemy rozproszone Interludium czyli krótki wykład o rozpraszaniu

2 Trudne pytania proste odpowiedzi? Sens życia ? 42 Jak realizować systemy rozproszone? SOA SOA 2.0, EDA  SOA

3 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 ????

4 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

5 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!

6 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

7 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

8 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

9 3 wymiary systemu Scalability Availiability Reliability

10 Atrubuty jakościowe które SOA może pomóc zapewnić Reusability Adaptability Maintainability

11 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

12 Marketing SOA

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

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

15 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

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

17 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

18 Styl Architektoniczny Styl architektoniczny – zespół wytycznych na temat jakie decyzje i rozwiązania sa akceptowalne I pożądane w ramach architektur definiowanych systemów

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

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

21 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