Studia Podyplomowe IT w Biznesie Systemy Rozproszone Wykład 4 Wprowadzenie do OMG CORBA (2) Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa.

Prezentacja na temat: "Studia Podyplomowe IT w Biznesie Systemy Rozproszone Wykład 4 Wprowadzenie do OMG CORBA (2) Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa."— Zapis prezentacji:

1 Studia Podyplomowe IT w Biznesie Systemy Rozproszone Wykład 4 Wprowadzenie do OMG CORBA (2) Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa Wykładowca: dr hab. inż. Kazimierz Subieta profesor PJWSTK subieta@ipipan.waw.pl, http://www.ipipan.waw.pl/~subieta Niniejszy materiał jest dostępny pod: http://www.si.pjwstk.edu.pl

2 K.Subieta. Systemy Rozproszone, Wykład 4, Slajd 2 październik 2001 IDL: struktury i unie struct - pozwala na grupowanie wartości różnych typów (podobnie do C/C++). module Bank { struct DaneKlienta { string imię, nazwisko; short wiek; }; interface Konto { DaneKlienta pobierzDane Właściciela();... }; }; union - pozwala na definiowanie alternatywnych struktur. struct SData {short dzień, miesiąc, rok;}; union Data switch (short) { case 1 : string formatNapisu; case 2 : long formatCyfrowy; default : SData formatStruktury; };

