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