Chapter 18, Publikacje z Projektowanie Systemów

Pobierz Chapter 18 i więcej Publikacje w PDF z Projektowanie Systemów tylko na Docsity! Sommerville, Ian: Software Engineering, edycja 9, rozdział 18  Problematyka systemów rozproszonych  Co jest istotne w kontekście projektowania.  Przetwarzanie typu klient – serwer  Jako podstawowy model systemu rozproszonego  Wzorce architektury systemów rozproszonych  Wzorzec - zastosowanie  Oprogramowanie jako usługa  Internetowy dostęp do systemu  Systemy rozproszone są bardziej skomplikowane niż te, które działają na pojedynczym procesorze.  Złożoność związana jest z potrzebą niezależnego zarządzania częściami systemu  Nie istnieje jeden organ odpowiedzialny za system - odgórne sterowanie jest niemożliwe.  Przezroczystość (ang. Transparency)  Otwartość (ang. Openness)  Skalowalność (ang. Scalability)  Zabezpieczenie (ang. Security)  Jakość usługi (ang. Quality of service )  Zarządzanie awariami (ang. Failure management ) W jakim zakresie system rozproszony powinien być postrzegany (przez jego użytkowników) jako system pojedynczy?  W wersji idealnej użytkownikom nie powinna być potrzebna świadomość, że system jest rozproszony.  W praktyce jest to niemożliwe  Części systemu są zarządzane niezależnie, pojawiają się opóźnienia,  Często lepiej uświadomić użytkownika – bo będzie mógł poradzić sobie z problemem  Aby osiągnąć przezroczystość:  zasoby powinny być abstrakcyjne  adresowanie powinno być logiczne  za mapowanie pomiędzy reprezentacją logiczną a fizyczną odpowiedzialna jest warstwa pośrednia (middleware). W jaki sposób zdefiniować użyteczną politykę zabezpieczeń i jak ją zaimplementować?  Rozproszony system jest narażony na dużo więcej rodzajów ataków w porównaniu z systemem scentralizowanym.  Wystarczy, że sukcesem zakończy się atak tylko na część systemu, żeby otworzyć możliwość dostępu do innych jego elementów.  Jeżeli części systemu są w posiadaniu różnych organizacji, które mają niekompatybilne polityki zabezpieczeń – może to prowadzić do trudności w zabezpieczaniu systemu.  Rodzaje ataków, przed którymi musi bronić się system rozproszony:  Przechwycenie (ang. Inteception)– komunikacja pomiędzy elementami systemu zostaje przechwycona przez atakującego w taki sposób, że następuje utrata poufności.  Przerwanie – usługi systemu są atakowane w taki sposób, że nie może ich on dostarczać w oczekiwany sposób. ▪ Odmowa usługi (ang. Denial of service) – atak polegający na bombardowaniu usługi zgłoszeniami. Zajęty przetwarzaniem system nie jest w stanie przetwarzać prawdziwych zgłoszeń.  Modyfikacja – dane i/lub usługi systemu są zmienione przez atakującego.  Fabrykacja – atakujący generuje informację, która nie powinna istnieć i wykorzystuje ją następnie do uzyskania uprawnień. Jak wyspecyfikować jakość usługi?  Jakość usługi oferowana przez rozproszony system odzwierciedla jego zdolność dostarczania usług:  Niezawodnie  Z czasem odpowiedzi oraz przepustowością, która jest akceptowalna przez użytkowników.  QoS jest krytyczne w przypadku systemów związanych z danymi przetwarzanymi w czasie rzeczywistym (np. strumienie audio i video).  Brak odpowiedniego poziomu QoS może spowodować degradację sygnału do poziomu niwelującego zrozumiałość informacji. Ważter Diner i X what wow pou like? Tamatn saup płease And to fallceg? Fillet zteak How watżd you like Bt cooked? Rare please iiith salad ar french fries? Salad please ETC,  <starter> <dish name = “soup” type = “tomato” /> <dish name = “soup” type = “fish” /> <dish name = “pigeon salad” /> </starter> <main course> <dish name = “steak” type = “sirloin” cooking = “medium” /> <dish name = “steak” type = “fillet” cooking = “rare” /> <dish name = “sea bass”> </main> <accompaniment> <dish name = “french fries” portions = “2” /> <dish name = “salad” portions = “1” /> </accompaniment>  Komunikacja proceduralna w systemie rozproszonym implementowana jest za pomocą zdalnych wywołań procedur.  W RPC jeden z komponentów wywołuje inny komponent w taki sam sposób jakby wywoływał procedurę lokalną. Warstwa pośrednia przechwytuje wywołanie i przekazuje je do zdalnego komponentu.  Zdalny komponent wykonuje obliczenia i, za pośrednictwem warstwy pośredniej, zwraca rezultat wywołującemu.  Wymagania RPC:  wywołujący i wołany muszą być dostępni w czasie komunikacji.  wywołujący i wołany muszą wiedzieć jak się ze sobą komunikować. Application components Middleware 4 T Operating system 1 T Networking System | Coardinated aperatean Infarmatan eachange and TOMITION SETACH Laegicał interaction Physical conmectivity AppScation components Meddleware Operating system Networking System 2  Koordynacja interakcji pomiędzy różnymi komponentami systemu  Przezroczystość lokacji – komponenty nie musza znać fizycznej lokacji pozostałych elementów systemu.  Świadczenie wspólnych usług. Warstwa pośrednia udostępnia implementacje usług, które mogą być wymagane przez komponenty systemu  Są to zazwyczaj usługi związane z inter- operacyjnością, udostępnianiem usług.  Do najpopularniejszych wzorców architektonicznych aplikacji rozproszonych należą:  Architektura Master-slave.  Dwuwarstwowa architektura typu klient-serwer  Wielowarstwowa architektura typu klient-serwer  Architektura rozproszonych komponentów ,  Architektura peer-to-peer,  Systemy rozproszone dostępne za pośrednictwem Internetu są zazwyczaj systemami typu klient-serwer.  W tego typu systemach użytkownik komunikuje się z aplikacją działającą na lokalnym komputerze (np. przeglądarką internetową). Aplikacja ta komunikuje się z programem działającym za zdalnym komputerze (np. serwerze webowym).  Zdalny komputer udostępnia usługi dostępne dla klientów. Proces klienta m f ( 4 Proces serwera  51, 52 5C2 e ©* Newark PCT 53, 54 G) cJ (ee) Server cnmputer O Client camputer  Preszntatzan Server Thin=clig et Database model Data management Application processing Freseriaiien p Apalication pracessinę j Faf-qlignt madal Client Database Data management  Wykorzystywany w sytuacji, kiedy przeprowadza się migrację istniejącego systemu do architektury klient-serwer.  Istniejący (spadkowy) system działa jako serwer . Interfejs graficzny implementowany jest po stronie klienta.  Podstawową wadą tego rozwiązania jest duże obciążenie sieci oraz serwera.  Więcej przetwarzania przeniesione jest na stronę klienta – aplikacja jest częściowo wykonywana lokalnie.  Bardziej adekwatne dla nowych systemów klient – serwer, gdzie możliwości klienta są znane a priori.  Model bardziej skomplikowany niż cienki klient – szczególnie w kontekście zarządzania. Nowe wersje aplikacji muszą być instalowane na kliencie. Warstwa prezentacji / (Klient | Komunikacja HTTPS (<ian Web server Zapytanie s System obsługi A at kont bankowych S-) „Klient warstwa aplikacji i e zarządzania danymi Database server Baza danych klientów SQL Warstwa bazy danych  Nie ma rozróżnienia na klientów i serwery.  Każda rozproszona jednostka jest obiektem udostępniającym usługi i korzystającym z usług innych komponentów  Komunikacja odbywa się za pośrednictwem warstwy pośredniej.  Bardziej skomplikowana od architektury klient-serwer  Zastosowanie: zasoby różnych systemów i baz danych muszą być połączone. Może również być to model implementacji wielowarstwowej architektury klient serwer. Comp | | Comp 4 | Comp 4 commen common common | common SETWXES sATVICES © (65 | SETWIEPS Commurscaticn msddleware k,  Systemy Peer to peer (p2p) to systemy zdecentralizowane, w których obliczenia mogą być przeprowadzane na dowolnym węźle w sieci.  System projektowany jest w taki sposób, aby wykorzystać moc obliczeniową oraz pamięć dużej liczby połączonych sieciowo komputerów.  Większość systemów p2p stanowią systemy niebiznesowe. Jednak technologia jest również wykorzystywana w systemach biznesowych.  Logiczna architektura sieci  Zdecentralizowana;  Pół-scentralizowana.  Architektura aplikacji  Generyczna organizacja komponentów tworzy aplikację p2p.  Architektura P2P skupia się na architekturze sieci.  Oprogramowanie jako usługa to sposób udostępniania funkcjonalności na zdalnym serwerze, do którego klient uzyskuje dostęp za pośrednictwem przeglądarki Internetowej. Serwer zarządza danymi użytkownika oraz stanem przetwarzania podczas sesji. Transakcje są zazwyczaj długie (np. edycja dokumentów).  Architektura zorientowana usługowa (Service Oriented Architecture - SOA) to podejście polegające na budowaniu systemu w postaci zbioru bezstanowych usług. Usługi te mogą być dostarczane przez różnych dostawców i mogą być rozproszone. W tego typu rozwiązaniach transakcje są zazwyczaj krótkie – usługa jest wołana – wykonuje działanie i zwraca rezultat.  Konfigurowalność - W jaki sposób konfigurować oprogramowanie dla specyficznych wymagań różnych organizacji?  Wynajmowanie wspólnej puli zasobów (ang. Multi-tenancy)  Udostępnianie oprogramowanie użytkownikowi, w taki sposób aby miał wrażenie, że pracuje na swojej własnej kopii systemu  Architektura systemu umożliwia efektywnie wykorzystanie zasobów.  Wymaga to istnienia bezwzględnej separacji funkcjonalności oraz danych systemu.  Zaletą systemów rozproszonych jest możliwość ich skalowania w miarę wzrastających potrzeb. Może również kontynuować udostępnianie usług pomimo awarii oraz pozwala na współdzielenie zasobów.  Do istotnych zagadnień, które należy wziąć po uwagę w trakcie projektowanie systemów rozproszonych należą: przezroczystość, otwartość, skalowalność, zabezpieczenie, jakość obsługi oraz zarządzanie awariami.  Systemy typu klient-serwer mają strukturę warstwową. Warstwy mogą być rozproszone na różne komputery  Do wzorców architektury systemów rozproszonych należą: architektura master-slave, dwuwarstwowa i wielowarstwowa architektura typu klient- serwer, architektura rozproszonych komponentów oraz architektura peer-to-peer.  Architektura rozproszonych komponentów wymaga istnienia warstwy pośredniej. Jej podstawowym zdaniem jest pośredniczenie w komunikacji pomiędzy komponentami oraz umożliwienie dodawania i usuwania komponentów do/z systemu.  Architektura peer-to-peer reprezentuje zdecentralizowaną strukturę systemu bez podziału na usługobiorcę (klienta) i usługodawcę (serwer). Obliczenia mogą być rozproszone pomiędzy wiele systemów i organizacji.  Oprogramowanie jako usługa (Software as a service) to metoda wdrażania systemów z cienkim klientem, w którym klientem jest przeglądarka Internetowa.