Programowanie aplikacjirównoległych i rozproszonych

Wykład 5

Dr inż. Tomasz Olasolas@icis.pcz.pl

Instytut Informatyki Teoretycznej i StosowanejPolitechnika Częstochowska

Wykład 5 – p. 1/54

Architektura typu klient - serwer

Klient - Serwer to asymetryczna architektura, w której pewnafunkcjonalność została rozdzielona i wyodbrębnione zostały dwaelementy:

klient - potrzebujący pewnej usługi, zlecający ją serwerowi,

serwer - dostarczający usługi zlecanej przez klienta.

Wykład 5 – p. 2/54

Cechy architektury klient - serwer

Cechy charakterystyczne serwera:

pasywny,

czeka na żądania od klientów,

w momencie otrzymania żądania, przetwarza je, a następniewysyła odpowiedź.

Cechy charakterystyczne klienta:

aktywny,

wysyła żądanie do serwera,

oczekuje na odpowiedź od serwera.

Wykład 5 – p. 3/54

Architektury klient - serwer

Podział ze względu na sposób obsługi żądań od klientów:

serwer iteracyjny (sekwencyjne) (iterative server ),

serwer współbieżny (concurrent server ).

Podział ze względu na obsługę stanów serwera:

serwer bezstanowy (stateless server ),

serwer stanowy (stateful server ).

Podział ze względu na „rozdzielenie pracy”:

cienki klient (thin client),

gruby (bogaty) klient (fat/rich client).

Podział ze względu na liczbę warstw (modułów),

Podział ze względu na sposób komunikacji (przy użyciu protokołupołączeniowego lub bezpołączeniowego).

Wykład 5 – p. 4/54

Serwer bezstanowy - stanowy

Serwer bezstanowy

nie przechowuje żadnych informacji dotyczących klienta,

klient za każdym razem, gdy wywołuje usługę serwera musipodać wszystkie dane niezbędne do wykonania usługi.

Serwer stanowy

przechowuje informacje dotyczące klienta. Można tutaj wyróżnićdwa typy tych informacji:

informacja globalna - przechowywana przez cały czasdziałania serwera (np. stan licznika),informacja o stanie sesji (session state) - informacje o staniepołączenia z klientem są przechowywane przez cały czastrwania 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ładasię z trzech poziomów (warstw):

1. Poziom interfejsu użytkownikanp. dokument w przeglądarce

2. Poziom przetwarzania (logiki sterowania)np. przetworzenie zapytania w przeglądarce internetowej

3. Poziom danych (modelu danych)np. informacje znajdujące się w bazie danych

Wykład 5 – p. 8/54

Zdalne wywołanie procedur - koncepcja

Zadaniem mechanizmu zdalnego wywołania procedur (RemoteProcedure Call) jest zachowanie w możliwie maksymalnym stopniusemantyki 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 firmęSun Microsystems jednocześnie z systemem NFS.

RPC umożliwia konstruowanie aplikacji rozproszonych wedługmodelu klient–serwer.

Aplikacje oparte na systemie RPC najczęściej są tworzone przywykorzystaniu kompilatora protokołów, takiego jak rpcgen firmy SunMicrosystems.

Wykład 5 – p. 10/54

System Sun RPC (II)

W skład Sun RPC wchodzą:

biblioteka funkcji,

narzędzie rpcgen służące do generowania dla aplikacji koduobsługi sieci na podstawie opisu interfejsu procedur.

Parametry wywołania funkcji i zwracane wyniki przesyłane są wformacie XDR (eXternal Data Representation - zewnętrznareprezentacja danych).

Z mechanizmu Sun RPC można korzystać przy użyciu protokołutransportu TCP lub UDP.

Serwer może udostępniać 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 doserwera polecenie wykonania podprogramu wraz z argumentamiwywołania. Następnie klient przechodzi w stan oczekiwania nazakończenie wykonania podprogramu, aby odebrać zwracane przezpodprogram wyniki.

Wykład 5 – p. 12/54

Usługi RPC

Usługąw RPC nazywa się zbiór funkcji przyjmujących określoneargumenty i zwracających określone wyniki.

Deklaracje argumentów i wyników to interfejs usługi.

Z punktu widzenia programisty usługa jest identyfikowana przeznumer programu i numer wersji.

