Wykład 2. Wprowadzenie do architektur systemów rozproszonych Uniwersytet Łódzki Katedra Informatyki W. Bartkiewicz Systemy rozproszone Wykład 2. Wprowadzenie do architektur systemów rozproszonych

Systemy jednostanowiskowe Katedra Informatyki Systemy jednostanowiskowe

Centralne zarządzanie zasobami Katedra Informatyki Centralne zarządzanie zasobami Współdzielenie zasobów Integracja zasobów Redukcja nadmiarowości zasobów Integralność zasobów

Architektura monolityczna (mainframe) Katedra Informatyki Architektura monolityczna (mainframe) Skupienie przetwarzania na wyłącznie na jednym komputerze Ograniczenia w skalowalności aplikacji Ograniczenie do znakowego interfejsu użytkownika

Architektura oparta na serwerze plików Katedra Informatyki Architektura oparta na serwerze plików Aplikacje na PC współdzielą dane za pośrednictwem serwera plików Duży ruch w sieci Konieczność synchronizacji dostępu Ograniczenie do ok. 12 użytkowników Desktopowa obsługa zbiorów danych Serwer plików

Architektura klient-serwer Katedra Informatyki Architektura klient-serwer Centralne zarządzanie danymi Niezależność danych i aplikacji Zmniejszenie ruchu sieciowego – transport wyłącznie odpowiedzi na zapytania, a nie całych plików Klienty SerwerDBMS Zapytania SQL Odpowiedzi na zapytania

Architektura dwuwarstwowa (gruby klient) Katedra Informatyki Architektura dwuwarstwowa (gruby klient) Interfejs użytkownika (zarządzanie dialogiem i prezentacją wyników) Zarządzanie danymi Logika aplikacji (przetwarzanie danych, wykonywanie obliczeń, itp.) Zarządzanie danymi SerwerDBMS Klient Interfejs użytkownika Logika aplikacji

Architektura dwuwarstwowa (gruby klient) Katedra Informatyki Architektura dwuwarstwowa (gruby klient) Procedury składowane Logika aplikacji Skalowalność do około 100 użytkowników Zarządzanie danymi SerwerDBMS Klient Dalsze zmniejszenie ruchu sieciowego Większe obciążenie serwera Interfejs użytkownika Logika aplikacji

Architektura dwuwarstwowa (cieńki klient) Katedra Informatyki Architektura dwuwarstwowa (cieńki klient) Serwer aplikacji Aplikacje klienckie są ładowane z serwera Nie ma potrzeby ich dystrybucji Nie ma potrzeby ich instalacji Nie ma potrzeby wersjonowania dla różnych systemów operacyjnych Zarządzanie danymi Logika aplikacji Serwer HTTP Klient (przeglądarka) Żądania HTTP Strony HTML Interfejs użytkownika (webowy)

Architektura dwuwarstwowa (cieńki klient) Katedra Informatyki Architektura dwuwarstwowa (cieńki klient) Serwer aplikacji Zwiększone obciążenie serwera Brak zarządzania stanem Architektura dobrze dostosowana do lekkich aplikacji dla dużej liczby klientów w sieci rozległej Zarządzanie danymi Logika aplikacji Serwer HTTP Klient (przeglądarka) Żądania HTTP Strony HTML Interfejs użytkownika (webowy)

Architektura dwuwarstwowa (klient wzbogacony) Katedra Informatyki Architektura dwuwarstwowa (klient wzbogacony) Cieńki klient - formularze HTML Skrypty strony klienta (JavaScript, VBScript) Obiekty (komponenty), np.. kontrolki Active-X Aplety Javy Kontrolki webowe .NET (renderowane jako HTML+skrypty) Zarządzanie danymi Logika aplikacji Serwer HTTP Klient (przeglądarka) Żądania HTTP Strony HTML Interfejs użytkownika (webowy)

Architektura dwuwarstwowa (oprogramowanie serwera) Katedra Informatyki Architektura dwuwarstwowa (oprogramowanie serwera) Skrypty CGI Skrypty serwerowe (PHP, ASP, JSP, ASP.NET) Obiekty serwerowe (serwelety Javy, komponenty .NET) Rozszerzenia serwera (np. filtry ISAPI) Zarządzanie danymi Logika aplikacji Serwer HTTP Klient (przeglądarka) Żądania HTTP Strony HTML Interfejs użytkownika (webowy)

