Systemy rozproszone

Wykład 2. Wprowadzenie do architektur systemów
rozproszonych

W.
Bartkiewicz

Systemy

jednostanowiskowe

Centralne zarządzanie

zasobami

• Współdzielenie zasobów
• Integracja zasobów
• Redukcja nadmiarowości zasobów
• Integralność zasobów

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

• 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

Serwe

r

plikó

w

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

Serw
erDB
MS

Klient
y

Zap

yta

nia

SQ

L

Odpow

ied

zi na

zapytan

ia

Architektura dwuwarstwowa

(gruby klient)

• Interfejs użytkownika

(zarządzanie dialogiem i
prezentacją wyników)

• Zarządzanie danymi
• Logika aplikacji

(przetwarzanie danych,
wykonywanie obliczeń,
itp.)

Serw
erDB
MS

Klient

Zarządza

nie

danymi

Interfejs

użytkownika

Logika aplikacji

Architektura dwuwarstwowa

(gruby klient)

• Dalsze zmniejszenie

ruchu sieciowego

• Większe obciążenie

serwera

• Skalowalność do około

100 użytkowników

Serw
erDB
MS

Klient

Zarządza

nie

danymi

Interfejs

użytkownika

Logika aplikacji

Procedur
y
składowa
ne

Logika

aplikacji

Architektura dwuwarstwowa

(cieńki klient)

• 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

Serw
er
HTTP

Klient

(przegląda

rka)

Zarządzanie

danymi Logika

aplikacji

Interfejs

użytkowni

ka

(webowy)

Żądani

a

HTTP

Stron

y

HTM

L

Serwer

aplikacji

Architektura dwuwarstwowa

(cieńki klient)

• 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

Serw
er
HTTP

Klient

(przegląda

rka)

Zarządzanie

danymi Logika

aplikacji

Interfejs

użytkowni

ka

(webowy)

Żądani

a

HTTP

Stron

y

HTM

L

Serwer

aplikacji

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)

Serw
er
HTTP

Klient

(przegląda

rka)

Zarządzanie

danymi Logika

aplikacji

Interfejs

użytkowni

ka

(webowy)

Żądani

a

HTTP

Stron

y

HTM

L

Architektura dwuwarstwowa

(oprogramowanie serwera)

• Skrypty CGI
• Skrypty serwerowe (PHP,

ASP, JSP, ASP.NET)

• Obiekty serwerowe

(serwelety Javy,
komponenty .NET)

• Rozszerzenia serwera

(np. filtry ISAPI)

Serw
er
HTTP

Klient

(przegląda

rka)

Zarządzanie

danymi Logika

aplikacji

Interfejs

użytkowni

ka

(webowy)

Żądani

a

HTTP

Stron

y

HTM

L

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)

• 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

• 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

• 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

• 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

Serw

er

DBM

S

Klienty

Inne

aplikacj

e

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

Serw

er

DBM

S

Klienty

Inne

aplikacj

e

Architektura trójwarstwowa

• 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

Serw

er

DBM

S

Klienty

Inne

aplikacj

e

Serwe

r

aplika

cji

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

aplikacyj

ny

SO

A

P

Serw

er

DBM

S

Z

a

rz

ą

d

za

n

ie

d

a

n

ym

i

Serw

er

HTT

P

L

o

g

ik

a

a

p

li

k

a

cj

i

Klient

webowy

HT

M

L

In

te

rf

e

js

u

ży

tk

o

w

n

ik

a

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

aplikacyj

ny

SO

A

P

Serw

er

DBM

S

Z

a

rz

ą

d

za

n

ie

d

a

n

ym

i

Serw

er

HTT

P

L

o

g

ik

a

a

p

li

k

a

cj

i

Klient

webowy

HT

M

L

In

te

rf

e

js

u

ży

tk

o

w

n

ik

a

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

aplikacyj

ny

SO

A

P

Serw

er

DBM

S

Z

a

rz

ą

d

za

n

ie

d

a

n

ym

i

Serw

er

HTT

P

L

o

g

ik

a

a

p

li

k

a

cj

i

Klient

webowy

HT

M

L

In

te

rf

e

js

u

ży

tk

o

w

n

ik

a

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

aplikacyj

ny

SO

A

P

Serw

er

DBM

S

Z

a

rz

ą

d

za

n

ie

d

a

n

ym

i

Serw

er

HTT

P

L

o

g

ik

a

a

p

li

k

a

cj

i

Klient

webowy

HT

M

L

In

te

rf

e

js

u

ży

tk

o

w

n

ik

a

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

aplikacyj

ny

SO

A

P

Serw

er

DBM

S

Z

a

rz

ą

d

za

n

ie

d

a

n

ym

i

Serw

er

HTT

P

L

o

g

ik

a

a

p

li

k

a

cj

i

Klient

webowy

HT

M

L

In

te

rf

e

js

u

ży

tk

o

w

n

ik

a

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

aplikacyj

ny

SO

A

P

Serw

er

DBM

S

Z

a

rz

ą

d

za

n

ie

d

a

n

ym

i

Serw

er

HTT

P

L

o

g

ik

a

a

p

li

k

a

cj

i

Klient

webowy

HT

M

L

In

te

rf

e

js

u

ży

tk

o

w

n

ik

a

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

aplikacyj

ny

SO

A

P

Serw

er

DBM

S

Z

a

rz

ą

d

za

n

ie

d

a

n

ym

i

Serw

er

HTT

P

L

o

g

ik

a

a

p

li

k

a

cj

i

Klient

webowy

HT

M

L

In

te

rf

e

js

u

ży

tk

o

w

n

ik

a

Rozproszone architektury

Enterprise

• Najbardziej znane

środowiska typu
Enterprise:

– CORBA
– Enterprise Java Beans
– COM+/DNA
– .NET
– Web Sphere

Klient

aplikacyj

ny

SO

A

P

Serw

er

DBM

S

Z

a

rz

ą

d

za

n

ie

d

a

n

ym

i

Serw

er

HTT

P

L

o

g

ik

a

a

p

li

k

a

cj

i

Klient

webowy

HT

M

L

In

te

rf

e

js

u

ży

tk

o

w

n

ik

a