Wykład 5 – p. 13/54

Program rpcbind

rpcbind jest serwerem dokonującym konwersji numerówprogramów RPC na numer portu tzw. portmapper (port 111)

1. serwer rejestruje się u demona portmap,

2. klient żąda numeru portu serwera,

3. demon portmap odsyła klientowi numer portu serwera,

4. klient wysyła żądanie do serwera,

5. serwer wysyła odpowiedź do klienta.

Wykład 5 – p. 14/54

Pieniek klienta i pieniek serwera

W RPC stosowane są pojęcia pieńka klienta (interfejsu klienta) ipieńka serwera(interfejsu serwera).

Pieniek klienta symuluje w aplikacji klienta lokalne działanieprocedury.

Pieniek serwera czeka na żądanie nadchodzące od klienta.

Wykład 5 – p. 15/54

Specyfikacja usług RPC

W RPC odległe usługi są zorganizowane i identyfikowane wedłughierarchii

jeden serwer zawiera jeden program

jeden program ma jedną lub kilka wersji

każda z wersji zawiera jedną 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 dotyczące usług zarejestrowanych w rpcbind

Wyświetlenie wszystkich usług na wskazanym serwerze:rpcinfo -p [ host ]

Przykład:

program wer. proto port

100000 2 tcp 111 portmapper

100000 2 udp 111 portmapper

391002 2 tcp 901 sgi_fam

100024 1 udp 757 status

100024 1 tcp 760 status

Wykład 5 – p. 18/54

Program rpcgen

Program rpcgen jako wejście pobiera plik specyfikacji usług wformacie języka RPC IDL („C” z dodatkiem typów program iversion).

Zostanie wygenerowany żądany kod języka C z implementacjązdefiniowanego wywołania zdalnej procedury.

Wykład 5 – p. 19/54

Język RPC

Plik z definicją protokołu może zawierać następujące elementy:

obowiązkowa deklaracja programu serwera i przynajmniej jednejdostarczonej przez niego funkcji,

deklaracje złożonych typów danych wykorzystywanych wprotokole,

deklaracje stałych,

komentarze.

Wykład 5 – p. 20/54

Przekazywanie argumentów

Standardowo RPC dopuszcza tylko jeden argument wywołaniaodległej procedury i jeden zwracany wynik, podawane w formiewskaźników.

Jeśli występuje 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,zapewniającym ich pełną przenośność w środowiskuheterogenicznym.

Konwersja danych znajdujących się w pamięci do formatu XDR(szeregowanie) i odwrotnie (deszeregowanie) odbywa się przyuż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 wpeł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

#include

#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

Przykład - kod serwera

#include

#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 dostępny w języku Java.

W przeciwieństwie do Sun RPC jest mechanizmem w pełniobiektowym.

Nie wprowadza żadnych nowych elementów wykraczających pozasam język - językiem specyfikacji interfejsu jest sama Java.

RMI zostało włączone 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 języka Java.

Każdy interfejs zdalny musi spełniać następujące warunki:

musi rozszrzać interfejs java.rmi.Remote,

wszystkie jego metody muszą deklarować klauzulą throwsmożliwość rzucenia wyjątku java.rmi.RemoteException.

Wykład 5 – p. 29/54

Komunikacja pomiędzy klientem i serwerem

Wykład 5 – p. 30/54

rmiregistry

Do nawiązania łączności pomiędzy klientem a serwerem służyrejestr 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 jestrejestr,

port - numer portu (domyślnie 1099),

nazwa - nazwa przyjęta 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żą statyczne metody klasyjava.rmi.Naming:

lookup() - zwraca obiekt zdalny związany z podaną nazwą,

bind() - wiąże obiekt zdalny z podaną nazwą - jeśli podananazwa już występuje zwracany jest wyjątek klasyAlreadyBoundException,

rebind() - wiąże obiekt zdalny z podaną nazwą - jeśli podananazwa już występuje przypisany do niej obiekty jestzastępowany nowym,

unbind() - usuwa powiązane nazwy z obiektem zdalnym wrejestrze,

list() - zwraca listę nazw obiektów występujących w rejestrze(lista obiektów typu String).

Wykład 5 – p. 32/54

Implementacja klasy serwera

