Standard CORBA. Oprogramowanie systemów równoległych i rozproszonych Wykład 8. Zalety (I) Model komunikacji. Dr inż. Tomasz Olas

Transkrypt

1 Standard CORBA Oprogramowanie systemów równoległych i rozproszonych Wykład 8 Dr inż. Tomasz Olas olas@icis.pcz.pl Instytut Informatyki Teoretycznej i Stosowanej Politechnika Częstochowska 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 się ono rozwojem, adaptacja i promowaniem standardów dla rozwijania i rozpowszechniania aplikacji heterogenicznych i rozproszonych. Skupia ponad 800 czołowych firm rozwojowych, producentów sprzętu 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). Model komunikacji 1/47 Zalety (I) Wykład 8 p Centralnym elementem architektury CORBA jest ORB (Object Request Broker) jest odpowiedzialny za wszystkie operacje, jakie sa dokonywane pomiędzy klientem a programem implementujacym usługi, czyli serwerem. 3/47 Otwartość. Architektura CORBA jest otwartym rozwiazaniem opartym na opublikowanej specyfikacji. Uniwersalność. Jest niezależna od sprzętu i systemu operacyjnego. Współdziałajace komponenty moga działać na różnych architekturach sprzętowych i pod kontrola różnych systemów operacyjnych. (Jest zaimplementowana i obsługiwana na wielu różnych systemach operacyjnych). Elastyczność. Obiekt programowy zgodny z architektura CORBA posiada ściśle zdefiniowany interfejs, poprzez który odbywa się komunikacja. Zmiany w implementacji obiektu nie maja wpływu na inne obiekty, o ile nie zostanie zmieniony interfejs. Współpraca. Komunikacja pomiędzy obiektami programowymi zgodnymi z CORBA odbywa się przy wykorzystaniu protokołu IIOP. Obiekty programowe moga ze soba w pełni współpracować, nawet jeżeli działaja na różnych systemach operacyjnych i zostały utworzone z wykorzystaniem różnych języków programowania. Wykład 8 p

2 Zalety (II) Usługi CORBA Przenośność. Obiekty programowe zgodne ze standardem CORBA sa przenośne. To znaczy, że obiekty zbudowane na jednej platformie moga być wykorzystane na każdej innej z obsługiwanych platform. Obiektowość. Budowa aplikacji odbywa się zgodnie z zasadami techniki obiektowej. Przeźroczystość dostępu. Z punktu widzenia użytkownika (programisty) nie ma różnicy pomiędzy dostępem do lokalnych i zdalnych obiektów. Przeźroczystość położenia. Jest możliwy dostęp do obiektów bez konieczności określania ich położenia. usługa nazewnictwa (naming service) umożliwia obiektom wzajemna lokalizację przy wykorzystaniu ich nazw, usługa zdarzeń (event service) pozwala obiektom być subskrybentem kanału zdarzeń dzięki czemu moga oni być powiadamiani o wystapieniu określonych zdarzeń, usługa transakcji (transaction service) definiuje reguły transakcyjności, koordynuje dwufazowe zatwierdzanie operacji pomiędzy obiektami, usługa bezpieczeństwa (security service) zapewnia funkcję autentyfikacji, autoryzacji i szyfrowania. Służa one do ochrony danych i kontroli dostępu użytkowników do aplikacji i usług. 5/47 Wykład 8 p Schemat architektury aplikacji w Corbie 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ętowo programowej. W architekturze ORG zdefiniowano pojęcie mostu, który odpowiada za dostęp do implementacji obiektu oraz komunikację z klientem. Most jest odpowiedzialny za unifikację 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 dostępności pewnych obiektów, do których maja dostęp tylko klienci z wybranej dziedziny. 7/47 Wykład 8 p