Katedra Informatyki Skrypty CGI Aplikacje natywne dla systemu operacyjnego serwera HTTP lub skryptowe wykonywane przez interpreter działający poza serwerem HTTP (czyli jako skrypt CGI) Uruchamiane przez serwer HTTP jako nowe procesy Serwer HTTP przekazuje dane od klienta na wejście standardowe aplikacji CGI lub poprzez zmienne środowiskowe Problemy efektywnościowe - uruchamianie i kończenie procesów wymaga zarządzania wieloma zasobami systemowymi maszyny serwera Problemy z bezpieczeństwem – aby serwer mógł uruchomić skrypt CGI użytkownika zdalny musi mieć uprawnienia do wykonywania programów w folderze skryptu

Skrypty serwerowe (PHP, JSP, ASP, ASP.NET) Katedra Informatyki Skrypty serwerowe (PHP, JSP, ASP, ASP.NET) Skrypty interpretowane poprzez interpreter działający zwykle w trybie rozszerzenia serwera Wymagają mniejszej ilości zasobów systemowych – wykonują się w kontekście serwera Po pierwszym wykonaniu zazwyczaj kompilowane do kodu pośredniego Użytkownik uruchamiający skrypt nie musi mieć nadanych uprawnień do wykonywania programów – w niektórych serwerach HTTP do uruchamiania skryptów Umieszczane jako wstawki między elementami HTML lub jako odrębne moduły programowe (Code Behind Page)

Obiekty (komponenty) serwerowe Katedra Informatyki Obiekty (komponenty) serwerowe Kompilowane do kodu pośredniego komponenty osadzane w środowisku serwera (i środowisku komponentowym) Serwelety Javy i komponenty .NET Tworzone jako odrębne aplikacje lub kompilowane ze skryptów serwerowych (JSP – serwelety, ASP.NET – komponenty .NET)

Rozszerzenia serwera HTTP Katedra Informatyki Rozszerzenia serwera HTTP Moduły kodu natywnego dla maszyny na której działa serwer HTTP, uruchamiane w kontekście jego działania Dostarczane w postaci bibliotek dynamicznych lub komponentów natywnych, które proces serwera potrafi uruchomić (a więc o pewnej standardowej strukturze) Typowe przykłady – interpretery skryptów serwerowych, filtry ISAPI – komponenty COM rozszerzające funkcjonalność serwera IIS

Grube klienty Klienty Serwer DBMS Inne aplikacje Katedra Informatyki Grube klienty Odciążenie serwera (rozproszenie przetwarzania), Zwiększenie ruchu sieciowego (przesyłanie całych wyników zapytań) Dla różnych interfejsów użytkownika (np. webowy i aplikacyjny) niezbędne jest zbudowanie w zasadzie dwu różnych aplikacji Klienty Serwer DBMS Inne aplikacje

Cieńkie klienty Klienty Serwer DBMS Inne aplikacje Katedra Informatyki Cieńkie klienty Zmniejszenie ruchu sieciowe-go (przesyłanie wyłącznie wyników przetwarzania) Zwiększanie obciążenia serwera, z którego korzystać mogą również inne aplikacje Zmiana interfejsu użytkownika wymaga jedynie zbudowania nowego klienta Klienty Serwer DBMS Inne aplikacje

Architektura trójwarstwowa Katedra Informatyki Architektura trójwarstwowa Klienty Logika aplikacji umieszczona jest w warstwie pośredniej między serwerem danych i klientem (serwer aplikacji) Umożliwia to korzystanie z zalet cieńkiego klienta bez konieczności obciążania serwera bazy danych Serwer aplikacji Serwer DBMS Inne aplikacje

