Obiektowe programowanie rozproszone – specyfikacja CORBA

Obiektowe programowanie rozproszone – specyfikacja CORBA

Obiektowe programowanie rozproszone – specyfikacja CORBA
Krzysztof Banaś
Systemy rozproszone
1
CORBA ➔
➔
➔
CORBA jest przykładem oprogramowania warstwy pośredniej (middleware)
Rolą takiego oprogramowania jest udostępnienie użytkownikowi lub programiście systemu rozproszonego jako jednolitego sytemu
Oprogramowanie warstwy pośredniej sytuuje się powyżej systemu operacyjnego pojedynczego zasobu (węzła) sieci, a poniżej końcowych programów użytkowych
Krzysztof Banaś
Systemy rozproszone
2
MDA
Krzysztof Banaś
Systemy rozproszone
3
CORBA ➔
➔
➔
➔
CORBA jest rozbudowanym środowiskiem mającym umożliwić tworzenie różnorodnych programów rozproszonych
Podstawowym rozszerzeniem CORBY w stosunku do modelu RPC jest oparcie na architekturze obiektowej
CORBA jest zbiorem specyfikacji opracowanych w ramach prac konsorcjum OMG (Object Management Group)
Model obliczeń CORBY jest pewną realizacją definiowanej w dokumentach OMG Architektury Zarządzania Obiektami (Object Management Architecture)
Krzysztof Banaś
Systemy rozproszone
4
OMA
Krzysztof Banaś
Systemy rozproszone
5
CORBA
Krzysztof Banaś
Systemy rozproszone
6
CORBA ➔
➔
➔
➔
Elementem Architektury Zarządzania Obiektami jest model obiektu
Z punktu widzenia CORBY obiekt jest pewnym identyfikowalnym bytem mogącym posiadać stan i mogącym świadczyć usługi Definicję usług świadczonych przez obiekty zawierają pliki zapisane w niezależnym od języka programowania języku IDL (w rzeczywistości wzorowanym i bardzo podobnym do C++)
W realizacji usług przez obiekt na rzecz klientów pośredniczy ORB (Object Request Broker – pośrednik wywołań obiektowych) – stąd nazwa CORBA (Common ORB Architecture – powszechna architektura ORB) Krzysztof Banaś
Systemy rozproszone
7
CORBA IDL
• Językiem służącym do definicji interfejsów w CORBIE jest IDL (interface definition language)
• Plik zawierający specyfikację IDL składa się z definicji następujących elementów:
– typy, stałe, wyjątki, moduły
• Definicja modułu może zawierać definicje i deklaracje:
– typów, stałych, wyjątków, interfejsów i innych modułów
• Definicja interfejsu składa się z definicji i deklaracji:
– typów, stałych, wyjątków, atrybutów i operacji
• Konkretne odwzorowania IDL do języków programowania określają jakim konstrukcjom językowym odpowiadają wymienione wyżej elementy IDL
Krzysztof Banaś
Systemy rozproszone
8
Elementy IDL ­ moduły
• Rolą modułów jest ochrona przed konfliktami powtarzających się nazw
• Moduły odpowiadają przestrzeniom nazw C++ i pakietom Javy
• Pojedynczy moduł określa zasięg nazw zdefiniowanych w ramach modułu
• Nazwy z innych zasiegów można importować za pomocą określenia import • Drugim sposobem na współdzielenie definicji jest klasyczne dołączanie plików poleceniem #include
Krzysztof Banaś
Systemy rozproszone
9
Elementy IDL ­ interfejsy
• Interfejs określa zbiór atrybutów i metod udostępnianych klientom przez zdalne obiekty
• Interfejs odpowiada klasie języków obiektowych, przy czym IDL narzuca pewne ograniczenia w stosunku do klasycznych definicji klas
• Interfejsy podlegają regułom dziedziczenia podobnym do reguł dziedziczenia między klasami
• Istnieją interfejsy standardowe oraz, stosowane w specyficznych celach i podlegające specyficznym regułom, interfejsy lokalne i abstrakcyjne
Krzysztof Banaś
Systemy rozproszone
10
Elementy IDL ­ interfejsy
• Dziedziczenie między interfejsami przebiega podobnie jak dziedziczenie między klasami (można np. dziedziczyć po interfejsach, które dziedziczą po innych interfejsach)
• Interfejs dziedziczący jest nazywany interfejsem pochodnym, interfejs, po którym dziedziczy jest interfejsem bazowym (występujący jawnie w specyfikacji dziedziczenia jest bezpośrednim interfejsem bazowym)
• IDL dopuszcza dziedziczenie wielokrotne (wielobazowe) i złożone schematy dziedziczenia
Krzysztof Banaś
Systemy rozproszone
11
Elementy IDL ­ interfejsy
• W klasie pochodnej można przedefiniowywać nazwy typów, stałych i wyjątków z klas bazowych
• Nie można przedefiniowywać nazw atrybutów i operacji
• Nie można dziedziczyć po dwóch interfejsach mających te same nazwy atrybutów lub operacji
• Użycie wszystkich nazw w interfejsach musi być jednoznaczne (np. za pomocą operatorów zasięgu ::) ­ polimorfizm nie jest dopuszczalny
Krzysztof Banaś
Systemy rozproszone
12
Elementy IDL ­ typy
• IDL dopuszcza następujące proste typy danych: short,
long, long long (+wersje unsigned powyższych), float, double, long double,
char, wchar, boolean, octet – które mają swoje odpowiedniki w językach programowania oraz typ any, który może oznaczać dowolny typ (konkretyzowany w trakcie wykonania)
• Prócz tego IDL dopuszcza typy złożone, takie jak: struct, union, enum
Krzysztof Banaś
Systemy rozproszone
13
Elementy IDL ­ typy
• Odpowiednikiem klasycznych tablic z języków rodziny C są typy szablonowe, takie jak: sequence, string,
wstring
• W definicji powyższych typów można podać rozmiar tablicy lub uzyskać zmienną, której rozmiar określi konkretna implementacja • Prócz tego istnieją typy fixed, native i tablice o stałym rozmiarze ( np. float tab[10])
• Wszelkie definicje rekurencyjne struktur należy realizować za pomocą deklaracji wyprzedzających i deklaracji typedef z użyciem typu sequence
Krzysztof Banaś
Systemy rozproszone
14
Elementy IDL ­ operacje
• Definicje operacji w IDL mają składnię podobną do definicji funkcji w C
• Definicja może być poprzedzona słowem oneway, oznaczającym asynchroniczną realizację operacji
• W definicji można określić jakie wyjątki (poza standardowymi wyjątkami CORBY) zgłasza operacja
• Dodatkowo definicja może zawierać wskazanie elementów kontekstu żądania mających znaczenie dla implementacji operacji
Krzysztof Banaś
Systemy rozproszone
15
Elementy IDL – parametry (argumenty) procedur
• Parametry definiowane są podobnie jak w C
• Elementem dodatkowym jest określenie atrybutu każdego z parametrów mówiącego czy parametr jest:
– daną wyłącznie wejściową, przesyłaną od klienta do serwera – in – daną wyłącznie wyjściową przesyłaną od serwera do klienta – out – daną wejściową i wyjściową, przesyłaną w obie strony – inout
Krzysztof Banaś
Systemy rozproszone
16
IDL – semantyka wywołania
• Standardowe wywołania operacji CORBY realizują semantykę:
– co­najmniej­raz jeśli zgłaszany jest wyjątek
– dokładnie­raz jeśli operacja kończy się sukcesem
• Operacje z atrybutem oneway mają cechy specyficzne:
–
–
–
–
realizują semantykę co­najwyżej­raz
ich argumenty muszą mieć atrybut in
deklarowanym typem wyniku musi być void
deklaracja operacji nie może zawierać wyrażenia raises
Krzysztof Banaś
Systemy rozproszone
17
Elementy IDL ­ wyjątki
• Wyjątki powiązane są z operacjami poprzez określenie raises
• Wyjątki są zwracane w sytuacji niemożliwości poprawnego zakończenia realizacji operacji
• Poza wyjątkami definiowanymi przez użytkownika istnieje zbiór standardowych wyjątków CORBY, które mogą być zgłaszane przez dowolne operacje
• W takim przypadku wartości zwracanych argumentów i wyniku są nieokreślone
• Wyjątki posiadają budowę zbliżoną do struktur
• Klient może badać wartość zwróconego wyjątku, a jesli został on zadeklarowany jako struktura, także jego zawartość Krzysztof Banaś
Systemy rozproszone
18
Elementy IDL ­ atrybuty
• Atrybuty są elementami interfejsu, które mogą być pobierane i ustalane
• Deklaracja atrybutu (np. attribute float dana) jest równoważna deklaracji dwóch funkcji – akcesora (np. float _get_dana() ) i mutatora (np. void
_set_dana(in float d) ) • Deklarację można poprzedzić słowem readonly co oznacza istnienie tylko akcesora
• Akcesory i mutatory mogą zgłaszać własne wyjątki wskazywane przez wyrażenia setraises i getraises w deklaracji atrybutu Krzysztof Banaś
Systemy rozproszone
19
IDL ­ przykład
module moj_bank {
};
interface Rachunek {
exception Pusty{};
void wplata( in long kwota );
void wyplata( in long kwota );
long stan();
};
interface ROR : Rachunek {
attribute long limit;
};
Krzysztof Banaś
Systemy rozproszone
20
CORBA ­ przykład
class Rachunek_impl : virtual public POA_moj_bank::Rachunek
{
public:
Rachunek_impl ();
void wplata( CORBA::Long kwota ) throw(::CORBA::SystemException);
void wyplata( CORBA::Long kwota ) throw(::CORBA::SystemException);
CORBA::Long stan() throw(::CORBA::SystemException);
private:
CORBA::Long _stan;
};
class ROR_impl : virtual public Rachunek_impl, virtual public POA_moj_bank::ROR
{
public:
CORBA::Long limit();
void limit( CORBA::Long _new_value );
};
Krzysztof Banaś
Systemy rozproszone
21
CORBA ORB
• Podstawowym elementem wykorzystywanym w ramach
specyfikacji CORBA przy zdalnym wywoływaniu metod
obiektów jest ORB – pośrednik wywołań obiektowych (object
request broker)
• Za pomocą ORB lokalizowane są obiekty i realizowane
wywołania ich metod
• Procedury realizowane przez ORB należą do modułu CORBA i
przy wywoływaniu muszą być poprzedzone określeniem zasięgu
CORBA::
Krzysztof Banaś
Systemy rozproszone
22
CORBA ORB
• Procedury ORB związane są z następującymi działaniami i usługami:
– uzyskiwanie referencji do podstawowych obiektów (realizujących podstawowe usługi)
– manipulowanie referencjami do obiektów
– przekazywanie informacji o usługach
– obsługa interfejsu wywołań dynamicznych (Dynamic Invocation)
– zarządzanie wątkami
– tworzenie strategii
– inne
Krzysztof Banaś
Systemy rozproszone
23
CORBA Object
• Implementacja każdego interfejsu CORBY dziedziczy po interfejsie Object
• Ten podstawowy interfejs definiuje operacje, które można dokonać na dowolnym obiekcie implementującym interfejs w ramach CORBY
• Operacje te realizowane są przez ORB i programista nie dostarcza ich implementacji
Krzysztof Banaś
Systemy rozproszone
24
CORBA Object
• Do operacji z interfejsu Object należą m.in.:
– Object duplicate(); ­ powielenie referencji do obiektu
– void release(); ­ usunięcie referencji do obiektu (obie operacje są lokalnie realizowane przez ORB)
– boolean is_nil(); ­ sprawdzenie czy referencja nie jest pusta
– boolean is_equivalent( in Object
other_object ); ­ sprawdzenie czy dwie referencje odnoszą się do tego samego obiektu
– inne (np. związane ze strategiami zarządzania obiektami)
Krzysztof Banaś
Systemy rozproszone
25
CORBA ORB
• Zainicjowanie środowiska CORBY jest czynnością, którą musi wykonać dowolny program klienta i serwera, chcący uzyskać dostęp do usług oferowanych przez ORB
• Procedura inicjacji jest zdefiniowana w module CORBA:
module CORBA{
typedef sequence<string> arg_list;
ORB ORB_init( inout arg_list argv,
in ORBid orb_id );
}
• Procedura zwraca referencję do pseudo-obiektu ORB
• Argumenty mogą pochodzić z linii polecenia, mogą też być
pustymi napisami (zwracana jest wtedy wartość domyślna)
Krzysztof Banaś
Systemy rozproszone
26
CORBA ORB
• Kolejnym koniecznym krokiem programu jest uzyskanie referencji do obiektów (egzemplarzy) świadczących usługi
• Do uzyskania referencji do podstawowych obiektów stosuje się procedurę (z interfejsu ORB):
Object resolve_initial_references(
in ObjectId identifier
) raises ( InvalidName );
• Zwracanym typem jest Object, który następnie rzutowany jest na konkretny typ pochodny za pomocą procedury narrow należącej do interfejsu konkretnego obiektu
• Listę podstawowych obiektów, dla których można uzyskać odniesienia za pomocą powyższej procedury zwraca inna procedura: list_initial_services
Krzysztof Banaś
Systemy rozproszone
27
Operacje ORB
• dwie operacje użyteczne w przypadku gdy serwer przekazuje klientom informacje o obiekcie w postaci łańcucha znaków (napisu) lub gdy odniesienie do obiektu ma być przechowane w sposób trwały
• przekształcanie referencji w napis (dokonywane przez serwer)
string object_to_string( in Object obj );
• przekształcanie napisu w referencję (dokonywane przez klienta)
Object string_to_object( in string str );
Krzysztof Banaś
Systemy rozproszone
28
CORBA – program klienta
#include "ror.h"
using namespace std; using namespace moj_bank;
int main (int argc, char *argv[]) {
CORBA::ORB_var orb = CORBA::ORB_init (argc, argv);
char pwd[256], uri[300];
sprintf (uri, "file://%s/ROR.ref", getcwd(pwd, 256));
CORBA::Object_var obj = orb­>string_to_object (uri);
ROR_var moj_ror = ROR::_narrow (obj);
moj_ror­>wplata(100);
printf("Stan po wplacie 100: %d\n",moj_ror­>stan());
moj_ror­>wyplata(50);
printf("Stan po wyplacie 50: %d\n",moj_ror­>stan());
exit(0);
}
Krzysztof Banaś
Systemy rozproszone
29
Sterowanie zdarzeniami
• Typowym elementem działania serwerów jest praca w nieskończonej pętli, w której nasłuchuje się żądań klientów i kolejno je realizuje
• CORBA umożliwia powyższy sposób funkcjonowania, tak w wersji jednowątkowej, jak i wielowątkowej
• W wersji jednowątkowej można realizować pętlę:
for(;;){ if(orb->work_pending() ){
orb->perform_work(); }else{ //coś innego } }
• Wywołanie orb->run powoduje przekazanie sterowania do
ORB, który następnie przejmuje zadanie wywoływania metod
obiektów – to wywołanie może być realizowane przez wiele
współbieżnych wątków
Krzysztof Banaś
Systemy rozproszone
30
Sterowanie zdarzeniami
• Programy mogą także kończyć pracę ORB
• Procedura (z interfejsu ORB)
void shutdown( in boolean wait_for_completion );
powoduje przerwanie obsługiwania żądań przez ORB
• Procedura void destroy();
zamyka ORB i niszczy wszelkie jego zasoby (jeśli nie zostało to zrobionone jawnie, wykonuje także operację shutdown z argumentem TRUE )
Krzysztof Banaś
Systemy rozproszone
31
Adaptery obiektów ➔
➔
➔
Aby zapewnić prawidłowe funkcjonowanie obiektu w systemie rozproszonym CORBA wprowadza warstwę pośrednią pomiędzy implementację obiektu (łącznie ze szkieletem) a ORB – tą warstwą pośrednią jest adapter obiektu
Istnieją dwa typy adapterów obiektów w standardzie CORBA – BOA: basic object adapter (obecnie niezalecany ze względu na zbytnie uproszczenia) i POA: portable object adapter
Jednym z zadań adapterów obiektów jest umożliwienie istnienia pojedynczego ORB dla różnych języków programowania
Krzysztof Banaś
Systemy rozproszone
32
Adaptery obiektów ➔
➔
➔
Adapter obiektu dostarcza klas (w programach napisanych w językach obiektowych), po których mogą dziedziczyć klasy dostarczające implementację dla obiektów
Adapter obiektu gwarantuje poprawne w ramach danego języka programowania (i specyfiki charakteru obiektu) tworzenie, niszczenie i wywoływanie metod obiektu
Specyfikacja dopuszcza tworzenie innych, poza standardowymi, adapterów obiektów przeznaczonych do specjalnych celów (np. obsługi obiektów związanych z bazami danych)
Krzysztof Banaś
Systemy rozproszone
33
CORBA ­ przykład
#include "ror_impl.h"
int main (int argc, char *argv[]) {
CORBA::ORB_var orb = CORBA::ORB_init (argc, argv);
CORBA::Object_var poaobj = orb­>resolve_initial_references ("RootPOA");
PortableServer::POA_var poa = PortableServer::POA::_narrow (poaobj);
PortableServer::POAManager_var mgr = poa­>the_POAManager();
ROR_impl * moj_ror = new ROR_impl;
PortableServer::ObjectId_var oid = poa­>activate_object (moj_ror);
ofstream of ("ROR.ref");
CORBA::Object_var ref = poa­>id_to_reference (oid.in());
CORBA::String_var str = orb­>object_to_string (ref.in());
of << str.in() << endl; of.close ();
cout << "Running." << endl;
mgr­>activate ();
orb­>run();
poa­>destroy (TRUE, TRUE); delete moj_ror;
}
Krzysztof Banaś
Systemy rozproszone
34
CORBA ­ przykład
class Rachunek_impl : virtual public POA_moj_bank::Rachunek
{
public:
Rachunek_impl ();
void wplata( CORBA::Long kwota ) throw(::CORBA::SystemException);
void wyplata( CORBA::Long kwota ) throw(::CORBA::SystemException);
CORBA::Long stan() throw(::CORBA::SystemException);
private:
CORBA::Long _stan;
};
class ROR_impl : virtual public Rachunek_impl, virtual public POA_moj_bank::ROR
{
public:
CORBA::Long limit();
void limit( CORBA::Long _new_value );
};
Krzysztof Banaś
Systemy rozproszone
35
Tworzenie aplikacji CORBY
➔
➔
Podobnie jak w systemie RPC odpowiednie kompilatory tworzą na podstawie definicji w IDL namiastki po stronie klienta, namiastki (zwane szkieletami) po stronie serwera oraz ułatwiają napisanie obiektowego kodu wykorzystującego interfejs (klient) i implementującego interfejs (serwer)
Kompilatory konkretnych języków programowania tworzą ostateczne aplikacje
Krzysztof Banaś
Systemy rozproszone
36
CORBA ­ przykład
void Rachunek_impl::wplata( CORBA::Long kwota ) throw(::CORBA::SystemException)
{
_stan += kwota;
}
void Rachunek_impl::wyplata( CORBA::Long kwota ) throw(::CORBA::SystemException)
{
_stan ­= kwota;
}
CORBA::Long Rachunek_impl::stan() throw(::CORBA::SystemException)
{
return _stan; }
Krzysztof Banaś
Systemy rozproszone
37
Środowisko CORBY ➔
➔
➔
Funkcjonowanie obiektów w programach jest znacznie bardziej złożone niż funkcjonowanie procedur

obiekty posiadają stan

obiekty mogą być współdzielone przez różnych klientów
Specyfikacje OMG dążą do uczynienia z CORBY wszechstronnego modelu dla wielu dziedzin zastosowań
Specyfikacje związane z CORBĄ definiują wiele usług, które mogą być świadczone przez środowiska CORBY, w celu ułatwienia złożonego zarządzania obiektami w rozmaitych aplikacjach
Krzysztof Banaś
Systemy rozproszone
38
Usługi CORBY
➔
Do podstawowych usług CORBY należą (miedzy innymi):







usługi nazewnicze (Naming Service) – wyszukiwanie serwerów za pomocą nazw
usługi cyklu życia obiektu (Life Cycle Service) – tworzenie, przenoszenie, niszczenie obiektów itp.
usługi zdarzeń (Event Service) – umożliwienie asynchronicznej komunikacji między obiektami
usługi obiektów trwałych (Persistent Object Service) – mechanizmy trwałego zapisu stanu obiektów
usługi bezpieczeństwa (Security Service) – zarządzanie dostępem do usług i szyfrowaniem przesyłanych danych
usługi transakcji (Transaction Service) – funkcjonowanie obiektów w środowisku realizacji transakcji
usługi wymiany obiektów (Trading Service) – wyszukiwanie obiektów świadczących określone usługi Krzysztof Banaś
Systemy rozproszone
39
Implementacje CORBY ➔
➔
➔
CORBA jest standardem, który umożliwia różne implementacje
CORBA definiuje także sposób porozumiewania się pomiędzy różnymi implementacjami ORB, tak aby mogło dochodzić do interakcji między obiektami funkcjonującymi w ramach różnych implementacji
Standardem porozumiewania się jest tzw. protokół InterORB: w wersji ogólnej GIOP i wersji internetowej IIOP
Krzysztof Banaś
Systemy rozproszone
40
Internetowe programowanie rozproszone – SOA, WebServices i systemy gridowe
Krzysztof Banaś
Systemy rozproszone
41
Technologie WWW
➔
Technologie często w praktyce korzystające z protokołów internetowych:



architektura usługowa (Service Oriented Architecture ­ SOA) – sposób organizacji systemów rozproszonych, w którym rozważa się każdy system poprzez pryzmat świadczonych przez niego usług
Web Services – technologia przetwarzania rozproszonego oparta o technologie WWW
systemy gridowe – systemy, w których rozproszone zasoby udostępniane są w sposób niezależny od fizycznej realizacji
Krzysztof Banaś
Systemy rozproszone
42
SOA – Service Oriented Architecture
➔
Termin “Service Oriented Architecture” jest określeniem architektury systemów rozproszonych, w których wyróżnia się:



➔
➔
usługobiorcę – klienta korzystającego z usług
dostawcę usług – usługą jest realizacja pewnego przetwarzania z wykorzystaniem dostarczonych danych
rejestr usług – miejsce, gdzie klient uzyskuje informacje o potrzebnych mu usługach
Podstawą SOA jest wykorzystanie przesyłania komunikatów do wymiany informacji między uczestnikami przetwarzania
Architektury usługowe odróżnia się od architektur obiektowych i architektur komponentowych
Krzysztof Banaś
Systemy rozproszone
43
SOA – Service Oriented Architecture
➔
➔
Dostarczając usługę w ramach architektury usługowej należy w ogólnie znanym i dostępnym rejestrze dokonać zgłoszenia:

miejsca dostępności usługi

sposobu korzystania z usługi
Klient chcący korzystać z określonej usługi:

wyszukuje w ogólnie znanych i dostępnych rejestrach opisy świadczonych usług

wybiera najbardziej mu odpowiadającą

kontaktuje się z serwerem usługi w celu realizacji przetwarzania Krzysztof Banaś
Systemy rozproszone
44
SOA – Service Oriented Architecture
➔
➔
➔
Sposób korzystania z usługi jest równoważny interfejsowi oprogramowania realizującego usługę
Interfejs taki powinien być napisany w sposób niezależny od:

języka programowania

systemu operacyjnego

sprzętu realizującego obliczenia
Sposób powiązania usługodawcy z usługobiorcą za pomocą tak określonych interfejsów określa się jako luźny (loosely coupled)
Krzysztof Banaś
Systemy rozproszone
45
SOA – Service Oriented Architecture
➔
➔
➔
Usługi zgłoszone w systemach SOA mogą być jednocześnie klientami innych usług
W ten sposób można tworzyć złożone schematy przetwarzania (workflows) składające się z wielu, odpowiednio zorganizowanych usług
Architektura usługowa (SOA) jest w tym ujęciu przeciwstawiona architekturze komponentowej (CBD)



ten sam cel ­ ponowne wykorzystanie oprogramowania
SOA ­ realizacja za pomocą organizacji usług sieciowych
CBD ­ lokalne komponowanie dostarczonych fragmentów oprogramowania Krzysztof Banaś
Systemy rozproszone
46
Web Services (usługi internetowe)
➔
➔
➔
Nazwą Web Services określa się dziś jedną z możliwych realizacji modelu SOA, umożliwiającą wykorzystanie istniejącej infrastruktury internetowej (protokół HTTP, przeglądarki)
Web Services oznaczają oprogramowanie dostępne poprzez sieć zbudowane zgodnie z określonymi standardami
Organizacjami rozwijającymi standardy Web Services są między innymi:


W3C – World Wide Web Consortium
OASIS ­ Organization for the Advancement of Structured Information Standards
Krzysztof Banaś
Systemy rozproszone
47
Web Services (usługi internetowe)
➔
Web Services wykorzystują następujące specyfikacje, aby przystosować przetwarzanie rozproszone do standardowego środowiska internetowego:



XML – język, który może być przetwarzany przez maszyny
SOAP – protokół przesyłu danych wykorzystujący XML
WSDL – język opisu usług wykorzystujący XML
Krzysztof Banaś
Systemy rozproszone
48
WebServices
Krzysztof Banaś
Systemy rozproszone
49
XML
➔
➔
➔
XML (eXtensible Markup Language)– główną cechą języka XML jest możliwość rozszerzania go o nowe konstrukcje, dzięki czemu może służyć do opisu coraz to innych dziedzin
W ramach konkretnych dziedzin, w których stosuje sie XML wypracowywane są standardy opisu dziedziny za pomocą XML i na ich podstawie programy przetwarzające teksty w XML
Sam standard definiujący XML nie jest rozbudowany, natomiast istnieje już wiele rozległych standardów wykorzystania XML w konkretnych dziedzinach
Krzysztof Banaś
Systemy rozproszone
50
SOAP
➔
➔
➔
➔
SOAP jest standardem wymiany komunikatów zapisanych w XML Komunikaty SOAP można wymieniać za pomocą różnych środków transmisji, choć najpopularniejszymi i preferowanymi są protokoły HTTP lub HTTPS
SOAP został zaprojektowany ze szczególnym uwzględnieniem wymiany komunikatów w ramach zdalnego wywołania procedur
W ramach środowisk programowania istnieją narzędzia, które projektują postać komunikatów SOAP dla konkretnych wywołań procedur zdalnych
Krzysztof Banaś
Systemy rozproszone
51
SOAP ­ żądanie
POST /webservices/tempconvert.asmx HTTP/1.1
Host: www.w3schools.com
Content-Type: application/soap+xml; charset=utf-8
Content-Length: length
<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
<soap12:Body>
<FahrenheitToCelsius xmlns="http://tempuri.org/">
<Fahrenheit>string</Fahrenheit>
</FahrenheitToCelsius>
</soap12:Body>
</soap12:Envelope>
Krzysztof Banaś
Systemy rozproszone
52
SOAP ­ odpowiedź
HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: length
<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
<soap12:Body>
<FahrenheitToCelsiusResponse xmlns="http://tempuri.org/">
<FahrenheitToCelsiusResult>string</FahrenheitToCelsiusResult>
</FahrenheitToCelsiusResponse>
</soap12:Body>
</soap12:Envelope>
Krzysztof Banaś
Systemy rozproszone
53
WSDL
➔
WSDL jest językiem opisu usług sieciowych podobnym w funkcji do IDL CORBY
➔
WSDL nie posługuje się modelem obiektowym
➔
WSDL zapisywany jest w XML
➔
➔
W przeciwieństwie do IDL opis interfejsu usługi w WSDL zazwyczaj nie jest tworzony przez programistę, ale przez środowisko programowania rozproszonego
Opis w WSDL zawiera informację o formie wymiany komunikatów przy wywoływaniu zdalnych procedur
Krzysztof Banaś
Systemy rozproszone
54
WSDL
➔
Dokument WSDL (napisany w XML) zawiera następujące elementy:





<interface> ­ odpowiednik interfejsu IDL lub definicji klasy abstrakcyjnej w obiektowych językach programowania; element <interface> zawiera elementy <operation> opisujące pojedyncze procedury
<message> ­ opisuje wymianę komunikatów związaną z wywołaniem procedury (argumenty wejścia i wyjścia)
<types> ­ typy danych użytych jako argumenty
<binding> ­ sposób realizacji wywołania, użyty protokół, itp.
<service> ­ połączenie interfejsu, sposobu realizacji wywołania i adresu internetowego dla uzyskania ostatecznej definicji usługi
Krzysztof Banaś
Systemy rozproszone
55
WSDL – opis prostej funkcji
<definitions targetNamespace="http://endpoint.helloservice/" name="HelloService">
<types>
<xsd:schema>
<xsd:import namespace="http://endpoint.helloservice/" schemaLocation="http://localhost:8080/helloservice/hello?xsd=1"/>
</xsd:schema>
</types>
<message name="sayHello">
<part name="parameters" element="tns:sayHello"/>
</message>
<message name="sayHelloResponse">
<part name="parameters" element="tns:sayHelloResponse"/>
</message>
<portType name="Hello">
<operation name="sayHello">
<input message="tns:sayHello"/>
<output message="tns:sayHelloResponse"/>
</operation>
</portType>
Krzysztof Banaś
Systemy rozproszone
56
WSDL – opis prostej funkcji
<binding name="HelloPortBinding" type="tns:Hello">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/>
<operation name="sayHello">
<soap:operation soapAction=""/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
<service name="HelloService">
<port name="HelloPort" binding="tns:HelloPortBinding">
<soap:address location="http://localhost:8080/helloservice/hello"/>
</port>
</service>
</definitions>
Krzysztof Banaś
Systemy rozproszone
57
Web Services i CORBA
➔
➔
➔
Web Services realizują podobny model przetwarzania rozproszonego jak CORBA
Zaletą Web Services jest korzystanie z technologii WWW (HTTP), posiadających m.in. rozwinięte mechanizmy zabezpieczeń (HTTPS)
Web Services nie dorównują (jeszcze...) systemom CORBY w dziedzinach:


➔
wsparcia modelu obiektowego
bogactwa dodatkowych usług związanych z przetwarzaniem
Systemy CORBY mogą stać się dostawcami usług Web Services, istnieje standard przekładu języka IDL na WSDL
Krzysztof Banaś
Systemy rozproszone
58
Porównanie technologii
Technology
Connect
time
Send string
(21,000
characters)
Receive
string
(22,000
characters)
Send 5,000
integers
Client
LOC
●(lines
of
●code)
Server
LOC
Actual
message
size
sending
1,000
characters
Actual
message
size
sending
100
integers
Raw sockets
0.002242
0.001377
0.001359
6.740674
57
25
2,279
85,863
CORBA
0.000734
0.004601
0.002188
1.523799
37
18
2,090
27,181
XML-RPC
0.007040
0.082755
0.050199
100.337219
29
17
4,026
324,989
SOAP
0.000610
0.294198
0.279341
1,324.296742
32
10
4,705
380,288
źródło: http://www.ibm.com/developerworks/webservices/library/ws-pyth9/
Krzysztof Banaś
Systemy rozproszone
59
Systemy gridowe
➔
➔
➔
Nazwa systemów gridowych wywodzi się od nazwy sieci elektroenergetycznej w USA – Power Grid i od idei korzystania z zasobów obliczeniowych podobnie jak z zasobów energii elektrycznej
W wizji tej pojedynczy użytkownik po podłączeniu do sieci (i uiszczeniu odpowiednich opłat) uzyskuje dostęp do mnogości usług w jednolity sposób i niezależnie od konkretnego sposobu implementacji tych usług oraz stosowanego sprzętu
Idea systemów gridowych narodziła się w środowiskach naukowych i wspierana jest przez koncepcję e­Nauki
Krzysztof Banaś
Systemy rozproszone
60
Wizja E-nauki
2100
2100
2100
2100
2100
2100
2100
2100
Współpraca
Przechowanie danych
Laboratoria i instrumenty
Obliczenia
Krzysztof Banaś
E-naukowiec
Systemy rozproszone
Wizualizacja
61
Systemy gridowe (Grids)
➔
➔
➔
➔
Początkowo systemy gridowe rozwijane były w ramach programów badawczych ukierunkowanych na zastosowania naukowe (projekty Condor, Globus)
Z czasem idee systemów gridowych i stosowane narzędzia zaczęły przenikać się z ich odpowiednikami w obszarze zastosowań biznesowych czy popularnych
Specyfikacje systemów gridowych opracowywane są przez organizacje (głównie grupy robocze GGF – Global Grid Forum) w postaci rekomendacji
Rekomendacje GGF ukierunkowane są na wszystkie obszary zastosowań
Krzysztof Banaś
Systemy rozproszone
62
Systemy gridowe (Grids)
➔
➔
➔
W systemach gridowych rozważa się dostęp do zasobów i ich wykorzystanie poprzez pewien jednolity system
Jednolitość systemu ma być zapewniona poprzez wirtualizację zasobów, tzn. każdy zasób jest przedstawiany jako pewien możliwy do zrealizowania zestaw usług
Ze względu na oparcie systemów gridowych na usługach ostatnie specyfikacje GGF wskazują na Web Services jako podstawę realizacji
Krzysztof Banaś
Systemy rozproszone
63
Systemy gridowe (Grids)
➔
➔
Zasoby informatyczne tworzące systemy gridowe są ze swej natury heterogeniczne i rozproszone
Stanowią je:


➔
urządzenia (procesory, dyski, drukarki, urządzenia pomiarowe, wyposażenie laboratoriów, urządzenia sieciowe, itp.)
programy, bazy danych, pliki
Ideą jest tworzenie systemów gridowych i współdzielenie zasobów przez różne podmioty, geograficznie rozproszone, tworzące tzw. wirtualne organizacje (VO)
Krzysztof Banaś
Systemy rozproszone
64
Systemy gridowe (Grids)
➔
Jednymi z podstawowych zadań jakie muszą zostać rozwiązane w ramach systemów gridowych są:


bezpieczeństwo – m.in. jak połączyć bezpieczne korzystanie z rozproszonych zasobów z ideą traktowania systemu gridowego jako jednolitej całości (a więc np. z tylko jednym logowaniem do całego systemu)
wydajność – jak zagwarantować maksymalna wydajność całości systemu rozproszonego, m.in. jak równoważyć obciążenie całości systemu (może to wymagać migracji zadań pomiędzy poszczególnymi zasobami)
Krzysztof Banaś
Systemy rozproszone
65
Systemy gridowe (Grids)
➔
➔
➔
Systemy gridowe poprzez oparcie na usługach mogą być organizowane zgodnie z typowym standardem SOA (usługobiorca, usługodawca, rejestr)
Wartością dodaną związaną z systemami gridowymi jest rozbudowana warstwa usług związanych z zarządzaniem zasobami
Systemy gridowe mogą także udostępniać swoje usługi na zewnątrz w ramach szerszego systemu zorganizowanego zgodnie z zasadami SOA
Krzysztof Banaś
Systemy rozproszone
66
Systemy gridowe (Grids)
➔
➔
➔
Systemy gridowe z założenia mają być budowane w oparciu o standardy
Liczba tych standardów ciągle rośnie, wraz z rozszerzaniem obszarów stosowania systemów gridowych
Podstawowym standardem GGF jest OGSA (Open Grid Software Architecture) – specyfikacja określająca ogólna budowę systemów gridowych
Krzysztof Banaś
Systemy rozproszone
67
Systemy gridowe (Grids)
➔
➔
➔
Systemy gridowe mają swoje realizacje publicznie dostępne w ramach otwartego oprogramowania (wciąż podstawową jest Globus Toolkit, obecnie w wersji 4)
Wielu producentów sprzętu (Sun, IBM, HP i inni) oraz oprogramowania (Sun, Oracle, Microsoft) dostarcza także swoje komercyjne wersje systemów gridowych (często będące rozwinięciami lub modyfikacjami systemów publicznie dostępnych)
Twórcy oprogramowania dostarczają także platformy i środowiska do tworzenia oprogramowania gridowego Krzysztof Banaś
Systemy rozproszone
68
Globus Toolkit version 4
Krzysztof Banaś
Systemy rozproszone
69