Obiektowe programowanie rozproszone specyfikacja CORBA. Krzysztof Banaś Systemy rozproszone 1

Transkrypt

1 Obiektowe programowanie rozproszone specyfikacja CORBA Krzysztof Banaś Systemy rozproszone 1

2 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

3 MDA Krzysztof Banaś Systemy rozproszone 3

4 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

5 OMA Krzysztof Banaś Systemy rozproszone 5

6 CORBA Krzysztof Banaś Systemy rozproszone 6

7 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

8 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

9 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

10 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

11 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

12 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

13 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

14 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

15 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

16 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

17 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

18 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

19 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

20 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

21 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

22 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

23 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

24 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

25 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

26 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

27 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

28 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

29 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

30 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

31 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

32 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

33 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

34 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

35 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

36 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

37 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

38 Ś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

39 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

40 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

41 Internetowe programowanie rozproszone SOA, WebServices i systemy gridowe Krzysztof Banaś Systemy rozproszone 41

42 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

43 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

44 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

45 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

46 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

47 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

48 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

49 WebServices Krzysztof Banaś Systemy rozproszone 49

50 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

51 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

52 SOAP żądanie POST /webservices/tempconvert.asmx HTTP/1.1 Host: Content-Type: application/soap+xml; charset=utf-8 Content-Length: length <?xml version="1.0" encoding="utf-8"?> <soap12:envelope xmlns:xsi=" xmlns:xsd=" xmlns:soap12=" <soap12:body> <FahrenheitToCelsius xmlns=" <Fahrenheit>string</Fahrenheit> </FahrenheitToCelsius> </soap12:body> </soap12:envelope> Krzysztof Banaś Systemy rozproszone 52

53 SOAP odpowiedź HTTP/ OK Content-Type: application/soap+xml; charset=utf-8 Content-Length: length <?xml version="1.0" encoding="utf-8"?> <soap12:envelope xmlns:xsi=" xmlns:xsd=" xmlns:soap12=" <soap12:body> <FahrenheitToCelsiusResponse xmlns=" <FahrenheitToCelsiusResult>string</FahrenheitToCelsiusResult> </FahrenheitToCelsiusResponse> </soap12:body> </soap12:envelope> Krzysztof Banaś Systemy rozproszone 53

54 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

55 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

56 WSDL opis prostej funkcji <definitions targetnamespace=" name="helloservice"> <types> <xsd:schema> <xsd:import namespace=" schemalocation=" </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

57 WSDL opis prostej funkcji <binding name="helloportbinding" type="tns:hello"> <soap:binding transport=" 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=" </port> </service> </definitions> Krzysztof Banaś Systemy rozproszone 57

58 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

59 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 ,279 85,863 CORBA ,090 27,181 XML-RPC , ,989 SOAP , , ,288 źródło: Krzysztof Banaś Systemy rozproszone 59

60 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

61 Wizja E-nauki Współpraca Laboratoria i instrumenty Przechowanie danych Obliczenia E-naukowiec Wizualizacja Krzysztof Banaś Systemy rozproszone 61

62 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

63 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

64 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

65 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

66 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

67 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

68 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

69 Globus Toolkit version 4 Krzysztof Banaś Systemy rozproszone 69