3 K.Subieta. Systemy Rozproszone, Wykład 4, Slajd 3 październik 2001 IDL: tablice, synonimy, stałe IDL umożliwia definiowanie tablic elementów dowolnego typu IDL. Każdy element tablicy musi mieć ten sam typ. Tablice mogą być wielowymiarowe. module Bank { struct Klient { string nazwa; Konto konta[3]; } typedef string DaneWpłat[10][2]; /* synonim typu */ /* ostatnie 10 wpłat, data i nazwa wpłacającego */ interface Konto { readonly attribute DaneWpłat wpłaty;... }; Stałe: const string AUTOR = Jan Nowak; const long MAX_ILOŚĆ_KONT = 10000;

4 K.Subieta. Systemy Rozproszone, Wykład 4, Slajd 4 październik 2001 IDL nie ma konstrukcji sterujących języków programowania, nie może być więc bezpośrednio użyty do implementacji rozproszonych aplikacji. Zamiast tego, odwzorowania językowe określają, jak cechy IDL mają być odwzorowane na cechy poszczególnych języków programowania. IDL nie ma konstrukcji sterujących języków programowania, nie może być więc bezpośrednio użyty do implementacji rozproszonych aplikacji. Zamiast tego, odwzorowania językowe określają, jak cechy IDL mają być odwzorowane na cechy poszczególnych języków programowania. Dotychczas zdefiniowano odwzorowania dla C, C++, Smalltalk, ADA95, COBOL, Java, Unix Bourne shell; Perl, Eiffel, Modula-3 i inne języki - niezależnie od OMG. OMG IDL long, short,... any string, wstring sequence referencja do obiektu interface operation module Przykładowe odwzorowanie IDL do C++: C++ long, short,... any class char *, wchar_t * class wskaźnik lub obiekt class funkcja członkowska namespace Obiekty CORBA są implementowane jako obiekty języka programowania IDL: odwzorowania językowe language mappings

5 K.Subieta. Systemy Rozproszone, Wykład 4, Slajd 5 październik 2001 Każda aplikacja oparta na CORBA wymaga dostępu do systemu typów zapisanych w OMG IDL oraz do odpowiednich interfejsów. Każda aplikacja oparta na CORBA wymaga dostępu do systemu typów zapisanych w OMG IDL oraz do odpowiednich interfejsów. Wiele aplikacji wymaga wyłącznie wiedzy statycznej, wykorzystywanej podczas kompilacji. Specyfikacja w OMG IDL jest kompilowana lub translowana w kod specyficzny dla danego języka programowania, w którym jest pisana aplikacja, zgodnie z odwzorowaniem językowym. Ten kod następnie jest wbudowany w aplikację. Zmiany w środowisku w zakresie obiektów przetwarzanych przez tę aplikację wymagają zmiany aplikacji. Istnieją aplikacje, dla których wiedza statyczna jest mało praktyczna. Np. aplikacje obce (np. oparte o Microsoft COM) chcą dostać się do obiektów CORBA. Ich zmiana i ponowna kompilacja po każdej zmianie specyfikacji w IDL spowodowałaby trudności. Alternatywą jest dynamiczny dostęp i wykorzystanie informacji o typie. CORBA IR (Interface Repository) pozwala na dostęp do typów zdefiniowanych w IDL podczas czasu wykonania. Dostęp jest hierarchiczny: np. po dostępie do modułu można iterować po definicjach znajdujących się wewnątrz tego modułu. CORBA IR (Interface Repository) pozwala na dostęp do typów zdefiniowanych w IDL podczas czasu wykonania. Dostęp jest hierarchiczny: np. po dostępie do modułu można iterować po definicjach znajdujących się wewnątrz tego modułu. Zastosowanie tego udogodnienia jest istotne dla wołań dynamicznych. Interface Repository Repozytorium interfejsów

6 K.Subieta. Systemy Rozproszone, Wykład 4, Slajd 6 październik 2001 Implementation Repository Repozytorium implementacji zawiera informację, która pozwala dla ORB zlokalizować i zaktywować implementację obiektów. Zazwyczaj, instalacja implementacji oraz sterowanie czynnościami aktywacji obiektów i wykonania związanych z nimi metod jest wykonywana poprzez repozytorium implementacji. Repozytorium implementacji zawiera informację, która pozwala dla ORB zlokalizować i zaktywować implementację obiektów. Zazwyczaj, instalacja implementacji oraz sterowanie czynnościami aktywacji obiektów i wykonania związanych z nimi metod jest wykonywana poprzez repozytorium implementacji. Repozytorium implementacji jest podstawowe dla funcjonowania ORB; jest ono także miejscem przechowywania dodatkowej informacji związanej z implementacją obiektów, np. informacji do testowania (debugging), kontroli administracyjnej, alokacji zasobów, bezpieczeństwa, itd. Repozytorium implementacji

7 K.Subieta. Systemy Rozproszone, Wykład 4, Slajd 7 październik 2001 Rejestracja obiektów: OA dostarcza operacji, które pozwalają zarejestrować byty języka programowania jako implementację obiektów CORBA. Szczegóły odnośnie tego, co jest rejestrowane i jak rejestracja jest zrealizowana zależą od języka programowania. Generacja referencji do obiektów CORBA. Aktywacja procesu na serwerze: Jeżeli trzeba, OA startuje procesy umożliwiające aktywację obiektów. Aktywacja obiektu: OA aktywuje obiekt, jeżeli nie jest on aktywny w momencie nadejścia zlecenia do tego obiektu. Odblokowanie połączeń: OA współpracuje z ORB celem zmiany połączenia w sytuacji, gdy uzyskane połączenie jest na czas dłuższy zablokowane. Wysyłanie wołań do obiektu zgodnie z jego interfejsem. Role adapterów obiektów

8 K.Subieta. Systemy Rozproszone, Wykład 4, Slajd 8 październik 2001 Obiekty są manipulowane poprzez metody wewnątrz implementacji obiektów Obiekty są tworzone przez warstwę implementacji obiektów lub już istnieją w pewnych repozytoriach na zewnątrz CORBA. Obiekty są manipulowane poprzez metody wewnątrz implementacji obiektów Obiekty są tworzone przez warstwę implementacji obiektów lub już istnieją w pewnych repozytoriach na zewnątrz CORBA. Obiekty (np. konta, pojazdy, pracownicy, akcje) mogą być: - chwilowymi obiektami lub zmiennymi, utworzonymi w pamięci operacyjnej, - krotkami w relacyjnej bazie danych, - obiektami w obiektowej bazie danych. CORBA traktuje wszystkie takie sytuacje jednakowo. Warstwa implementacji obiektów tworzy unikalne referencje do obiektów. CORBA tym się nie zajmuje. Sposób tworzenia referencji i jej budowa jest sprawą dostawcy ORB-u lub klienta. Każdy obiekt obsługiwany przez CORBA musi mieć referencję. Kowalsk i Nowak referencja1 referencja2 Obiekty pracowników Referencje do obiektów odsyła do Implementacja obiektów Scenariusz zarządzania obiektami (1)

9 K.Subieta. Systemy Rozproszone, Wykład 4, Slajd 9 październik 2001 1. Warstwa implementacji obiektów czyni publicznymi referencje do obiektów. 2. Klienci kolekcjonują i zapamiętują referencje. 3. Klienci wysyłają zlecenia do obiektów używając ich referencji. Obiekty nie są przesyłane pomiędzy klientem i serwerem poprzez mechanizmy CORBA; zamiast tego, używane i przesyłane są referencje. 1. Warstwa implementacji obiektów czyni publicznymi referencje do obiektów. 2. Klienci kolekcjonują i zapamiętują referencje. 3. Klienci wysyłają zlecenia do obiektów używając ich referencji. Obiekty nie są przesyłane pomiędzy klientem i serwerem poprzez mechanizmy CORBA; zamiast tego, używane i przesyłane są referencje. 1. ORB lokalizuje implementację obiektu związaną z referencją do obiektu. 2. Adapter obiektu aktywuje obiekt w jego warstwie implementacyjnej. 3. Adapter obiektu przekazuje zlecenie (przydziela metodę) do obiektu. Metody znajdujące się w warstwie implementacji obiektu dokonują odpowiednich manipulacji obiektami 1. ORB lokalizuje implementację obiektu związaną z referencją do obiektu. 2. Adapter obiektu aktywuje obiekt w jego warstwie implementacyjnej. 3. Adapter obiektu przekazuje zlecenie (przydziela metodę) do obiektu. Metody znajdujące się w warstwie implementacji obiektu dokonują odpowiednich manipulacji obiektami ORB znajduje właściwą implementację PodajZarobekPrac Kowalski przydziela metodę aktywuje Adapter obiektu Scenariusz zarządzania obiektami (2)

10 K.Subieta. Systemy Rozproszone, Wykład 4, Slajd 10 październik 2001 Metody wewnątrz warstwy implementacji obiektów wykonują potrzebną manipulację i zwracają rezultaty i wartości parametrów wyjściowych. ORB zwraca te rezultaty i wartości parametrów wyjściowych z powrotem do klienta. Metody wewnątrz warstwy implementacji obiektów wykonują potrzebną manipulację i zwracają rezultaty i wartości parametrów wyjściowych. ORB zwraca te rezultaty i wartości parametrów wyjściowych z powrotem do klienta. Klient ORB wynik 3000 PLN PodajZarobekPrac Kowalski Implementacja obiektu Scenariusz zarządzania obiektami (3)

11 K.Subieta. Systemy Rozproszone, Wykład 4, Slajd 11 październik 2001 Zdefiniuj interfejsy serwera (klasy obiektów) używając IDL. Interfejsy w IDL informują klienta o obiektach, które są w zasięgu ORB, o ich atrybutach, o metodach, które wolno stosować, o parametrach i wyniku tych metod, oraz o wyjątkach, które mogą być powodowane przez metody. Wprowadź definicję interfejsu do repozytorium interfejsów, używając do tego celu specjalnego udogodnienia. Informację tę mogą wykorzystywać programy aplikacyjne np. dla celów wołań dynamicznych. Zastosuj prekompilator do definicji interfejsów w IDL. Typowy prekompilator CORBA wyprowadza co najmniej trzy rodzaje kodu wyjściowego: 1) pniaki klienta dla metod zdefiniowanych w IDL. Pniaki te są używane przez program klienta w celu statycznego dostępu do obiektów. 2) szkielety serwera, określające nagłówki metod (+ inne informacje), które mają być zaimplementowane po stronie serwera. 3) Specyficzną dla danego języka programowania definicję klasy (np w Java lub C++). 1) i 2) nie wymagają dalszych zabiegów, 3) musi być zapełnione kodem. 1 Wołanie statyczne: krok po kroku (1) 2 3