Architektura trójwarstwowa z warstwą pośrednią na serwerze HTTP Katedra Informatyki Architektura trójwarstwowa z warstwą pośrednią na serwerze HTTP Struktura warstwy pośredniej: usługi fasady – wiążące warstwę pośrednią z interfejsem użytkownika) główne usługi logiki aplikacji (np. kod przetwarzający zamówienia, dane klientów, itp.) usługi dostępu do danych (zarządzające przesyłaniem zapytań do serwera SQL i pobieraniem ich wyników) Klient webowy HTML Interfejs użytkownika Serwer DBMS Zarządzanie danymi Serwer HTTP Logika aplikacji Klient aplikacyjny SOAP

Architektura trójwarstwowa z warstwą pośrednią na serwerze HTTP Katedra Informatyki Architektura trójwarstwowa z warstwą pośrednią na serwerze HTTP Metody dostępu do danych: natywne biblioteki związane z konkretnym językiem programowania ODBC ADO ADO.NET JDBC Klient webowy HTML Interfejs użytkownika Serwer DBMS Zarządzanie danymi Serwer HTTP Logika aplikacji Klient aplikacyjny SOAP

Problem stanu aplikacji webowej Katedra Informatyki Problem stanu aplikacji webowej W architekturze dwuwarstwowej serwer DBMS jest serwerem połączeniowym Serwer HTTP jest serwerem bezpołączeniowym w tradycyjnych prostych aplikacjach webowych informacja o stanie jest zbędna w bardziej złożonych aplikacjach trójwarstwowych informacja o stanie jest często podstawowa Klient webowy HTML Interfejs użytkownika Serwer DBMS Zarządzanie danymi Serwer HTTP Logika aplikacji Klient aplikacyjny SOAP

Problem stanu aplikacji webowej Katedra Informatyki Problem stanu aplikacji webowej Przechowywanie stanu w warstwie środkowej (plikach na serwerze HTTP) w warstwie bazy danych Przesyłanie stanu do warstwy klienta żetony cookies ukryte zmienne formularzy Klient webowy HTML Interfejs użytkownika Serwer DBMS Zarządzanie danymi Serwer HTTP Logika aplikacji Klient aplikacyjny SOAP

Interfejs użytkownika Katedra Informatyki Serwisy webowe Standardowe aplikacje webowe komunikują się z klientem poprzez komunikaty HTML (np. generują i przesyłają do klienta strony HTML) Komunikaty HTML mogą być odbierane również przez klienty aplikacyjne – wymaga to jednak analizy przesłanej strony i „wydłubania” danych Web serwisy – rodzaj komponentów serwerowych komunikujących się z klientem aplikacyjnym poprzez komunikaty SOAP Klient webowy HTML Interfejs użytkownika Serwer DBMS Zarządzanie danymi Serwer HTTP Logika aplikacji Klient aplikacyjny SOAP

Interfejs użytkownika Katedra Informatyki Serwisy webowe SOAP (Simple Object Access Protocol) – oparty na XML-u sposób kodowania wywołań zdalnych podprogramów SOAP umożliwia realizację RPC (Remote Procedure Call) klient wywołuje funkcję jej nazwa parametry wywołania kodowane są w formacie SOAP i przesyłane do serwera HTTP serwer uruchamia komponent (web serwis), który wykonuje zakodowaną funkcję. Wynik jej działania w formacie SOAP przesyłany jest do klienta Klient webowy HTML Interfejs użytkownika Serwer DBMS Zarządzanie danymi Serwer HTTP Logika aplikacji Klient aplikacyjny SOAP

Rozproszone architektury Enterprise Katedra Informatyki Rozproszone architektury Enterprise Komponenty i obiekty rozproszone. Standardowe formaty: CORBA COM/DCOM Java Beans .NET Serwisy webowe Koordynator transakcji rozproszonych (np. MTS) Usługi kolejkowania komunikatów (np. MSMQ) Klient webowy HTML Interfejs użytkownika Serwer DBMS Zarządzanie danymi Serwer HTTP Logika aplikacji Klient aplikacyjny SOAP

Rozproszone architektury Enterprise Katedra Informatyki Rozproszone architektury Enterprise Najbardziej znane środowiska typu Enterprise: CORBA Enterprise Java Beans COM+/DNA .NET Web Sphere Klient webowy HTML Interfejs użytkownika Serwer DBMS Zarządzanie danymi Serwer HTTP Logika aplikacji Klient aplikacyjny SOAP