Aby metody obiektu mogły być zdalnie dostępne, musi on spełniaćdwa warunki:

implementować jakiś interfejs zdalny,

być wyeksportowany.

Eksport obiektu oznacza otwarcie odpowiedniego portu irozpoczęcie nasłuchu. Najprościej uzyskać ten efekt dziedzicząc zktórejś z podklas klasy java.rmi.server.RemoteServer, npjava.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) jeststandardem przeznaczonym do kompleksowego tworzeniaobiektowych aplikacji rozproszonych.

Specyfikacja technologii CORBA została opracowana przezkonsorcjum OMG (Object Management Group) utworzone w 1989 r.

Zajmuje się ono rozwojem, adaptacją i promowaniem standardówdla rozwijania i rozpowszechniania aplikacji heterogenicznych irozproszonych.

OMA (Object Management Architecture) - Architekturazarządzania obiektami w sieci komputerowej,

CORBA.

Skupia ponad 800 czołowych firm rozwojowych, producentówsprzętu komputerowego oraz dostawców oprogramowania a takżeużytkowników (m. in. takie firmy jak: Apple, AT&T Digital, HP, Intel,Inprise, IBM, Novell, Oracle, Software AG, Sybase, Symantec, Xeroxitd).

Wykład 5 – p. 37/54

Model komunikacji

Centralnym elementem architektury CORBA jest ORB (ObjectRequest Broker) jest odpowiedzialny za wszystkie operacje, jakie sądokonywane pomiędzy klientem a programem implementującymusługi, czyli serwerem.

Wykład 5 – p. 38/54

Zalety (I)

Otwarto ść - CORBA opiera się na opublikowanej i dostępnej dlawszystkich specyfikacji.

Uniwersalnósć - jest niezależna od sprzętu i systemu operacyjnego.Komponenty, które ze sobą współpracują mogą działać na różnycharchitekturach sprzętowych i pod kontrolą różnych systemówoperacyjnych.

Elastycznósć - obiekty CORBY posiadają ściśle zdefiniowanyinterfejs, poprzez który odbywa się komunikacja. Zmiany wimplementacji obiektu nie mają wpływu na inne obiekty, o ile niezostanie zmieniony interfejs.

Wykład 5 – p. 39/54

Zalety (II)

Przenósnósć - obiekty CORBY są przenośne. Oznacza to, żeobiekty zbudowane na jednej platformie mogą być wykorzystane nainnej platformie CORBA.

Obiektowość - budowa aplikacji odbywa się zgodnie z technikąobiektową.

Przeźroczystósć dostępu- punktu widzenia użytkownika(programisty) dostęp do obiektów zdalnych może być realizowany wtaki sam sposób, jak do lokalnych.

Przeźroczystósć położenia- jest możliwy dostęp do obiektów bezkoniecznoś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 nawzajemną lokalizację poprzez wykorzystanie ich nazw,

usługa zdarzén (event service) - umożliwia obiektom odbieraniezdarzeń,

usługa transakcji (transaction service) - definiuje regułytransakcyjności, koordynuje dwufazowe zatwierdzanie operacjipomiędzy obiektami,

usługa bezpieczénstwa (security service) - zapewnia funkcjęautentyfikacji, autoryzacji i szyfrowania. Dzięki temu możliwa jestochrona danych i kontrola dostępu 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 jegobudowy decyduje o tym, że Corba to technologia niezależna odplatformy sprzętowo–programowej.

W architekturze ORG zdefiniowano pojęcie mostu, który odpowiadaza dostęp do implementacji obiektu oraz komunikację z klientem.

Most jest odpowiedzialny za unifikację danych przekazywanych wwarstwie ORB.