12 K.Subieta. Systemy Rozproszone, Wykład 4, Slajd 12 październik 2001 Wołanie statyczne: krok po kroku (2) Dodaj kod po stronie serwera do szkieletu wyprodukowanego przez wyrażenie IDL. Kod ten implementuje metody zdefiniowane w wyrażeniu IDL. Skompiluj ten kod, używając w tym celu normalnego kompilatora wybranego języka programowania. Zarejestruj obiekty serwera w Repozytorium Implementacji. ORB używa tej informacji celem zlokalizowania aktywnych obiektów lub celem wykonania ich aktywacji. Rejestracja obiektów wymaga napisania programu o dość standardowej budowie. Utwórz instancje obiektów na serwerze. W czasie startu aplikacji, Adapter Obiektów znajdujący się na serwerze może tworzyć obiekty, które będą obsługiwać odległe wołania metod ze strony klienta. CORBA definiuje specjalne strategie Adaptera Obiektów, które są używane do tworzenia i zarządzania tego rodzaju obiektami. 4 5 6 7

13 K.Subieta. Systemy Rozproszone, Wykład 4, Slajd 13 październik 2001 Wołanie statyczne: krok po kroku (3) Zaimplementuj kod aplikacji klienta, która będzie używać obiektów serwera wcześniej zdefiniowanych, zaimplementowanych i utworzonych. Skompiluj ten kod używając normalnego kompilatora wybranego języka programowania. Nie zapomnij o dołączeniu podczas kompilacji pliku z pieńkiem klienta utworzonym z wyrażenia IDL. 8 9 Podana wyżej procedura jest typowa, ale może mieć wiele odmian. Niektóre kroki mogą być pominięte, np. nie ma potrzeby definiowania wyrażenia IDL, jeżeli zostało ono wcześniej wprowadzone do Repozytorium Interfejsów i został już utworzony wcześniej pieniek klienta.

