Komponentowe i rozproszone (Web)Service Oriented Architecture.

Prezentacja na temat: "Komponentowe i rozproszone (Web)Service Oriented Architecture."— Zapis prezentacji:

1 Komponentowe i rozproszone (Web)Service Oriented Architecture

2 Serwis jako komponent Odseparowane (web) serwisy odpowiadające za poszczególne obszary domenowe Serwis może mieć własne GUI pozwalające na pracę osobom z odpowiedniego działu Synchroniczne wołania usług dostarczanych przez inne oddziały

3 Księgowość Marketing Obsługa Klientów Spedycja Sklep Magazyn Przykładowy sklep

4 Przykładowa funkcjonalność

5 Księgowość Marketing Obsługa Klientów Spedycja Sklep Magazyn

6 A gdzie są dane? W bazie danych…

7 Księgowość Marketing Obsługa Klientów Spedycja Sklep Magazyn

8 Klienci Transakcje Towary Księgowość Marketing Obsługa Klientów Spedycja Sklep Magazyn Może być gorzej?

9 To była tylko jedna akcja … Są i inne:  Raporty  Przeceny  Przyjecie nowych towarów  Wysyłka  Zwroty i reklamacje * Liczba użytkowników

10 Podejście synchroniczne – powoli, ale przynajmniej działa Procesy głównie czekają na wyniki/zasoby/potwierdzenie Lepszy sprzęt często oznacza, że poświęcamy więcej cykli (szybszego) procesora na czekanie Timeout – powoduje ponowienie żądania (a stare może być jeszcze przetwarzane) System działa w developmencie a w produkcji (od razu lub nie) całość zaczyna mieć problemy

11 Podejście synchroniczne - czasem jednak nie działa … Maintenance/awaria/deadlock w jednym podsystemie/serwerze może spowodować degradację/zatrzymanie całego systemu Przenosimy serwer - Jak np. zmienić adresację w sieci? Skalujemy system – jak dodać drugą instancję serwisu magazyn? Co z utrzymywaniem starych wersji ?

12 Zależności Utrudniają development Utrudniają wdrażanie Ograniczają stabilność Utrudniają zarządzanie i utrzymanie Nie można ich wyeliminować ale trzeba je ograniczać...

13 Zależności (coupling) w kodzie Powiązanie wynika z zalezności Wywołanie funkcji zależy od sygnatury czyli kod wywołujący zależy od definicji funkcji Miary zależności w kodzie  Ca – liczba klas (funkcji), które zależą od danej klasy (funkcji)  Ce - liczba klas (funkcji), od których zależy dana klasa (funkcja)

14 Zależności (coupling) w systemach Platformowe (protokół, format – interoperability) Czasowe (żądanie - odpowiedź) Przestrzenne (adresy – identyfikacja)

15 Kilka scenariuszy Zmiana szczegułów implementacyjnych serwisu = konieczność wersjonowania lub jednoczesnego deplymentu wielu serwisów Zmiana (deplyment) nowej wersji serwisu, od którego zależy wiele innych serwisów = zmiany konfiguracyjne w klientach Upadek bazy = downtime + utrata danych Deadlock = rollback transakcji Upadek serwisu = blad przy wywołaniu

16 Jak efektywnie redukować powiązania? Ca, Ce – zależności w kodzie, SOA – opieramy się na kontraktach Platformowe – użycie XML/JSon zamiast binarnych protokołów (SOAP?) Przestrzenne – wirtualne endpointy, routowanie (np. po typie komunikatu) Czasowe – asynchroniczne komunikaty

17 Redukcja powiązań... jest złożona Efferent Afferent Platformowe Czasowe Przestrzenne