Tomasz Pawlak. Biznesowe Systemy Rozproszone

Transkrypt

1 (1) Tomasz Pawlak

2 2 Plan prezentacji Sprawy organizacyjne Wprowadzenie do biznesowych systemów rozproszonych Architektura Komunikacja Inne pojęcia

3 3 Dane kontaktowe Pokój: BT Konsultacje: Środa 14:00 15:00 Lepiej: umawiać się mailowo

4 4 Bibliografia G. Alonso, F. Casati, H. Kuno, V. Machiraju, Web Services: Concepts, Architectures and Applications, Springer, 2004 Wikipedia (angielska)

5 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 6 Zakres laboratorium Prezentacja technologii Projekt: SOAP REST Klient usługi Serwer usługi Kompozycja usług

7 7 Zasady zaliczenia Wykład Kolokwium Obecność nieobowiązkowa Laboratorium Projekt Prezentacja Obecność obowiązkowa

8 8 Pytania?

9 9 Wprowadzenie

10 10 Co to jest system rozproszony?

11 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ść

12 11 Co to jest proces biznesowy?

13 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

14 12 Co to jest system biznesowy?

15 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)

16 13 Biznesowy System Rozproszony System Rozproszony System Biznesowy System rozproszony znajdujący swoje zastosowanie w firmie Obecnie: (Prawie) każdy system wykorzystywany w firmie

17 14 Biznesowy System Rozproszony Wiele komponentów Różne technologie Różni producenci Różne czasy produkcji i wdrożenia

18 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

19 System informacyjny 15 Modelowanie systemów informacyjnych Klient Komponent prezentacji Komponent logiki aplikacji Komponent zarządzania zasobami

20 16 Klient Człowiek Inny system

21 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

22 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

23 19 Warstwa zarządzania zasobami Zazwyczaj: inny system, innego producenta Udostępniający dane przez własne API/protokół

24 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

25 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

26 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

27 23 Proces kierowany wymaganiami użytkownika Jak użytkownik wyjaśnił czego potrzebuje Źródło:

28 24 Proces kierowany wymaganiami użytkownika Co zrozumiał menedżer projektu Źródło:

29 25 Proces kierowany wymaganiami użytkownika Jak architekt zaprojektował system Źródło:

30 26 Proces kierowany wymaganiami użytkownika Jak programista zaimplementował system Źródło:

31 27 Proces kierowany wymaganiami użytkownika Co otrzymali beta-testerzy Źródło:

32 28 Proces kierowany wymaganiami użytkownika Jak konsultant biznesowy opisał system klientowi Źródło:

33 29 Proces kierowany wymaganiami użytkownika Dokumentacja systemu Źródło:

34 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:

35 30 Proces kierowany wymaganiami użytkownika Co zostało wdrożone Źródło:

36 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:

37 31 Proces kierowany wymaganiami użytkownika Za co zapłacił klient Źródło:

38 32 Proces kierowany wymaganiami użytkownika Jak wyglądało wsparcie techniczne Źródło:

39 33 Proces kierowany wymaganiami użytkownika Czego klient naprawdę potrzebował Źródło:

40 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

41 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

42 36 Architektura systemu informacyjnego

43 37 Architektura 1-poziomowa (1-tier) Historycznie pierwsza Mainframe i terminale Aplikacja monolityczna Bez wyraźnej separacji odpowiedzialności komponentów

44 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

45 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

46 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:

47 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

48 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

49 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)

50 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

51 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

52 44 Komunikacja w systemach 2-tier API serwera Stabilne Wynika z interfejsów dostępnych usług Zdalne wywołanie procedur (RPC)

53 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

54 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

55 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

56 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

57 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

58 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

59 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

60 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

61 53 Która architektura jest najlepsza?

62 53 Która architektura jest najlepsza? Mała liczba poziomów Niskie koszty komunikacji Wysoka wydajność Niska elastyczność Brak skalowalności

63 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ść

64 54 Komunikacja w systemach informacyjnych

65 55 Rodzaje komunikacji

66 55 Rodzaje komunikacji Komunikacja synchroniczna

67 55 Rodzaje komunikacji Komunikacja synchroniczna Komunikacja asynchroniczna

68 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ź

69 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

70 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

71 59 Komunikacja asynchroniczna Brak ograniczeń na czas przesłania wiadomości przez kanał komunikacyjny Komunikacja nieblokująca: Strony przetwarzają dalej po wysłaniu komunikatu

72 serwer 60 Realizacja w systemach middleware Kolejki komunikatów Przetwarzanie zdarzeniowe żądanie kolejka pobranie klient pobranie kolejka odpowiedź

73 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

74 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

75 63 Inne pojęcia związane z biznesowymi systemami rozproszonymi

76 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

77 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

78 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

79 67 Mit dziewiątek Jaki poziom dostępności systemu jest wystarczający? 90% 99% 99,9%?

80 67 Mit dziewiątek Jaki poziom dostępności systemu jest wystarczający? 90% 99% 99,9%? Jak wiele dziewiątek jest wystarczające?

81 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 % 8.76 godzin 43.8 minut % minut 4.38 minut % 5.26 minut 25.9 sekund % 31.5 sekund 2.59 sekund

82 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

83 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

84 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:

85 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

86 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

87 74 Dziękuję za uwagę Proszę o pytania