(1) Tomasz Pawlak
2 Plan prezentacji Sprawy organizacyjne Wprowadzenie do biznesowych systemów rozproszonych Architektura Komunikacja Inne pojęcia
3 Dane kontaktowe Tomasz.Pawlak@cs.put.poznan.pl www.cs.put.poznan.pl/tpawlak Pokój: 1.6.6 BT Konsultacje: Środa 14:00 15:00 Lepiej: umawiać się mailowo
4 Bibliografia G. Alonso, F. Casati, H. Kuno, V. Machiraju, Web Services: Concepts, Architectures and Applications, Springer, 2004 Wikipedia (angielska)
5 Zakres wykładu Systemy rozproszone Oprogramowanie Middleware Integracja aplikacji w przedsiębiorstwie Projektowanie i modelowanie elementów oprogramowania (UML) Usługi internetowe Protokoły koordynacji usług Modelowanie i kompozycja usług Analiza systemów biznesowych
6 Zakres laboratorium Prezentacja technologii Projekt: SOAP REST Klient usługi Serwer usługi Kompozycja usług
7 Zasady zaliczenia Wykład Kolokwium Obecność nieobowiązkowa Laboratorium Projekt Prezentacja Obecność obowiązkowa
8 Pytania?
9 Wprowadzenie
10 Co to jest system rozproszony?
10 Co to jest system rozproszony? System rozproszony (ang. distributed system) to zbiór niezależnych urządzeń technicznych połączonych w jedną, spójną logicznie całość., Wikipedia Współdzielenie zasobów Otwartość Współbieżność Skalowalność Odporność na awarie Przezroczystość
11 Co to jest proces biznesowy?
11 Co to jest proces biznesowy? Zbiór kroków powiązanych ograniczeniami kolejnościowymi i warunkami logicznymi prowadzący do realizacji celu biznesowego. Cel biznesowy Wytworzenie nowego produktu Sprzedaż produktu Dostawa towaru
12 Co to jest system biznesowy?
12 Co to jest system biznesowy? System realizujący lub wspomagający procesy biznesowe Dla nas: System komputerowy wykorzystywany w przedsiębiorstwie, np.: System Informacji Szpitalnej (HIS) System Wspomagający Projektowanie (CAD) System Planowania Zasobów Przedsiębiorstwa (ERP) Content Management System (CMS) Customer Relationship Managements (CRM) Material Requirements Planning (MRP)
13 Biznesowy System Rozproszony System Rozproszony System Biznesowy System rozproszony znajdujący swoje zastosowanie w firmie Obecnie: (Prawie) każdy system wykorzystywany w firmie
14 Biznesowy System Rozproszony Wiele komponentów Różne technologie Różni producenci Różne czasy produkcji i wdrożenia
14 Biznesowy System Rozproszony Wiele komponentów Różne technologie Różni producenci Różne czasy produkcji i wdrożenia Konieczność integracji Komunikacja Normalizacja formatów danych i samych danych Zapewnienie spójności danych, niezawodności, czasu pracy
System informacyjny 15 Modelowanie systemów informacyjnych Klient Komponent prezentacji Komponent logiki aplikacji Komponent zarządzania zasobami
16 Klient Człowiek Inny system
17 Warstwa prezentacji Warstwa prezentacji informacji klientowi Zależnie od przewidywanego klienta Inne oprogramowanie: Interfejs programistyczny (API) Człowiek: Interfejs graficzny Interfejs tekstowy Przykład: Dane w formacie XML, JSON, HTML
18 Warstwa logiki aplikacji Warstwa świadczenia usług Wykonywanie właściwej pracy Zbiór prostych operacji składających się na wykonanie żądania klienta Przykład wykonanie przelewu w banku: Pobranie informacji o przelewie Sprawdzenie dostępnych środków i/lub limitów Dopisanie operacji do rachunku i przeliczenie salda Przesłanie informacji o operacji do banku odbiorcy Pobranie opłat
19 Warstwa zarządzania zasobami Zazwyczaj: inny system, innego producenta Udostępniający dane przez własne API/protokół
20 Warstwa zarządzania zasobami Zwykle: system zarządzania bazą danych Oddzielny serwer Własnościowy protokół komunikacji, często owijany przez: ODBC JDBC ADO.NET
21 Podejścia do modelowania systemów Z góry na dół (top-down) Projektowanie od zera Z dołu do góry (bottom-up) Integracja systemów
22 Podejście z góry na dół Fazy tworzenia systemu Specyfikacja wymagań funkcjonalnych Specyfikacja wymagań pozafunkcjonalnych Implementacja logiki odpowiadającej wymaganej funkcjonalności Definicja zasobów wynikających z logiki Proces kierowany wymaganiami użytkownika Mocno związane komponenty Jednorodny system
23 Proces kierowany wymaganiami użytkownika Jak użytkownik wyjaśnił czego potrzebuje Źródło: http://www.projectcartoon.com/cartoon/2
24 Proces kierowany wymaganiami użytkownika Co zrozumiał menedżer projektu Źródło: http://www.projectcartoon.com/cartoon/2
25 Proces kierowany wymaganiami użytkownika Jak architekt zaprojektował system Źródło: http://www.projectcartoon.com/cartoon/2
26 Proces kierowany wymaganiami użytkownika Jak programista zaimplementował system Źródło: http://www.projectcartoon.com/cartoon/2
27 Proces kierowany wymaganiami użytkownika Co otrzymali beta-testerzy Źródło: http://www.projectcartoon.com/cartoon/2
28 Proces kierowany wymaganiami użytkownika Jak konsultant biznesowy opisał system klientowi Źródło: http://www.projectcartoon.com/cartoon/2
29 Proces kierowany wymaganiami użytkownika Dokumentacja systemu Źródło: http://www.projectcartoon.com/cartoon/2
29 Proces kierowany wymaganiami użytkownika Dokumentacja systemu Uwaga! Nieodłączne elementy wdrożenia systemu biznesowego Dokumentacja stanowiskowa i administracyjna Szkolenie dla pracowników Bez powyższego ryzyko nieodebrania systemu i kar finansowych Źródło: http://www.projectcartoon.com/cartoon/2
30 Proces kierowany wymaganiami użytkownika Co zostało wdrożone Źródło: http://www.projectcartoon.com/cartoon/2
30 Proces kierowany wymaganiami użytkownika Co zostało wdrożone W wielu firmach dział wdrożeń jest odseparowany od działu rozwojowego Źródło: http://www.projectcartoon.com/cartoon/2
31 Proces kierowany wymaganiami użytkownika Za co zapłacił klient Źródło: http://www.projectcartoon.com/cartoon/2
32 Proces kierowany wymaganiami użytkownika Jak wyglądało wsparcie techniczne Źródło: http://www.projectcartoon.com/cartoon/2
33 Proces kierowany wymaganiami użytkownika Czego klient naprawdę potrzebował Źródło: http://www.projectcartoon.com/cartoon/2
34 Podejście z dołu do góry Fazy tworzenia systemu Identyfikacja wymagań funkcjonalnych Analiza integrowanych systemów Dostępna funkcjonalność Możliwości Ograniczenie/modyfikacja wymagań funkcjonalnych projektu Implementacja Proces kierowany przez wymagania użytkownika i ograniczenia ich realizacji Słabo powiązane komponenty System modularny
35 Źródła ograniczeń realizacji Środowisko Przestarzałe technologie Niekompatybilne interfejsy dostępowe Braki funkcjonalne Dostęp do systemów w trybie tylko do odczytu Niewystarczająca wydajność Brak mechanizmów powiadamiania o zdarzeniach Dane Braki kluczowych informacji Np.: brak identyfikatora encji danych Błędne/niepewne informacje/nieprawidłowo zakodowane informacje Np.: Poznań, Poznan, POZ w adresie dostawy
36 Architektura systemu informacyjnego
37 Architektura 1-poziomowa (1-tier) Historycznie pierwsza Mainframe i terminale Aplikacja monolityczna Bez wyraźnej separacji odpowiedzialności komponentów
38 Spaghetti code Nieformalne, negatywne określenie jakości kodu źródłowego Analogia do spaghetti Nitki odpowiadają przepływowi sterowania Przeplatanie nitek uniemożliwia rozpoznanie poszczególnych dróg przepływu
38 Spaghetti code Nieformalne, negatywne określenie jakości kodu źródłowego Analogia do spaghetti Nitki odpowiadają przepływowi sterowania Przeplatanie nitek uniemożliwia rozpoznanie poszczególnych dróg przepływu
38 Spaghetti code Nieformalne, negatywne określenie jakości kodu źródłowego Analogia do spaghetti Nitki odpowiadają przepływowi sterowania Przeplatanie nitek uniemożliwia rozpoznanie poszczególnych dróg przepływu Źródło: https://craftofcoding.wordpress.com/2013/10/07/what-is-spaghetti-code/
39 Integracja systemów 1-tier Brak API Brak separacji odpowiedzialności Często: prosty interfejs tekstowy Komunikacja przez komunikaty na konsoli Parsowanie ekranu (komunikatów) Nieeleganckie, powolne i trudne w utrzymywaniu
40 Zalety i wady systemów 1-tier Zalety Wady Szybkość pracy Monolityczna architektura Wysoka optymalizacja Trudne w rozszerzaniu Brak przełączeń kontekstu między komponentami Niskie koszty rozwoju warstwy prezentacji i wdrożenia Trudne w integracji Wysokie koszty integracji i utrzymania zintegrowanego systemu
41 Obecne trendy Mainframe Grid złożony z wielu PC Odchodzi się od systemów monolitycznych Stare systemy 1-tier sporadycznie wykorzystywane w integracjach (np.: jako źródło danych)
Serwer PC System informacyjny 42 Systemy 2-poziomowe (2-tier) Komponenty aplikacji: Komponent prezentacji Komponent logiki i zarządzania zasobami Klient Komponent prezentacji Komponent logiki aplikacji Komponent zarządzania zasobami
43 Właściwości systemów 2-tier Rozłożenie obciążenia Serwer przetwarza dane Obliczenia związane z prezentacją realizowane na PC Łatwe przygotowanie różnych komponentów prezentacji Klient Cienki Gruby
44 Komunikacja w systemach 2-tier API serwera Stabilne Wynika z interfejsów dostępnych usług Zdalne wywołanie procedur (RPC)
45 Zalety i wady systemów 2-tier Zalety Wady Kluczowe operacje mogą być wykonane szybko Połączenie logiki i zarządzania zasobami Przenośność Ograniczona skalowalność Możliwość wykorzystania systemu niezgodnie z założeniami Klient jest podatny na awarie każdej z wykorzystywanych usług
Middleware System informacyjny 46 Architektura 3-poziomowa (3-tier) Separacja komponentów Prezentacji Logiki aplikacji Zarządzania danymi Klient Komponent prezentacji Komponent logiki aplikacji Komponent zarządzania zasobami
47 Middleware Integracja komponentów systemu Pośredniczenie w komunikacji Zapewnia pewne gwarancje dla jakości usług Niezawodność komunikacji Odporność na awarie (np.: przez replikację) Interoperacyjność (np.: automatyczna zmiana kolejności bitów) Równoważenie obciążenia
48 Właściwości systemów 3-tier Niezależność komponentów systemu Możliwość wymiany pojedynczego komponentu Niezależny rozwój komponentów Wymagania: Stabilne API komponentów logiki i zarządzania zasobami Np.: w przypadku baz danych: ODBC JDBC Lub aplikacji: CORBA SOAP + WSDL
49 Zalety i wady systemów 3-tier Zalety Wady Wysoka skalowalność Dobra przenośność kodu Niższa wydajność niż systemów 1- i 2-tier Komunikacja Łatwość rozszerzania System trudniejszy w administracji
Komponent prezentacji System informacyjny 50 Architektura n-poziomowa (n-tier) Dodatkowe poziomy, względem 3-tier, np.: Klient Serwer HTTP Generator widoku Komponent logiki aplikacji Komponent zarządzania zasobami
System informacyjny 51 Architektura n-poziomowa (n-tier) Inny przykład Klient Interfejs użytkownika wewnętrznego Interfejs użytkownika zewnętrznego Logika administratora Logika użytkownika wewnętrznego Logika użytkownika zewnętrznego Baza danych System plików Inny system 1-tier
52 Zalety i wady systemów n-tier Zalety Wady Przenośność kodu Wysoka złożoność systemu Elastyczność Trudna administracja Stosunkowo łatwo dodać nową funkcjonalność Skalowalność Wiele źródeł awarii Wysoki koszt komunikacji Duże opóźnienia Powolna praca
53 Która architektura jest najlepsza?
53 Która architektura jest najlepsza? Mała liczba poziomów Niskie koszty komunikacji Wysoka wydajność Niska elastyczność Brak skalowalności
53 Która architektura jest najlepsza? Mała liczba poziomów Duża liczba poziomów Niskie koszty komunikacji Duże koszty komunikacji Wysoka wydajność Utrata wydajności Niska elastyczność Elastyczność Brak skalowalności Skalowalność
54 Komunikacja w systemach informacyjnych
55 Rodzaje komunikacji
55 Rodzaje komunikacji Komunikacja synchroniczna
55 Rodzaje komunikacji Komunikacja synchroniczna Komunikacja asynchroniczna
56 Komunikacja synchroniczna Dobrze zdefiniowane ograniczenia na czas przesłania wiadomości przez kanał komunikacyjny Komunikacja blokująca: Strony czekają na odpowiedź, zanim mogą wykonać kolejną operację żądanie odpowiedź
57 Zalety komunikacji synchronicznej Upraszcza implementację Czekanie jest proste Przepływ sterowania jest naturalny Kod wykonujący żądanie bezpośrednio poprzedza obsługę odpowiedzi Dobra dla interakcji typu żądanie odpowiedź Dominuje w rozwiązaniach middleware
58 Wady komunikacji synchronicznej Komponenty systemu są ze sobą mocno powiązane Marnotrawstwo czasu podczas oczekiwania Potencjalnie gorsza responsywność aplikacji Obie strony komunikacji muszą być online Trudna do zarządzania/utrzymania w dużym heterogenicznym systemie
59 Komunikacja asynchroniczna Brak ograniczeń na czas przesłania wiadomości przez kanał komunikacyjny Komunikacja nieblokująca: Strony przetwarzają dalej po wysłaniu komunikatu
serwer 60 Realizacja w systemach middleware Kolejki komunikatów Przetwarzanie zdarzeniowe żądanie kolejka pobranie klient pobranie kolejka odpowiedź
61 Zalety komunikacji asynchronicznej Brak oczekiwania na odpowiedź Możliwość równoległego przetwarzania Wysoka wydajność Wysoka niezawodność Jedna ze stron komunikacji może być offline Retransmisje bez udziału nadawcy
62 Wady komunikacji asynchronicznej Wymaga miejsca składowania komunikatów (middleware) Trudna w implementacji/obsłudze Kod wysłania komunikatu jest odseparowany od obsługi odpowiedzi Wymaga dobrej synchronizacji w kliencie, aby nie wprowadzić go w stan niespójny
63 Inne pojęcia związane z biznesowymi systemami rozproszonymi
64 Jakość usług (Quality of Service, QoS) Poziom jakości usług, jaki system ma zapewnić odbiorcy Zazwyczaj dotyczy wymagań pozafunkcjonalnych Wydajność przetwarzania Niezawodność Dostępność Czas odpowiedzi Wielkość opóźnień Długość przerw serwisowych Sprawiedliwy dostęp do zasobów Zapewnienie QoS na określonym poziomie ma zwykle wpływ na architekturę systemu
65 Service Level Agreement (SLA) Umowa między klientem, a usługodawcą precyzująca warunki QoS Uzgodnienia Monitorowanie usług Raportowanie Przegląd osiąganych wyników Kary za nieprzestrzeganie
66 Niezawodność i dostępność systemu Niezawodność: Prawdopodobieństwo, że system wykona żądanie w założonym czasie Dostępność: Czas, w którym system jest gotowy do realizacji żądań użytkowników Obniżenie spowodowane przez: Błędy programowe Awarie sprzętu Źle dobrane parametry systemu Przerwy serwisowe
67 Mit dziewiątek Jaki poziom dostępności systemu jest wystarczający? 90% 99% 99,9%?
67 Mit dziewiątek Jaki poziom dostępności systemu jest wystarczający? 90% 99% 99,9%? Jak wiele dziewiątek jest wystarczające?
68 Mit dziewiątek Liczba dziewiątek Dostępność Czas awarii w roku Czas awarii w miesiącu 1 90% 36.5 dni 3 dni 2 99% 3.65 dni 7.2 godzin 3 99.9% 8.76 godzin 43.8 minut 4 99.99% 52.56 minut 4.38 minut 5 99.999% 5.26 minut 25.9 sekund 6 99.9999% 31.5 sekund 2.59 sekund
69 Ile kosztują kolejne dziewiątki? Dodatkowa/zapasowa infrastruktura Koszt zakupu Koszt utrzymania Np.: energia elektryczna, zabezpieczone pomieszczenie Czas obsługi rośnie ze złożonością systemu Wzrost liczby pracowników Koszty wynagrodzeń Suma kosztów rośnie wykładniczo
70 Kiedy kolejna dziewiątka opłaca się? Źródło: Wei-Dong Zhu et al., IBM High Availability Solution for IBM FileNet P8 Systems, IBM, 2009
Bezpieczeństwo w systemie rozproszonym 71 Poufność: Szyfrowanie komunikacji Transport Layer Security (TLS, dawniej SSL) SSL v1 v3: podatne na ataki, ostatni: POODLE TLS v1.0: użyty z niektórymi szyframi podatny na ataki, np: BEAST (AES) TLS v1.1 (zalecane przez IETF) Nowsze: TLS v1.2 Kontrola dostępu do danych Uwierzytelnienie Autoryzacja Integralność: Podpisy cyfrowe Uniemożliwienie wykonania niezaufanego kodu Zapewnienie spójności (wiarygodności?) danych Źródła: https://niebezpiecznik.pl/post/sslv3-umarl-zjadl-go-pudel/ https://niebezpiecznik.pl/post/szyfrowanie-ssltls-1-0-zlamane/
72 Wąskie gardło Wąskie gardło element zasobów lub urządzenie o najniższej sprawności, ogranicza i wyznacza potencjał dla całego systemu, Wikipedia Komponent, którego przepustowość determinuje przepustowość całego systemu
73 Strojenie (Tuning) Procedura doboru parametrów dla systemu Które eliminują wąskie gardła Maksymalizuje wydajność Projektowanie systemu Określenie parametrów technicznych systemu Implementacja Optymalizacja kodu Zrównoleglanie przetwarzania Wdrożenie Dobór nastaw do sprzętu i ilości danych
74 Dziękuję za uwagę Proszę o pytania