14 K.Subieta. Systemy Rozproszone, Wykład 4, Slajd 14 październik 2001 Podstawowy cel: współdziałanie pomiędzy ORB-ami wyprodukowanymi przez różne firmy. Wersje poprzedzające 2.0 nie zapewniały tej własności ze względu na brak standardu formatu danych i protokółów dla komunikacji pomiędzy ORB-ami. Bezpośrednie współdziałanie (direct interoperability): jest możliwe gdy ORB-y są umieszczone w tej samej dziedzinie: rozumieją te same referencje do obiektów, ten sam system typów w OMG IDL i te same środki bezpieczeństwa. Bezpośrednie współdziałanie (direct interoperability): jest możliwe gdy ORB-y są umieszczone w tej samej dziedzinie: rozumieją te same referencje do obiektów, ten sam system typów w OMG IDL i te same środki bezpieczeństwa. Współdziałanie bazujące na mostach (bridge-based interoperability): jest potrzebne do komunikacji ORB-ów z różnych dziedzin. Mają one za zadanie odwzorować informację specyficzną dla jednego ORB-u w informację właściwa dla innego. Współdziałanie bazujące na mostach (bridge-based interoperability): jest potrzebne do komunikacji ORB-ów z różnych dziedzin. Mają one za zadanie odwzorować informację specyficzną dla jednego ORB-u w informację właściwa dla innego. General Inter-ORB Protocol (GIOP) - specyfikuje składnie transferowanej informacji, format komunikatów. Jest prosty i łatwy w implementacji. Internet Inter-ORB Protocol (IIOP) - specyfikuje GIOP poprzez transport TCP/IP. Environment-Specific Inter-ORB Protocols (ESIOP), np. bazujący na OSF DCE. Protokoły pomiędzy ORB-ami Inter-ORB Protocols