3 Komunikacja między domenami ORB Adapter obiektu Za komunikację 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 pomiędzy domenami ORB została utworzona specyfikacja protokołu IIOP (Internet Inter-ORB Protocol). IIOP wykorzystuje stos TCP/IP do komunikacji. Dzięki protokołom GIOP i IIOP możliwy jest dostęp do Corby z poziomu różnych, nawet bardzo odmiennych od siebie, języków programowania. Realizacja wywołania zdalnej metody w Corbie wymaga, aby po stronie serwera znajdował się mechanizm, który jest odpowiedzialny za bezpieczeństwo tej operacji, utworzenia referencji do obiektu oraz za aktywację implementacji. Taki mechanizm nazywa się adapterem obiektu. W chwili obecnej CORBA zawiera dwa podstawowe typy adapterów: Adapter BOA (Basic Object Adapter) charakteryzuje się 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 pomiędzy różnymi implementacjami. Adapter POA (Portable Object Adapter) zastępuje adapter BOA i zawiera brakujace operacje, które nie występuja w adapterze BOA. Wywołanie zdalnych operacji 9/47 Repozytorium Interfejsu Dostęp do zdalnych obiektów może odbywać się w sposób statyczny lub dynamiczny: Statyczne wywołanie operacji następuje poprzez pieniek IDL (ang. IDL stub). Programista specyfikuje pieniek wykorzystujac język IDL. Pieniek jest funkcja klienta, która pozwala statycznie wywoływać zdalne operacje poprzez wywołanie zwykłej lokalnej funkcji (badź metody w przypadku języka obiektowego np. C++). Dynamiczne wywołanie operacji. Aplikacja może w trakcie działania może dokonać specyfikacji usługi, która jest wymagana. Niezbędna jest przy tym informacja o interfejsie i o niezbędnych typach. Taka informację można otrzymać od programisty lub programowo z interfejsu repozytorium. Repozytorium Interfejsu umożliwia uzyskanie dostępu do interfejsów obiektów, operacji jakie sa przez nie udostępnione oraz parametrów i typów jakie sa w nich wykorzystywane. Można je traktować jako bazę danych zawierajac a definicję obiektów. Repozytorium interfejsu zawiera te same informacje, które znajduja się w plikach IDL. 11/47

4 Repozytorium Implementacji Tworzenie aplikacji 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. Proces tworzenia aplikacji z wykorzystaniem technologii CORBA można podzielić na następujace etapy: zdefiniowanie interfejsów obiektów w IDL, generacja kodu pieńka klienta przy wykorzystaniu kompilatora IDL, utworzenie implementacji obiektu po stronie serwera (servant), utworzenie kodu klienta, utworzenie kodu serwera. OMG IDL 13/47 Składnia OMG IDL OMG IDL (Interface Definition Language - język definiowania interfejsu) jest podstawowym mechanizmem w Corbie umożliwiajacym odseparowanie interfejsu obiektu (deklaracji obiektu) od jego implementacji. Jest językiem typowo deklaracyjnym i nie pozwala na realizację obiektów. Gramatyka języka IDL jest podzbiorem ANSI C++ z dodatkowymi konstrukcjami, wspierajacymi mechanizm wywoływania operacji. 15/47

5 OMG IDL - typy danych (I) OMG IDL - typy danych (II) typy podstawowe: typy definiowane Deklaracja typu definiowanego (typedef) może być używana w celu przypisania nazwy do definicji dowolnego typu, np. typedef string MemoVal; W praktyce, typedef wykorzystuje się dla tablic i typów szablonowych. tablice IDL dostarcza możliwości tworzenia wielowymiarowych tablic stałego rozmiaru do przechowywania elementów dowolnego typu. Rozmiar każdego wymiaru musi być określony w definicji, np. typedef long CellValues[10][20]; Należy używać typedef dla tablic, które sa używane jako parametr, atrybut lub wartość zwracana. 17/47 OMG IDL - typy danych (III) OMG IDL - typy danych (IV) typy szablonowe sekwencja (sequence) Sekwencja jest zmiennej długości lista elementów dowolnego typu IDL. Sekwencje możemy określić jako jednowymiarowa tablicę zmiennej długości. Długość sekwencji może być ograniczona (określamy jej maksymalny rozmiar) lub nie. typedef sequence <octet,10> s1; typedef sequence <octet> s2; string String jest sekwencja znaków (char). Podobnie jak sekwencja może być ograniczony lub nie: typedef string <15> Name; typedef string Description; typ wyliczeniowy Jest to najprostszy z typów konstrukcyjnych. Przykład: enum Petcat, dog, fish, bird, rat, horse; struktury Struktura podobnie jak kilka elementów w IDL, ma te same możliwości jak w C++, a ponadto umożliwia tworzenie typów rekurencyjnych. Przykład: struct Osoba string<10> imie; string<10> nazwisko; long rok_urodzenia; ; 19/47