Pozwala on również na tworzenie domen, które odpowiedzialne sąza poszczególne obiekty Corby (umożliwia to np. ograniczeniedostępności pewnych obiektów, do których mają dostęp tylko klienciz wybranej dziedziny.

Wykład 5 – p. 43/54

Komunikacja między domenami ORB

Za komunikację wewnątrz domeny odpowiada protokół o nazwieGIOP (The General Inter-ORB Protocol). Główne jego zadanie tozapewnienie komunikacji poszczególnym obiektom ORB.

Do komunikacji pomiędzy domenami ORB została utworzonaspecyfikacja protokołu IIOP (Internet Inter-ORB Protocol). IIOPwykorzystuje stos TCP/IP do komunikacji.

Dzięki protokołom GIOP i IIOP możliwy jest dostęp do Corby zpoziomu różnych, nawet bardzo odmiennych od siebie, językówprogramowania.

Wykład 5 – p. 44/54

Adapter obiektu

Realizacja wywołania zdalnej metody w Corbie wymaga, aby postronie serwera znajdował się mechanizm, który jest odpowiedzialnyza bezpieczeństwo tej operacji, utworzenia referencji do obiektu orazza aktywację implementacji. Taki mechanizm nazywa się adapteremobiektu.

W chwili obecnej CORBA zawiera dwa podstawowe typy adapterów:Adapter BOA (Basic Object Adapter) charakteryzuje się niskim poziomem

skomplikowania w implementacji. Jego wadą jest ograniczenie tylko do podstawowych

operacji. Z tego powodu wielu producentów serwerów Corby dodaje do niego własne

rozwiązania, co powoduje brak zgodności pomiędzy różnymi implementacjami.

Adapter POA (Portable Object Adapter) zastępuje adapter BOA i zawiera brakujące

operacje, które nie występują w adapterze BOA.

Wykład 5 – p. 45/54

Wywołanie zdalnych operacji

Dostęp do zdalnych obiektów może odbywać się w sposób statycznylub dynamiczny:

Statyczne wywołanie operacjinastępuje poprzez pieniek IDL(ang. IDL stub). Programista specyfikuje pieniek wykorzystującjęzyk IDL. Pieniek jest funkcją klienta, która pozwala statyczniewywoływać zdalne operacje poprzez wywołanie „zwykłej”lokalnej funkcji (bądź metody w przypadku języka obiektowegonp. C++).

Dynamiczne wywołanie operacji. Aplikacja może w trakciedziałania może dokonać specyfikacji usługi, która jestwymagana. Niezbędna jest przy tym informacja o interfejsie i oniezbędnych typach. Taką informację można otrzymać odprogramisty lub programowo z interfejsu repozytorium.

Wykład 5 – p. 46/54

Repozytorium Interfejsu

Repozytorium Interfejsu umożliwia uzyskanie dostępu do interfejsówobiektów, operacji jakie są przez nie udostępnione oraz parametrów itypów jakie są w nich wykorzystywane.

Można je traktować jako bazę danych zawierającą definicję obiektów.Repozytorium interfejsu zawiera te same informacje, które znajdująsię 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 zarządzania obiektami.

Używane jest również do lokalizacji i aktywacji zaimplementowanychobiektów.

Obiekt po zarejestrowaniu w Repozytorium Implementacjiuruchamiany jest automatycznie w momencie wystąpienia żądaniaod klienta.

Wykład 5 – p. 48/54

Architektura typu klient - serwerCechy architektury klient - serwerArchitektury klient - serwerSerwer bezstanowy - stanowyPodzia³ pracy klienta i serweraArchitektura trójwarstwowaWarstwy aplikacji - model MVCZdalne wywo³anie procedur - koncepcjaSystem Sun RPC (I)System Sun RPC (II)RPC - zasada dzia³aniaUs³ugi RPCProgram rpcbindPieniek klienta i pieniek serweraSpecyfikacja us³ug RPCSpecyfikacje programówPolecenie rpcinfoProgram rpcgenJêzyk RPCPrzekazywanie argumentówXDR - External Data RepresentationPrzyk³ad - plik kalkulator.xPrzyk³ad - kod klienta (I)Przyk³ad - kod klienta (II)Przyk³ad - kod serweraZdalne wywo³anie metodModel przep³ywu danychDefinicja interfejsu w RMIKomunikacja pomiêdzy klientem i serweremrmiregistryObs³uga obiektów - klasa NamingImplementacja klasy serweraPrzyk³ad - Definicja interfejsuPrzyk³ad - klasa serweraPrzyk³ad - klasa klientaStandard CORBAModel komunikacjiZalety (I)Zalety (II)Us³ugi CORBASchemat architektury aplikacji w CorbieStruktura mechanizmu ORBKomunikacja miêdzy domenami ORBAdapter obiektuWywo³anie zdalnych operacjiRepozytorium InterfejsuRepozytorium Implementacji