15 K.Subieta. Systemy Rozproszone, Wykład 4, Slajd 15 październik 2001 Rodzaje usług obiektowych (1) Usługa w zakresie cyklu życiowego (Life Cycle Service). Definiuje operacje tworzenia, kopiowania, przemieszczania, i usuwania komponentów (obiektów) będących pod kontrolą danej aplikacji zintegrowanej poprzez standard CORBA. Usługa w zakresie trwałości (Persistence Service). Definiuje interfejs do składowania komponentów (obiektów) na trwałych nośnikach, włączając w to obiektowe bazy danych, relacyjne bazy danych i zwykłe pliki. Usługa w zakresie nazywania (Naming Service). Pozwala nadać komponentom (obiektom) nazwy (o hierarchicznej budowie) oraz odzyskać identyfikatory komponentów (obiektów) na podstawie ich nazw. Usługa pozwala przywiązać komponenty (obiekty) do istniejącego nazewnictwa katalogów systemów operacyjnych lub kontekstów nazwowych wg różnorodnych systemów: ISO X.500, OSF DCE, Sun NIS+, Novell NDS, Internet LDAP. Usługa w zakresie zdarzeń (Event Service). Pozwala określić, czy dane komponenty mają reagować (nie reagować) na określone zdarzenia. Object Services

16 K.Subieta. Systemy Rozproszone, Wykład 4, Slajd 16 październik 2001 Rodzaje usług obiektowych (2) Usługa w zakresie współbieżności (Concurrency Control Service). Pozwala zakładać/zdejmować zamki na obiekty (lub inne byty) celem przeciwdziałania kolizjom transakcji lub wątków. Usługa w zakresie transakcji (Transaction Service). Przewiduje koordynację transakcji opartą na dwufazowym potwierdzeniu (2PC) dla prostych i zagnieżdżonych transakcji. Usługa w zakresie dodatkowych własności obiektów (Properties Service). Pozwala dynamicznie związać z obiektami dowolne nazwane własności (atrybuty), np. datę utworzenia, datę ostatniej modyfikacji, nazwisko modyfikującego, itd. Usługa w zakresie czasu (Time Services). Przewiduje interfejsy do synchronizowania czasu w środowisku rozproszonym. Pozwala również definiować zdarzenia wyzwalane przez upływ czasu.

17 K.Subieta. Systemy Rozproszone, Wykład 4, Slajd 17 październik 2001 Rodzaje usług obiektowych (3) Usługa w zakresie ochrony (Security Service). Zapewnia możliwości pełnej ochrony rozproszonych obiektów. Wspomaga autoryzację, sterowanie dostępem, tajność i przeciwdziałanie unikaniu zapłaty (non-repudiation). Zarządza także oddelegowywaniem uwierzytelnień (credentials). Bardzo rozbudowana (ponad 200 stron specyfikacji). Usługa handlowa (Trader Service). Przewiduje odzyskiwanie informacji o obiektach na podstawie ich własności, publikować informacje o serwisach dostarczanych przez obiekty, itd. Usługa w zakresie kolekcji (Collection Service). Przewiduje interfejsy do tworzenia najczęściej spotykanych kolekcji (zbiorów, wielozbiorów, sekwencji, itd.) i manipulacji tymi kolekcjami. Nie wszystkie usługi są tutaj omówione.

18 K.Subieta. Systemy Rozproszone, Wykład 4, Slajd 18 październik 2001 Najbardziej znane implementacje CORBA

19 K.Subieta. Systemy Rozproszone, Wykład 4, Slajd 19 październik 2001 Zbyt maksymalistyczne cele, zbyt wolne tempo rozwoju, nie nadążanie za rozwojem współczesnych technologii (Konkurenci: DCOM, serwisy Internetu). Niski poziom abstrakcji, zbytnie przywiązanie do szczegółów technicznych jęz.prog. niskiego rzędu takich jak C++ i protokółów transportowych. Jako konsekwencja - współdziałanie i przenaszalność jest często trudne do osiągnięcia. Tendencja do rozrostu standardu w kierunku nowego języka programowania, z rozbudowanymi specjalizacjami pionowymi i poziomymi. Ograniczenia modelu danych: brak rozdzielenia typów i interfejsów, brak niektórych typów masowych (wielozbiorów), brak relatywizmu i ortogonalności typów, Problemy wydajności: komunikacja na poziomie dostępu do pojedynczych obiektów jest dla wielu aplikacji nieakceptowalna. Konieczna jest komunikacja makroskopowa, np. w stylu (optymalizowanych) języków zapytań takich jak SQL lub OQL. Problem bezpieczeństwa nie jest dotychczas traktowany z wystarczającą uwagą. Wady OMG CORBA