6 OMG IDL - typy danych (V) OMG IDL - moduł Unie Unia w IDL zawiera identyfikator pola określajacy, która zmienna składowa unii jest bieżaco przypisana z wartościa. union nazwa_unii switch(typ) case wielkość_stała_1: typ nazwa1; case wielkość_stała_2: typ nazwa2; default: typ nazwa; ; Przykład: union Reference switch(short) case 1:Title: string; Author: string; case 2: URL: string; case 3: TopicID: long; ; Moduł w IDL pełni rolę głównie porzadkow a (jest opcjonalny). Stanowi przestrzeń nazw i z tego powodu, gdy IDL jest tłumaczony na C++ jest automatycznie zamieniany na namespace. module BazaDanych Istnieje możliwość ponownego otwierania przestrzeni nazw, jaka stwarza moduł: module Modul1 module Modul2 module Modul1 OMG IDL - stałe 21/47 OMG IDL - interfejsy (I) IDL zezwala na deklaracje stałych - wykorzystane jest przy tym słowo kluczowego const: const unsigned long LenghtOfNameString=15; W IDL nie sa obsługiwane stałe typu octet. Liczby całkowite moga być określane z użyciem dziesiętnej (ang. decimal), ósemkowej (ang. octal) lub szesnastkowej (ang. hexadecimal) notacji. Interfejsy (ang. Interfaces) - definiuja zbiór metod (operacji), które moga być wywoływane klient. Można rozumieć je jako definicję klasy, bez zawartej w niej sekcji implementacyjnej. Interfejsy sa deklarowane z użyciem słowa kluczowego interface. Wewnatrz deklaracji interfejsu jest lista atrybutów i metod. Wszystkie metody sa publiczne. Przykład: interface Example1 readonly attribute string Name; attribute long Value; long AddToValue(in long Summand, out long Resualt); ; 23/47

7 OMG IDL - interfejsy (II) OMG IDL - atrybuty IDL dopuszcza trzy typy interfejsu: interfejs abstrakcyjny (abstract)- stanowiacy podstawę hierarchii obiektowej stosowanej w danej aplikacji, interfejs lokalny (local), interfejs zwykły, który stanowi obiekt publiczny w środowisku aplikacji. Zapis interfejsu przedstawia się następujaco: abstract local interface <nazwa> : lista dziedziczenia Interfejs może posiadać atrybuty. Atrybuty w przeciwieństwie do innych obiektowych języków programowania sa tylko publiczne. Deklaracja atrybutu w interfejsie jest poprzedzona słowem kluczowym attribute. Dodanie słowa kluczowego readonly powoduje, iż nowo zadeklarowany atrybut jest przeznaczony tylko do odczytu. Przykład: attribute float liczba; readonly attribute double suma; 25/47 OMG IDL - wyjatki OMG IDL - metody (I) Każdy interfejs może definiować wiele wyjatków (ang. exceptions), które zgłaszane sa momencie wystapienia błędu w trakcie wykonania operacji. interface Konto exception BrakSrodkow ; ; Po słowie kluczowym raises występuje lista wyjatków, które moga być zgłaszane podczas wykonania operacji. Podczas wykonania operacji moga być zgłaszane również wyjatki standardowe sygnalizowane przez ORB, które nie musza być wymieniane po słowie raises. Deklaracja metody zawiera typ zwracanej wartości, nazwę metody oraz jej parametry. Każdy parametr musi zawierać słowo kluczowe określajace kierunek przesyłanego parametru, typ parametru i jego nazwę. Stosowane sa następujace słowa kluczowe: in (kierunek wejściowy), out (kierunek wyjściowy), inout (kierunek wejściowo - wyjściowy). Klient po wywołaniu metody jest blokowany - oczekuje na zakończenie działania operacji i na zwrócona wartość. W przypadku, gdy klient nie musi czekać na zwracana wartość, to należy ja zadeklarować z użyciem słowa kluczowego oneway przed typem zwracanej wartości. 27/47

