Wykład 5 - Instytut Informatyki Teoretycznej i Stosowanej

Programowanie aplikacji
równoległych i rozproszonych
Wykład 5
Dr inż. Tomasz Olas
[email protected]
Instytut Informatyki Teoretycznej i Stosowanej
Politechnika Cz˛estochowska
Wykład 5 – p. 1/54
Architektura typu klient - serwer
Klient - Serwer to asymetryczna architektura, w której pewna
funkcjonalność została rozdzielona i wyodbrebnione
˛
zostały dwa
elementy:
klient - potrzebujacy
˛ pewnej usługi, zlecajacy
˛ ja˛ serwerowi,
serwer - dostarczajacy
˛ usługi zlecanej przez klienta.
Wykład 5 – p. 2/54
Cechy architektury klient - serwer
Cechy charakterystyczne serwera:
pasywny,
czeka na żadania
˛
od klientów,
w momencie otrzymania żadania,
˛
przetwarza je, a nastepnie
˛
wysyła odpowiedź.
Cechy charakterystyczne klienta:
aktywny,
wysyła żadanie
˛
do serwera,
oczekuje na odpowiedź od serwera.
Wykład 5 – p. 3/54
Architektury klient - serwer
Podział ze wzgledu
˛
na sposób obsługi żada
˛ ń od klientów:
serwer iteracyjny (sekwencyjne) (iterative server ),
serwer współbieżny (concurrent server ).
Podział ze wzgledu
˛
na obsługe˛ stanów serwera:
serwer bezstanowy (stateless server ),
serwer stanowy (stateful server ).
Podział ze wzgledu
˛
na „rozdzielenie pracy”:
cienki klient (thin client),
gruby (bogaty) klient (fat/rich client).
Podział ze wzgledu
˛
na liczbe˛ warstw (modułów),
Podział ze wzgledu
˛
na sposób komunikacji (przy użyciu protokołu
połaczeniowego
˛
lub bezpołaczeniowego).
˛
Wykład 5 – p. 4/54
Serwer bezstanowy - stanowy
Serwer bezstanowy
nie przechowuje żadnych informacji dotyczacych
˛
klienta,
klient za każdym razem, gdy wywołuje usługe˛ serwera musi
podać wszystkie dane niezbedne
˛
do wykonania usługi.
Serwer stanowy
przechowuje informacje dotyczace
˛ klienta. Można tutaj wyróżnić
dwa typy tych informacji:
informacja globalna - przechowywana przez cały czas
działania serwera (np. stan licznika),
informacja o stanie sesji (session state) - informacje o stanie
połaczenia
˛
z klientem sa˛ przechowywane przez cały czas
trwania sesji.
Wykład 5 – p. 5/54
Podział pracy klienta i serwera
Wykład 5 – p. 6/54
Architektura trójwarstwowa
Wykład 5 – p. 7/54
Warstwy aplikacji - model MVC
MVC (ang. Model-View-Controller) - Model-Widok-Kontroler składa
sie˛ z trzech poziomów (warstw):
1. Poziom interfejsu użytkownika
np. dokument w przegladarce
˛
2. Poziom przetwarzania (logiki sterowania)
np. przetworzenie zapytania w przegladarce
˛
internetowej
3. Poziom danych (modelu danych)
np. informacje znajdujace
˛ sie˛ w bazie danych
Wykład 5 – p. 8/54
Zdalne wywołanie procedur - koncepcja
Zadaniem mechanizmu zdalnego wywołania procedur (Remote
Procedure Call) jest zachowanie w możliwie maksymalnym stopniu
semantyki zwykłych wywołań procedur w środowisku sieciowym.
Wykład 5 – p. 9/54
System Sun RPC (I)
Produkt Sun RPC został wprowadzony i wypromowany przez firme˛
Sun Microsystems jednocześnie z systemem NFS.
RPC umożliwia konstruowanie aplikacji rozproszonych według
modelu klient–serwer.
Aplikacje oparte na systemie RPC najcz˛eściej sa˛ tworzone przy
wykorzystaniu kompilatora protokołów, takiego jak rpcgen firmy Sun
Microsystems.
Wykład 5 – p. 10/54
System Sun RPC (II)
W skład Sun RPC wchodza:
˛
biblioteka funkcji,
narz˛edzie rpcgen służace
˛ do generowania dla aplikacji kodu
obsługi sieci na podstawie opisu interfejsu procedur.
Parametry wywołania funkcji i zwracane wyniki przesyłane sa˛ w
formacie XDR (eXternal Data Representation - zewnetrzna
˛
reprezentacja danych).
Z mechanizmu Sun RPC można korzystać przy użyciu protokołu
transportu TCP lub UDP.
Serwer może udostepniać
˛
dla wywołań RPC wiele podprogramów.
Wykład 5 – p. 11/54
RPC - zasada działania
Działanie RPC jest synchroniczne: aplikacja klient wysyła do
serwera polecenie wykonania podprogramu wraz z argumentami
wywołania. Nastepnie
˛
klient przechodzi w stan oczekiwania na
zakończenie wykonania podprogramu, aby odebrać zwracane przez
podprogram wyniki.
Wykład 5 – p. 12/54
Usługi RPC
Usługa˛ w RPC nazywa sie˛ zbiór funkcji przyjmujacych
˛
określone
argumenty i zwracajacych
˛
określone wyniki.
Deklaracje argumentów i wyników to interfejs usługi.
Z punktu widzenia programisty usługa jest identyfikowana przez
numer programu i numer wersji.
Wykład 5 – p. 13/54
Program rpcbind
rpcbind jest serwerem dokonujacym
˛
konwersji numerów
programów RPC na numer portu tzw. portmapper (port 111)
1.
serwer rejestruje sie˛ u demona portmap,
2.
klient żada
˛ numeru portu serwera,
3.
demon portmap odsyła klientowi numer portu serwera,
4.
klient wysyła żadanie
˛
do serwera,
5.
serwer wysyła odpowiedź do klienta.
Wykład 5 – p. 14/54
Pieniek klienta i pieniek serwera
W RPC stosowane sa˛ pojecia
˛
pieńka klienta (interfejsu klienta) i
pieńka serwera (interfejsu serwera).
Pieniek klienta symuluje w aplikacji klienta lokalne działanie
procedury.
Pieniek serwera czeka na żadanie
˛
nadchodzace
˛ od klienta.
Wykład 5 – p. 15/54
Specyfikacja usług RPC
W RPC odległe usługi sa˛ zorganizowane i identyfikowane według
hierarchii
jeden serwer zawiera jeden program
jeden program ma jedna˛ lub kilka wersji
każda z wersji zawiera jedna˛ lub kilka procedur
Wykład 5 – p. 16/54
Specyfikacje programów
Numer programu - liczba 32-bitowa
0000 0000 – 1fff ffff - SunRPC
2000 0000 – 3fff ffff - definiowane przez użytkownika
4000 0000 – 5fff ffff - tymczasowe
6000 0000 – ffff ffff - zarezerwowane
Numer wersji - liczba 32-bitowa
Numer procedury - liczba 32-bitowa
Wykład 5 – p. 17/54
Polecenie rpcinfo
Zwraca informacje dotyczace
˛ usług zarejestrowanych w rpcbind
Wyświetlenie wszystkich usług na wskazanym serwerze:
rpcinfo -p [ host ]
Przykład:
program wer. proto
100000
2
tcp
100000
2
udp
391002
2
tcp
100024
1
udp
100024
1
tcp
port
111
111
901
757
760
portmapper
portmapper
sgi_fam
status
status
Wykład 5 – p. 18/54
Program rpcgen
Program rpcgen jako wejście pobiera plik specyfikacji usług w
formacie jezyka
˛
RPC IDL („C” z dodatkiem typów program i
version).
Zostanie wygenerowany żadany
˛
kod jezyka
˛
C z implementacja˛
zdefiniowanego wywołania zdalnej procedury.
Wykład 5 – p. 19/54
Jezyk
˛
RPC
Plik z definicja˛ protokołu może zawierać nastepuj
˛ ace
˛ elementy:
obowiazkowa
˛
deklaracja programu serwera i przynajmniej jednej
dostarczonej przez niego funkcji,
deklaracje złożonych typów danych wykorzystywanych w
protokole,
deklaracje stałych,
komentarze.
Wykład 5 – p. 20/54
Przekazywanie argumentów
Standardowo RPC dopuszcza tylko jeden argument wywołania
odległej procedury i jeden zwracany wynik, podawane w formie
wskaźników.
Jeśli wystepuje
˛
kilka argumentów należy je umieścić w strukturze.
Wykład 5 – p. 21/54
XDR - External Data Representation
XDR jest zdefiniowanym na potrzeby RPC formatem danych,
zapewniajacym
˛
ich pełna˛ przenośność w środowisku
heterogenicznym.
Konwersja danych znajdujacych
˛
sie˛ w pamieci
˛ do formatu XDR
(szeregowanie) i odwrotnie (deszeregowanie) odbywa sie˛ przy
użyciu specjalnych procedur zwanych filtrami.
Dla typów podstawowych zostały zdefiniowane odpowiednie filtry,
natomiast dla typów złożonych programista musi je utworzyć
samodzielnie.
XDR może być używany również poza RPC, np. do tworzenia w
pełni przenośnych plików binarnych.
Wykład 5 – p. 22/54
Przykład - plik kalkulator.x
struct liczby{
int x1;
int x2;
};
program KALKULATOR {
version WERSJA {
int dodaj(liczby) = 1;
} = 1;
} = 0x21000000;
Wykład 5 – p. 23/54
Przykład - kod klienta (I)
#include <iostream>
#include <rpc/rpc.h>
#include "ser.h"
int dodaj(int a, int b)
{
CLIENT *c1;
integers arg;
int *ret;
char* host = "localhost";
c1 = clnt_create(host, KALKULATOR, WERSJA, "tcp");
if (c1 == NULL)
{
clnt_pcreateerror(host);
return -1;
}
Wykład 5 – p. 24/54
Przykład - kod klienta (II)
arg.x1 = a;
arg.x2 = b;
ret = (int*)dodaj_1(&arg, c1);
if (ret == NULL)
{
clnt_perror(c1, "blad wywolania odleglej procedury");
return -1;
}
clnt_destroy(c1);
return (*ret);
}
int main()
{
int a = 1, b = 1;
std::cout << dodaj(a,b);
}
Wykład 5 – p. 25/54
Przykład - kod serwera
#include <rpc/rpc.h>
#include "ser.h"
int dodaj(int x1, int x2)
{
return x1 + x2;
}
int *dodaj_1_svc(intargs* arg, svc_req *)
{
int* result = new int;
*result = dodaj(arg->x1, arg->x2);
return result;
}
Wykład 5 – p. 26/54
Zdalne wywołanie metod
RMI to podstawowy mechanizm typu RPC dostepny
˛
w jezyku
˛
Java.
W przeciwieństwie do Sun RPC jest mechanizmem w pełni
obiektowym.
Nie wprowadza żadnych nowych elementów wykraczajacych
˛
poza
sam jezyk
˛
- jezykiem
˛
specyfikacji interfejsu jest sama Java.
RMI zostało właczone
˛
do JDK w wersji 1.1.
Wykład 5 – p. 27/54
Model przepływu danych
Wykład 5 – p. 28/54
Definicja interfejsu w RMI
Intefejs zdalny w RMI jest po prostu interfejsem jezyka
˛
Java.
Każdy interfejs zdalny musi spełniać nastepuj
˛ ace
˛ warunki:
musi rozszrzać interfejs java.rmi.Remote,
wszystkie jego metody musza˛ deklarować klauzula˛ throws
możliwość rzucenia wyjatku
˛
java.rmi.RemoteException.
Wykład 5 – p. 29/54
Komunikacja pomiedzy
˛
klientem i serwerem
Wykład 5 – p. 30/54
rmiregistry
Do nawiazania
˛
łaczności
˛
pomiedzy
˛
klientem a serwerem służy
rejestr serwerów (rmiregistry).
Realizuje on wyszukiwanie obiektów na podstawie ich nazwy.
Nazwa obiektu przyjmuje format URL //host:port/nazwa,
gdzie:
host - nazwa lub adres komputera gdzie uruchomiony jest
rejestr,
port - numer portu (domyślnie 1099),
nazwa - nazwa przyjeta
˛ dla obiektu zdalnego w rejestrze.
Wykład 5 – p. 31/54
Obsługa obiektów - klasa Naming
Do obsługi rejestracji w rmiregistry służa˛ statyczne metody klasy
java.rmi.Naming:
lookup() - zwraca obiekt zdalny zwiazany
˛
z podana˛ nazwa,
˛
bind() - wiaże
˛ obiekt zdalny z podana˛ nazwa˛ - jeśli podana
nazwa już wystepuje
˛
zwracany jest wyjatek
˛
klasy
AlreadyBoundException,
rebind() - wiaże
˛ obiekt zdalny z podana˛ nazwa˛ - jeśli podana
nazwa już wystepuje
˛
przypisany do niej obiekty jest
zastepowany
˛
nowym,
unbind() - usuwa powiazane
˛
nazwy z obiektem zdalnym w
rejestrze,
list() - zwraca liste˛ nazw obiektów wystepuj
˛ acych
˛
w rejestrze
(lista obiektów typu String).
Wykład 5 – p. 32/54
Implementacja klasy serwera
Aby metody obiektu mogły być zdalnie dostepne,
˛
musi on spełniać
dwa warunki:
implementować jakiś interfejs zdalny,
być wyeksportowany.
Eksport obiektu oznacza otwarcie odpowiedniego portu i
rozpocz˛ecie nasłuchu. Najprościej uzyskać ten efekt dziedziczac
˛ z
którejś z podklas klasy java.rmi.server.RemoteServer, np
java.rmi.server.UnicastRemoteObject.
Wykład 5 – p. 33/54
Przykład - Definicja interfejsu
import java.rmi.*;
public interface MojInterfejs extends Remote
{
public Double zdalnaMetoda(int i) throws RemoteException;
// inne zdalne funkcje
...
}
Wykład 5 – p. 34/54
Przykład - klasa serwera
import java.rmi.*;
import java.rmi.server.*;
import java.net.*;
public class MojSerwer extends UnicastRemoteObject implements MojInterfejs
{
public MojSerwer() throws RemoteException
{ ... }
public Double zdalnaMetoda(int i) throws RemoteException
{ ... }
public static void main(String []t) {
try {
MojSerwer ob = new MojSerwer();
Naming.rebind("MojInterfejs", ob);
}
catch (RemoteException re) { ... }
catch (MalformedURLException ue){ ... }
}
Wykład 5 – p. 35/54
Przykład - klasa klienta
import java.rmi.*;
public class MojKlient
{
public static void main(String args[])
{
if (System.getSecurityManager() == null)
System.setSecurityManager(new RMISecurityManager());
try {
MojInterfejs s =(MojInterfejs)Naming.lookup("rmi://localhost/MojInterfejs");
...
}
catch (Exception e){ ... }
}
}
Wykład 5 – p. 36/54
Standard CORBA
CORBA (Common Object Request Broker Architecture) jest
standardem przeznaczonym do kompleksowego tworzenia
obiektowych aplikacji rozproszonych.
Specyfikacja technologii CORBA została opracowana przez
konsorcjum OMG (Object Management Group) utworzone w 1989 r.
Zajmuje sie˛ ono rozwojem, adaptacja˛ i promowaniem standardów
dla rozwijania i rozpowszechniania aplikacji heterogenicznych i
rozproszonych.
OMA (Object Management Architecture) - Architektura
zarzadzania
˛
obiektami w sieci komputerowej,
CORBA.
Skupia ponad 800 czołowych firm rozwojowych, producentów
sprz˛etu komputerowego oraz dostawców oprogramowania a także
użytkowników (m. in. takie firmy jak: Apple, AT&T Digital, HP, Intel,
Inprise, IBM, Novell, Oracle, Software AG, Sybase, Symantec, Xerox
itd).
Wykład 5 – p. 37/54
Model komunikacji
Centralnym elementem architektury CORBA jest ORB (Object
Request Broker) jest odpowiedzialny za wszystkie operacje, jakie sa˛
dokonywane pomiedzy
˛
klientem a programem implementujacym
˛
usługi, czyli serwerem.
Wykład 5 – p. 38/54
Zalety (I)
Otwartość - CORBA opiera sie˛ na opublikowanej i dostepnej
˛
dla
wszystkich specyfikacji.
Uniwersalność - jest niezależna od sprz˛etu i systemu operacyjnego.
Komponenty, które ze soba˛ współpracuja˛ moga˛ działać na różnych
architekturach sprz˛etowych i pod kontrola˛ różnych systemów
operacyjnych.
Elastyczność - obiekty CORBY posiadaja˛ ściśle zdefiniowany
interfejs, poprzez który odbywa sie˛ komunikacja. Zmiany w
implementacji obiektu nie maja˛ wpływu na inne obiekty, o ile nie
zostanie zmieniony interfejs.
Wykład 5 – p. 39/54
Zalety (II)
Przenośność - obiekty CORBY sa˛ przenośne. Oznacza to, że
obiekty zbudowane na jednej platformie moga˛ być wykorzystane na
innej platformie CORBA.
Obiektowość - budowa aplikacji odbywa sie˛ zgodnie z technika˛
obiektowa.
˛
Przeźroczystość dost˛epu - punktu widzenia użytkownika
(programisty) dostep
˛ do obiektów zdalnych może być realizowany w
taki sam sposób, jak do lokalnych.
Przeźroczystość położenia - jest możliwy dostep
˛ do obiektów bez
konieczności dokładnego określania ich położenia.
Wykład 5 – p. 40/54
Usługi CORBA
usługa nazewnictwa (naming service) - pozwala obiektom na
wzajemna˛ lokalizacje˛ poprzez wykorzystanie ich nazw,
usługa zdarzeń (event service) - umożliwia obiektom odbieranie
zdarzeń,
usługa transakcji (transaction service) - definiuje reguły
transakcyjności, koordynuje dwufazowe zatwierdzanie operacji
pomiedzy
˛
obiektami,
usługa bezpieczeństwa (security service) - zapewnia funkcje˛
autentyfikacji, autoryzacji i szyfrowania. Dzieki
˛ temu możliwa jest
ochrona danych i kontrola dostepu
˛
użytkowników do aplikacji i usług.
Wykład 5 – p. 41/54
Schemat architektury aplikacji w Corbie
Wykład 5 – p. 42/54
Struktura mechanizmu ORB
Warstwa ORB stanowi centralny obiekt Corby. Dlatego sposób jego
budowy decyduje o tym, że Corba to technologia niezależna od
platformy sprz˛etowo–programowej.
W architekturze ORG zdefiniowano pojecie
˛
mostu, który odpowiada
za dostep
˛ do implementacji obiektu oraz komunikacje˛ z klientem.
Most jest odpowiedzialny za unifikacje˛ danych przekazywanych w
warstwie ORB.
Pozwala on również na tworzenie domen, które odpowiedzialne sa˛
za poszczególne obiekty Corby (umożliwia to np. ograniczenie
dostepności
˛
pewnych obiektów, do których maja˛ dostep
˛ tylko klienci
z wybranej dziedziny.
Wykład 5 – p. 43/54
Komunikacja miedzy
˛
domenami ORB
Za komunikacje˛ wewnatrz
˛ domeny odpowiada protokół o nazwie
GIOP (The General Inter-ORB Protocol). Główne jego zadanie to
zapewnienie komunikacji poszczególnym obiektom ORB.
Do komunikacji pomiedzy
˛
domenami ORB została utworzona
specyfikacja protokołu IIOP (Internet Inter-ORB Protocol). IIOP
wykorzystuje stos TCP/IP do komunikacji.
Dzieki
˛ protokołom GIOP i IIOP możliwy jest dostep
˛ do Corby z
poziomu różnych, nawet bardzo odmiennych od siebie, jezyków
˛
programowania.
Wykład 5 – p. 44/54
Adapter obiektu
Realizacja wywołania zdalnej metody w Corbie wymaga, aby po
stronie serwera znajdował sie˛ mechanizm, który jest odpowiedzialny
za bezpieczeństwo tej operacji, utworzenia referencji do obiektu oraz
za aktywacje˛ implementacji. Taki mechanizm nazywa sie˛ adapterem
obiektu.
W chwili obecnej CORBA zawiera dwa podstawowe typy adapterów:
Adapter BOA (Basic Object Adapter) charakteryzuje sie˛ niskim poziomem
skomplikowania w implementacji. Jego wada˛ jest ograniczenie tylko do podstawowych
operacji. Z tego powodu wielu producentów serwerów Corby dodaje do niego własne
rozwiazania,
˛
co powoduje brak zgodności pomiedzy
˛
różnymi implementacjami.
Adapter POA (Portable Object Adapter) zastepuje
˛
adapter BOA i zawiera brakujace
˛
operacje, które nie wystepuj
˛ a˛ w adapterze BOA.
Wykład 5 – p. 45/54
Wywołanie zdalnych operacji
Dostep
˛ do zdalnych obiektów może odbywać sie˛ w sposób statyczny
lub dynamiczny:
Statyczne wywołanie operacji nastepuje
˛
poprzez pieniek IDL
(ang. IDL stub). Programista specyfikuje pieniek wykorzystujac
˛
jezyk
˛
IDL. Pieniek jest funkcja˛ klienta, która pozwala statycznie
wywoływać zdalne operacje poprzez wywołanie „zwykłej”
lokalnej funkcji (badź
˛ metody w przypadku jezyka
˛
obiektowego
np. C++).
Dynamiczne wywołanie operacji. Aplikacja może w trakcie
działania może dokonać specyfikacji usługi, która jest
wymagana. Niezbedna
˛
jest przy tym informacja o interfejsie i o
niezbednych
˛
typach. Taka˛ informacje˛ można otrzymać od
programisty lub programowo z interfejsu repozytorium.
Wykład 5 – p. 46/54
Repozytorium Interfejsu
Repozytorium Interfejsu umożliwia uzyskanie dostepu
˛
do interfejsów
obiektów, operacji jakie sa˛ przez nie udostepnione
˛
oraz parametrów i
typów jakie sa˛ w nich wykorzystywane.
Można je traktować jako baz˛e danych zawierajac
˛ a˛ definicje˛ obiektów.
Repozytorium interfejsu zawiera te same informacje, które znajduja˛
sie˛ w plikach IDL.
Wykład 5 – p. 47/54
Repozytorium Implementacji
Repozytorium Implementacji zawiera informacje o klasach serwera,
instancjach obiektów i ich identyfikatorach.
Wykorzystywane jest do zarzadzania
˛
obiektami.
Używane jest również do lokalizacji i aktywacji zaimplementowanych
obiektów.
Obiekt po zarejestrowaniu w Repozytorium Implementacji
uruchamiany jest automatycznie w momencie wystapienia
˛
żadania
˛
od klienta.
Wykład 5 – p. 48/54