20 K.Subieta. Systemy Rozproszone, Wykład 4, Slajd 20 październik 2001 Podsumowanie (1) OMG CORBA jest standardem współdziałania systemów obiektowych i nieobiektowych, heterogenicznych i rozproszonych, opracowany przez gremium OMG. Dość ambitnym celem standardu OMG CORBA jest uzyskanie możliwości współdziałania pomiędzy niekompatybilnymi systemami, pracującymi na różnych platformach sprzętowych i programowych, oddalonych geograficznie. Osiągnięcie tego celu wymagało zwiększenia poziomu abstrakcji w taki sposób, aby (zazwyczaj zasadnicze) różnice implementacyjne nie miały znaczenia. Ten poziom abstrakcji osiąga się poprzez opis obiektów w uniwersalnym języku IDL (Interface Definition Language), który oprócz struktury obiektów ustala także specyfikacje metod działających na obiektach oraz zależności (wielo-) dziedziczenia. Do współdziałania konieczne jest także określenie odwzorowania (mapping) implementacji obiektów na abstrakcyjną postać implikowaną przez IDL. Temu celowi poświęcony jest adapter obiektów, w szczególności BOA (Basic Object Adapter); jest on specyficzny dla danego języka programowania.

21 K.Subieta. Systemy Rozproszone, Wykład 4, Slajd 21 październik 2001 Podsumowanie (2) Powiązanie pomiędzy aplikacją (odwołującą się do obiektów) i implementacją obiektów może mieć charakter statyczny lub dynamiczny, w zależności od tego, czy wiązanie następuje w czasie kompilacji czy też w czasie wykonania. W przypadku statycznym, z wyrażenia IDL jest generowany automatycznie tzw. pniak (stub), czyli fragment kodu, który jest konsolidowany z aplikacją klienta. Po stronie serwera obiektów z wyrażenia IDL generowany jest szkielet (skeleton) implementacji, który programista musi zapełnić konkretnym kodem implementacyjnym wyspecyfikowanych metod. W przypadku dynamicznym, dostęp następuje bezpośrednio poprzez odwołania dynamiczne, na zasadzie podobnej do RPC. OMG CORBA obejmuje także dużą kolekcję usług i udogodnień, zarówno poziomych (niezależnych od dziedziny aplikacyjnej, np. usługi w zakresie nazw, zdarzeń, trwałych obiektów, związków, zapytań), jak i pionowych (specyficznych dla danej dziedziny aplikacyjnej, np. telekomunikacja, medycyna, finanse, wytwarzanie).

22 K.Subieta. Systemy Rozproszone, Wykład 4, Slajd 22 październik 2001 Podsumowanie (3) Podstawowym elementem architektonicznym standardu CORBA jest tzw. pośrednik (Object Request Broker, ORB), skupiający w sobie funkcjonalności niezbędne do przetwarzania rozproszonych obiektów i współdziałania. Pakiety ORB komunikują się ze sobą w sieci komputerowej przy pomocy protokółu GIOP (General Inter-ORB Protocol) lub jego internetowego odpowiednika IIOP. W tej chwili zaimplementowano kilkanaście pakietów ORB. CORBA ma ogromne znaczenie kulturotwórcze w dziedzinie informatyki. Maksymalistyczne cele tego standardu są trudne do osiągnięcia, szczególnie w zakresie akceptowalnej wydajności (performance). Niektórzy specjaliści głoszą, że oparcie rozproszonych aplikacji o standard CORBA będzie zbyt kosztowne. Opinie te są prawdopodobnie nie zawsze prawdziwe, ale są podsycane przez konkurencję (np. Microsoft z technologią COM/DCOM). Argument Microsoftu przeciwko CORBA dotyczy zbyt wolnego rozwoju i małej skali zastosowań (nie do końca są słuszne.)