8 OMG IDL - metody (II) OMG IDL - dziedziczenie W celu określenia możliwości wystapienia wyjatków w metodzie należy użyć słowa kluczowego raises, po którym w nawiasach okragłych po przecinku należy wymienić nazwy wyjatków. Wyjatki powinny być zdefiniowane wcześniej słowem kluczowym exception. Przykład: interface Calka double Suma(in double a, in double b); double Iloczyn(in double a, in double b); interface Drzewo exception ObiektIstnieje ; void NowyElement(in double a) raises(obiektistnieje); oneway void Reorganizacja(); ; CORBA dopuszcza możliwość dziedziczenia przez interfejs atrybutów i metod innych interfejsów. interface Baza ; interface InterfejsPochodny: Baza ; CORBA umożliwia dziedziczenie wielokrotne, o ile interfejsy przodków nie maja definicji z identyczna nazwa. Wszystkie interfejsy IDL dziedzicza bezpośrednio od CORBA interface object. 29/47 OMG IDL - dyrektywy preprocesora Interfejs obiektu w IDL W plikach IDL moga zostać wykorzystane dyrektywy preprocesora: #define #elif #else #endif #ifdef #ifndef #include Przykład: Plik kalkulator.idl: interface Kalkulator double dodaj(in double x1, in double x2); ; #include <baza.idl> 31/47

9 Generacja szkieletu w C++ POA - architektura (I) W przypadku implementacji omniorb kompilator IDL nazywa się omniidl. Standardowo do wygenerowania kodu w języku C++ wykorzystywana jest opcja -bcxx: omniidl -bcxx kalkulator.idl w wyniku otrzymujemy dwa pliki: kalkulator.hh kalkulatorsk.cc Po dodaniu opcji -Wbexample (omniidl -bcxx -Wbexample hello.idl) wygenerowany zostaje ponadto plik kalkulator_i.cc. POA zawiera kilkanaście komponentów dość precyzyjnie zdefiniowanych w specyfikacji: Klient - Program wywołujacy operacje na obiektach poprzez ich referencję. Serwer - Program odpowiedzialny za realizację zadań stawianych przez klienta. Zawiera implementację obiektów servant oraz POA. Obiekt - W architekturze POA oznacza abstrakcyjna jednostkę zdefiniowana dzięki technologii CORBA. Każdy obiekt zawiera identyfikator, interfejs i implementację interfejsu. Servant - Stanowi jednostkę (obiekt) w języku programowania użytym do implementacji interfejsu. Jest to element programu serwera. Menadżer servant - Obiekt tworzony przez programistę, przeznaczony do kontroli poszczególnych obiektów servant (np. do ich tworzenia oraz usuwania). POA - architektura (II) 33/47 Hierarchia obiektów POA komponenty POA cd.: ObjectID - Identyfikator obiektu - jest niepowtarzalnym ciagiem wartości typu octec (może być wygenerowany przez system lub podany przez użytkownika). Referencja obiektu - Służy do określania położenia obiektu oraz zawiera identyfikatory nadane przez POA. Policy - Definiuje zachowanie obiektów implementowanych przez POA. POA - Jednostka składowa programu serwera (zawiera pozostałe elementy architektury jak servant czy inne obiekty POA). Menadżer POA - Umożliwia zmianę stanów obiektów POA (kolejkowanie poszczególnych żadań, odrzucanie, tworzenie nowych oraz usuwanie obiektów POA). Obiekty POA tworza hierarchię. Pierwszym obiektem występujacym w każdym serwerze jest korzeń hierarchii POA (RootPOA). W przeciwieństwie do pozostałych obiektów POA korzeń zawsze jest dostępny i nie trzeba go tworzyć. Pozostałe obiekty POA moga być tworzone przy użyciu RootPOA badź przez menadżera POA. Zadaniem obiektów POA jest przechowywanie obiektów servant. 35/47

10 AOM Zmiana stanu obiektu POA (I) Obiekt POA zawiera specjalny obiekt o nazwie Active Object Map (AOM) - mapa aktywnych obiektów. Gdy do obiektu POA przychodzi żadanie od klienta, adapter sprawdza, czy w AOM istnieje referencja do obiektu. Jeżeli taka referencja istnieje, to odszukiwany jest odpowiedni obiekt servant. W przypadku braku referencji POA odwołuje się do domyślnego obiektu servant lub do menadżera obiektów servant, których zadaniem jest utworzenie nowego lub odszukanie istniejacego obiektu servant. Każdy obiekt POA jest wyposażony w menadżera, którego zadaniem jest zmiana stanu obiektu POA. Obiekt POA może znajdować się w jednym z czterech stanów: active - żadania sa obsługiwane na bieżaco, holding - żadania sa dołaczane do kolejki, discarding - żadania sa odrzucane, a klient otrzymuje wyjatek TRANSIENT, inactive - żadania nie sa obsługiwane, obiekt POA jest w trakcie procedury usuwania. Zmiana stanu obiektu POA (II) 37/47 CORBA - przykład Po wywołaniu metody create_poa obiekt POA znajduje się w stanie holding. Przetwarzanie żadań odbywa się dopiero po wywołaniu metody activate z menadżera POA. Usunięcie obiektu może zostać wykonane poprzez przez wywołanie metody menadżera deactivate. Proces tworzenia aplikacji z wykorzystaniem technologii CORBA można podzielić na następujace etapy: zdefiniowanie interfejsów obiektów w IDL, generacja kodu pieńka klienta przy wykorzystaniu kompilatora IDL, utworzenie implementacji obiektu po stronie serwera (servant), utworzenie kodu klienta, utworzenie kodu serwera. 39/47

11 Interfejs obiektu w IDL Generacja szkieletu w C++ Plik hello.idl: interface Hello string say_hello(in string client); ; W przypadku implementacji omniorb kompilator IDL nazywa się omniidl. Standardowo do wygenerowania kodu w języku C++ wykorzystywana jest opcja -bcxx: omniidl -bcxx hello.idl w wyniku otrzymujemy dwa pliki: hello.hh hellosk.cc Po dodaniu opcji -Wbexample (omniidl -bcxx -Wbexample hello.idl) wygenerowany zostaje ponadto plik hello_i.cc. 41/47 hello.hh (I) hello.hh (II) class Hello; class _objref_hello; class _impl_hello; typedef _objref_hello* Hello_ptr; typedef Hello_ptr HelloRef; class Hello public: // Declarations for this interface type. typedef Hello_ptr _ptr_type; typedef Hello_var _var_type; static _ptr_type _duplicate(_ptr_type); static _ptr_type _narrow(corba::object_ptr); static _ptr_type _unchecked_narrow(corba::object_ptr); static _ptr_type _nil(); // for internal use ; class _objref_hello : public virtual CORBA::Object, public virtual omniobjref public: char* say_hello(const char* client); // for internal use ; class _impl_hello : public virtual omniservant public: virtual ~_impl_hello(); virtual char* say_hello(const char* client) = 0; ; class POA_Hello : public virtual _impl_hello, public virtual PortableServer::ServantBase public: virtual ~POA_Hello(); inline ::Hello_ptr _this() return (::Hello_ptr) _do_this(::hello::_pd_repoid); ; 43/47

12 Servant Serwer class Hello_impl : public POA_Hello public: virtual char * say_hello(const char * client); ; char * Hello_impl::say_hello(const char * client) cout << "omniorb C++ server: " << client << endl; char * server = CORBA::string_alloc(32); strncpy(server, "omniorb C++ server", 32); return server; Typowe czynności jakie powinien wykonać serwer moga wygladać następujaco: nawiazanie kontaktu z ORB, uzyskanie obiektu-korzenia POA, odczytanie menadżera, utworzenie obiektu zawierajacego implementacje interfejsu, aktywacja implementacji, zapis IOR, aktywacja menadżera, uruchomienie pętli zdarzeń ORB. 45/47 Usługa nazw Kod serwera II Klient może na różne sposoby uzyskać referencje do zdalnego obiektu. Wygodnym mechanizmem jaki może być w tym celu wykorzystany jest mechanizm o nazwie usługa nazw (Naming Service). Umożliwia ona na identyfikacje obiektów posługujac się ich nazwami symbolicznymi. int main(int argc, char ** argv) try CORBA::ORB_ptr orb = CORBA::ORB_init(argc, argv); CORBA::Object_var poa_obj = orb->resolve_initial_references("rootpoa"); PortableServer::POA_var poa = PortableServer::POA::_narrow(poa_obj); PortableServer::POAManager_var manager = poa->the_poamanager(); Hello_impl * service = new Hello_impl; try CORBA::Object_var ns_obj = orb->resolve_initial_references("nameservice"); if (!CORBA::is_nil(ns_obj)) CosNaming::NamingContext_ptr nc = CosNaming::NamingContext::_narrow(ns_obj); CosNaming::Name name; name.length(1); name[0].id = CORBA::string_dup("TestServer"); name[0].kind = CORBA::string_dup(""); nc->rebind(name, service->_this()); cout << argv[0] << ": server TestServer bound" << endl; catch (CosNaming::NamingContext::NotFound &) cerr << "not found" << endl; catch (CosNaming::NamingContext::InvalidName &) cerr << "invalid name" << endl; catch (CosNaming::NamingContext::CannotProceed &) cerr << "cannot proceed" << endl; manager->activate(); orb->run(); delete service; orb->destroy(); catch (CORBA::UNKNOWN) cerr << "unknown exception" << endl; catch (CORBA::SystemException &) cerr << "system exception" << endl; 47/47

13 Kod klienta II int main(int argc, char ** argv) try CORBA::ORB_ptr orb = CORBA::ORB_init(argc, argv); Hello_ptr hello = 0; try CORBA::Object_var ns_obj = orb->resolve_initial_references("nameservice"); if (!CORBA::is_nil(ns_obj)) CosNaming::NamingContext_ptr nc = CosNaming::NamingContext::_narrow(ns_obj); CosNaming::Name name; name.length(1); name[0].id = CORBA::string_dup("TestServer"); name[0].kind = CORBA::string_dup(""); CORBA::Object_ptr obj = nc->resolve(name); if (!CORBA::is_nil(obj)) hello = Hello::_narrow(obj); catch (CosNaming::NamingContext::NotFound &) cerr << "not found" << endl; catch (CosNaming::NamingContext::InvalidName &) cerr << "invalid name" << endl; catch (CosNaming::NamingContext::CannotProceed &) cerr << "cannot proceed" << endl; if (!CORBA::is_nil(hello)) char * server = hello->say_hello("omniorb C++ client"); cout << "answer from: " << server << endl; CORBA::string_free(server); orb->destroy(); catch (CORBA::UNKNOWN) 49/47