© K.Subieta. Systemy rozproszone 6, Folia 1 styczeń 2005 Systemy rozproszone (SYR) Wykładowca: Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik.

Prezentacja na temat: "© K.Subieta. Systemy rozproszone 6, Folia 1 styczeń 2005 Systemy rozproszone (SYR) Wykładowca: Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik."— Zapis prezentacji:

1 © K.Subieta. Systemy rozproszone 6, Folia 1 styczeń 2005 Systemy rozproszone (SYR) Wykładowca: Kazimierz Subieta Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa subieta@pjwstk.edu.pl Instytut Podstaw Informatyki PAN, Warszawa subieta@ipipan.waw.pl Wykład 6: Wprowadzenie do OMG CORBA (1)

2 © K.Subieta. Systemy rozproszone 6, Folia 2 styczeń 2005 Object Management Group Konsorcjum programistyczne utworzone w 1989 r. Zajmuje się rozwojem, adaptacją i promowaniem standardów dla rozwijania i rozprzestrzeniania aplikacji w środowiskach heterogenicznych i rozproszonych. Skupia ok. 800 czołowych firm rozwojowych, producentów i dostawców oprogramowania oraz użytkowników. Technika działania: RFP (Request For Proposal): zapytania odnośnie konkretnych tematów wysyłane przez komitety OMG do wszystkich członków. Członkowie (aktywni w danej sprawie) nadsyłają swoje propozycje. Integracja propozycji następuje wewnątrz komitetów na zasadzie głosowania. Rezultat działalności: OMA ( Object Management Architecture ), której najważniejszym składnikiem jest CORBA (Common Object Request Broker Architecture) OMA ( Object Management Architecture ), której najważniejszym składnikiem jest CORBA (Common Object Request Broker Architecture) Co to jest OMG?

3 © K.Subieta. Systemy rozproszone 6, Folia 3 styczeń 2005 Misja OMG Opracowanie jednorodnej architektury z użyciem technologii obiektowej, mającej na celu integrację rozproszonych aplikacji, która zapewniałaby: ponowne użycie komponentów oprogramowania i danych współdziałanie i przenaszalność podstawy rynku kompatybilnego oprogramowania OMG skupia się na szybkim rozwoju łatwych w użyciu (dostępnych na półce) standardowych komponentów.

4 © K.Subieta. Systemy rozproszone 6, Folia 4 styczeń 2005 Jednorodna terminologia dla modelu obiektowego Jedna, zuniformizowana perspektywa danych dla całego rozproszonego, heterogenicznego systemu Zachowanie autonomii lokalnych systemów Wspólna abstrakcyjna rama koncepcyjna Wspólny model odwoływania się do danych i usług Wspólne interfejsy i protokóły Podstawą integracji modelu są kluczowe cechy obiektowości, takie jak obiekty, klasy (interfejsy), metody (operacje), hermetyzacja, polimorfizm i dziedziczenie Koncepcja OMG

5 © K.Subieta. Systemy rozproszone 6, Folia 5 styczeń 2005 Andersen APM Apple ASCII AT&T Bell Nothern Borland Bull CA CI Labs Data Access Digital EDS Expertsoft Fujitsu Genesis HP HyperDesk ICL Informix Intel IntelliCorp IBM Micro Focus Microsoft MITRE NeXT Novell Object Design Object Tech.Intl Oracle OSF ParcPlace POSC Siemens Nixdorf Software AG Sun Microsyst. Sybase Symantec Taligent Telefonica I+D Tivoli TRW Unisys Xerox Istnieje wiele produktów i aplikacji opartych o standard CORBA. Praktycznie każdy miesiąc przynosi informację o nowym produkcie. OMG: Czołowi partnerzy

6 © K.Subieta. Systemy rozproszone 6, Folia 6 styczeń 2005 OMA: ogólna architektura Obiekty Aplikacyjne Object Request Broker (Pośrednik Zapotrzebowania na Obiekty) Wspólne Usługi Obiektowe (Usługi CORBA) WspółbieżnośćNazwowa Własności Cykl życiowyTrwałośćHandlowa Ochrona Kolekcje Dostęp zewnętrznyZwiązkiZapytaniaTransakcje ZdarzeniaStartupLicencje Czas Wspólne udogodnienia (Udogodnienia CORBA) Wspólne udogodnienia pionowe (dziedzinowe) Wspólne udogodnienia poziome Rozproszone dokumenty Zarządzanie informacją Zarządzanie systemem Zarządzanie zadaniami MedycynaFinanseRachunkowość.....

7 © K.Subieta. Systemy rozproszone 6, Folia 7 styczeń 2005 OMA { Model obiektów (opis obiektów rozproszonych w sieci komputerowej) Model interakcji pomiędzy obiektami) Model obiektów OMA: Obiekt jest hermetyzowanym bytem z unikalną niezmienialną tożsamością. Obsługa obiektów może odbywać się wyłącznie poprzez dobrze zdefiniowane interfejsy. Klienci wysyłają zlecenia do obiektów, które wykonują odpowiednie usługi. Implementacja i lokacja obiektów jest dla klienta ukryta. OMA: Architektura Zarządzania Obiektami Object Management Architecture

8 © K.Subieta. Systemy rozproszone 6, Folia 8 styczeń 2005 Są to interfejsy niezależne od dziedziny, które mogą być używane przez wiele systemów rozproszonych obiektów. Np. usługa polegająca na rozpoznaniu wszystkich istniejących w systemie usług jest potrzebna niezależnie od dziedziny aplikacyjnej. Są to interfejsy niezależne od dziedziny, które mogą być używane przez wiele systemów rozproszonych obiektów. Np. usługa polegająca na rozpoznaniu wszystkich istniejących w systemie usług jest potrzebna niezależnie od dziedziny aplikacyjnej. Przykłady usług: Usługa w zakresie nazw (naming service) - pozwala klientom na odszukanie obiektów (ich referencji) na podstawie ich nazw. Usługa handlowa (trading service) - pozwala klientom na odszukanie obiektów na podstawie pożądanych własności obiektów. Pozostałe usługi mają różnorodne przeznaczenie. Nie wszystkie są zaimplementowane w dostepnych pakietach ORB. Pozostałe usługi mają różnorodne przeznaczenie. Nie wszystkie są zaimplementowane w dostepnych pakietach ORB. OMA: usługi obiektowe Object Services

9 © K.Subieta. Systemy rozproszone 6, Folia 9 styczeń 2005 Koncepcja polega na zdefiniowaniu zrębów (frameworks), tj. grup obiektów specyficznych dla danej dziedziny, które ustalają w niej rozwiązanie jakiegoś problemu: np. w telekomunikacji, medycynie, finansach, wytwarzaniu. ORB, Object Request Broker (Pośrednik Zapotrzebowania na Obiekty) Zrąb obiektowy IA - Interfejsy Aplikacyjne ID - Interfejsy Dziedzinowe WU - Wspólne Udogodnienia UO - Usługi Obiektowe komponenty aplikacji komunikują się poprzez ORB UO IA, ID, WU, UO IA, WU, UO Użycie modelu OMA

10 © K.Subieta. Systemy rozproszone 6, Folia 10 styczeń 2005 Klient Implementacja obiektów Wołania dynamiczne (RPC) Pniak IDL (IDL stub) Interfejs do pośrednika ORB Szkielet obiektów (IDL skeleton) Adapter obiektów Rdzeń Pośrednika (ORB core) Dynamiczny Szkielet Interfejsu dynamicznestatyczne Przesyłanie zlecenia od klienta do obiektów

11 © K.Subieta. Systemy rozproszone 6, Folia 11 styczeń 2005 CORBA: schemat komunikowania się klienta z serwerem Host klienta Klient Wywołanie operacji Host serwera Obiekt Pośrednik (ORB, Object Request Broker) Definicja obiektów w IDL pozwala dla klienta widzieć je na abstrakcyjnym poziomie. Klient jest zwolniony z rozpatrywania jakichkolwiek środków komunikacji pomiędzy klientem i serwerem. Z jego punktu widzenia obiekty znajdują się bezpośrednio (wirtualnie) w jego przestrzeni adresowej. zlecenie wynik, parametry wyj

12 © K.Subieta. Systemy rozproszone 6, Folia 12 styczeń 2005 CORBA: schemat wywołania statycznego Host klienta Klient Wywołanie operacji Host serwera Obiekt Pośrednik (ORB, Object Request Broker) Pniak klienta jest fragmentem aplikacji klienta generowanym automatycznie z wyrażenia IDL. Implementacja interfejsu do obiektu po stronie serwera powstaje ze szkieletu interfejsu do obiektu, automatycznie generowanego z wyrażenia IDL, który jest następnie wypełniany (ręcznie) kodem implementacji operacji zdefiniowanych w wyrażeniu IDL. Pniak klienta Implementacja interfejsu do obiektu (szkielet + kod) zlecenie wynik, parametry wyj

13 © K.Subieta. Systemy rozproszone 6, Folia 13 styczeń 2005 stubs, skeletons Pniak(stub) znajduje się po stronie klienta i zajmuje się tworzeniem i wysyłaniem jego zleceń. Szkielet (skeleton) znajduje się po stronie serwera. Szkielet wypełniony kodem implementacji operacji zajmuje się dostarczanie zleceń klienta do implementacji obiektów. Obydwa mechanizmy są tworzone bezpośrednio ze specyfikacji w IDL, są więc specyficzne dla danego interfejsu. Są one wbudowane bezpośrednio w w aplikację klienta i w implementację obiektów. Wiązanie jest statyczne, wołanie operacji jest odwzorowane w wołanie funkcji w odpowiednim języku programowania. Pniak zajmuje się uszeregowaniem (marshal) zlecenia, tj. zamienia je na formę odpowiednią dla transmisji. Serwer ORB i szkielet dokonują operacji odwrotnej (unmarshal), czyli konwersji z postaci transmitowanej do postaci wymaganej przez język programowania. Po wykonaniu zlecenia, odpowiedź jest wysyłana w odwrotną stronę, poprzez szkielet, serwer ORB i pniak, do aplikacji klienta. Pniaki i szkielety

14 © K.Subieta. Systemy rozproszone 6, Folia 14 styczeń 2005 ORB Core, transparency Kluczowa własność ORB - przezroczystość, czyli ukrywanie nieistotnej informacji. Lokalizację obiektu: klient nie potrzebuje wiedzieć, gdzie obiekt jest ulokowany. Implementację obiektu: klient nie potrzebuje wiedzieć, jak obiekt jest zaimplementowany. Stan działania obiektu: klient nie potrzebuje wiedzieć, czy obiekt jest aktywny, gotowy do akceptacji zapytania, czy nie uczestniczy aktualnie w innych procesach. Mechanizmy komunikowania się obiektów: klient nie potrzebuje wiedzieć, jaki mechanizm komunikacyjny jest używany (TCP/IP, wspólna pamięć, lokalne wołanie metod, itd.) ORB ukrywa: Klient może skupić się na problemach związanych z dziedziną aplikacyjną, a nie na problemach realizacyjnych związanych ze środowiskiem komputerowym. Klient może skupić się na problemach związanych z dziedziną aplikacyjną, a nie na problemach realizacyjnych związanych ze środowiskiem komputerowym. CORBA: Rdzeń ORB: przezroczystość

15 © K.Subieta. Systemy rozproszone 6, Folia 15 styczeń 2005 Aby przesłać zlecenie, klient specyfikuje docelowy obiekt poprzez podanie jego referencji. Referencja do obiektu jest tworzona wraz z utworzeniem obiektu i nigdy się nie zmienia, aż do jego skasowania. Referencje są nieczytelne, tj. tylko ORB wie, jak referencje są tworzone, jak również niemodyfikowalne: nie ma żadnej możliwości ich zmiany. Referencje mogą mieć postać standardową: Internet Inter-ORB Protocol (IIOP) Distributed Computing Environment Common Inter-ORB Protocol lub mogą mieć postać specyficzną dla danego ORB, danej aplikacji lub dziedziny. Metody uzyskiwania referencji do obiektów: Tworzenie obiektów: po utworzeniu obiektu klient otrzymuje jego referencję. (CORBA nie ma operacji tworzenia obiektów, należą one do aplikacji.) Usługi w zakresie katalogów: klient może wywołać usługę przeglądania obiektów, patrz wspomniane usługi w zakresie nazw (Name Service) i własności (Trader Service). Zamiana referencji na string i odwrotnie: aplikacja może zamienić referencję na string i zapamiętać w pliku lub bazie danych. Rdzeń ORB: referencje do obiektów object references

16 © K.Subieta. Systemy rozproszone 6, Folia 16 styczeń 2005 object model Obiekt: identyfikowalny, hermetyzowany byt zapewniający jedną lub więcej usług, które mogą być zlecane przez klienta. Zlecenie (request) jest zdarzeniem, tj. czymś, co zachodzi w pewnym punkcie czasowym. Zlecenie może mieć parametry, które są używane do przesyłania danych do obiektu. Zlecenie jest kierowane do obiektu i powoduje wywołanie usługi na rzecz zlecającego. Usługa może zwrócić zlecającemu wynik. Wartość może być parametrem zlecenia; jest ona wystąpieniem typu danych OMG IDL. Wartość, która identyfikuje obiekt, nazywana jest nazwą obiektu. Referencja do obiektu jest wewnętrzną (nieczytelną) nazwą obiektu, która w sposób unikalny identyfikuje pojedynczy obiekt. Wyjątek pojawia się wtedy, gdy zlecenie nie zakończyło się w sposób normalny. Model obiektowy OMG (1)

17 © K.Subieta. Systemy rozproszone 6, Folia 17 styczeń 2005 Obiekty mogą być tworzone, modyfikowane i usuwane poprzez wykonanie odpowiednich zleceń. Typ jest nazwanym zbiorem wartości spełniających pewien warunek. Wartość spełniająca ten warunek jest nazywana członkiem typu. Zbiór wszystkich takich wartości jest nazywany ekstensją typu (type extension). Typ obiektu jest takim typem, którego członkami są obiekty. Dokładniej, typ obiektu jest określony przez typ przechowywanych w nim wartości. Interfejs jest opisem zestawu wszystkich operacji, które klient może zlecać dla obiektu. Interfejsy są definiowane w języku OMG IDL. Interfejs podlega dziedziczeniu (wielo-dziedziczeniu). Interfejs dowolnego obiektu zawiera oprócz własnych operacji wszystkie odziedziczone operacje. Model obiektowy OMG (2)

18 © K.Subieta. Systemy rozproszone 6, Folia 18 styczeń 2005 Operacja zapewnia wykonanie określonej usługi na obiekcie. Operacja posiada sygnaturę, która opisuje parametry zlecenia, zwracaną wartość, możliwość spowodowania wyjątku, dodatkowy kontekst, semantykę wykonania. Parametr operacji jest scharakteryzowany przez typ i tryb. Tryby parametrów: in (wejściowy), out (wyjściowy), inout (wejściowy i wyjściowy) Deklaracja atrybutu jest równoważna deklaracji dwóch operacji: pierwszej, która odczytuje wartość tego atrybutu, i drugiej, która tę wartość zmienia. Model obiektowy OMG (3)

19 © K.Subieta. Systemy rozproszone 6, Folia 19 styczeń 2005 IDL określa typy i interfejsy obiektów, podobnie do klas w C++ lub interfejsów w Java. IDL nic nie mówi o implementacji obiektów i operacji na obiektach. IDL jest kluczem do współdziałania systemów poprzez interfejsy oparte na OMG CORBA. Jest on językiem neutralnym, niezależnym od jakiegokolwiek języka programowania. IDL jest deklaracyjny; zajmuje się wyłącznie specyfikacją obiektów. Jest on potrzebny użytkownikom do dwóch celów: klientom, którzy mogą wywoływać operacje zdefiniowane w IDL, projektantom, którzy mogą rozszerzać istniejące funkcje systemu poprzez specjalizację istniejących interfejsów. OMG IDL Interface Definition Language module Bank { interface Konto {... }; interface Klient {... };.... };

20 © K.Subieta. Systemy rozproszone 6, Folia 20 styczeń 2005 Przykład opisu w IDL Ulubieniec właściciel Zwierzę Specyfikacja wirtualnych zwierzątek: Pies wiek Szczekaj() Usiądź() Warcz() Kot Miaucz() Mrucz() module Moje_Zwierzątka { /* definicja interfejsu dla psa */ interface Pies: Ulubieniec, Zwierzę { readonly attribute integer wiek; exception NieReaguje{string dlaczego}; void Szczekaj( in short jak_długo) raises (NieReaguje); void Usiądź( in string gdzie ) raises (NieReaguje); void Warcz(in string na_kogo) raises (NieReaguje); }; /* definicja interfejsu dla kota */ interface Kot: Zwierzę { void Miaucz( in short ile_razy ) raises (NieReaguje); void Mrucz( in short jak_długo ) raises (NieReaguje); };

21 © K.Subieta. Systemy rozproszone 6, Folia 21 styczeń 2005 Osoba Imię Nazwisko Data_Urodzenia wiek() Kierowca Punkty_Karne Numer_Prawa_Jazdy Wykroczenie(..) interface Osoba { attribute string Imię; attribute string Nazwisko; attribute long Data_Urodzenia; short Wiek( void );... }; interface Kierowca : Osoba { attribute short Punkty_Karne; attribute long Numer_Prawa_Jazdy; exception Odebranie_Prawa_Jazdy {... string Przyczyna;... }; void Wykroczenie(in short punkty ) raises( Odebranie_Prawa_Jazdy );... }; OMG IDL - inny przykład

22 © K.Subieta. Systemy rozproszone 6, Folia 22 styczeń 2005 interface Konto{ readonly attribute float bilans; void zmień_bilans( in float wartość); }; interface SprawdzKonto : Konto attribute float LimitPrzekroczKonta; }; interface Bank{ Konto NoweKonto( in string nazwisko) ; SprawdzKonto SprawdzNowe( in string nazwisko ); void UsuńKonto( in Konto konto_klienta ); }; IDL: jeszcze inny przykład

23 © K.Subieta. Systemy rozproszone 6, Folia 23 styczeń 2005 Moduły (modules) są zbiorami interfejsów zgrupowanych pod jedną nazwą. Moduł wyznacza zakres nazw: nazwy wewnątrz modułu nie kolidują z nazwami z innych modułów. Nazwa z wnętrza modułu musi być kwalifikowana nazwą modułu, np. Bank :: Konto Interfejs definiuje zbiór operacji, które klient może wywoływać w stosunku do obiektu. Jest to specyfikacja obiektu, która opisuje metody, parametery metod, typy danych i wyjątki. Interfejs nie zawiera implementacji. Interfejs może mieć atrybuty i każdy z tych atrybutów posiada automatycznie dwie metody get (daj wartość) oraz set (podstaw wartość). Atrybut może być readonly (tylko do czytania). Interfejs może być definiowany z użyciem dziedziczenia (inheritance) lub wielo- dziedziczenia (multiple-inheritance). OMG IDL: pojęcia (1)

24 © K.Subieta. Systemy rozproszone 6, Folia 24 styczeń 2005 OMG IDL: pojęcia (2) Wyjątki służą do obsługi błędów (mogą mieć także inne zastosowania). Możliwe są dwa typy wyjątków: wyjątki systemowe (standardowe dla CORBA) oraz wyjątki użytkownika (definiowane w specyfikacji IDL). Wyjątek jest strukturą danych zawierającą atrybuty informujące np. o przyczynach powstania wyjatku. Kontekst jest to obiekt zawierający listę własności specyficznych dla klienta. Jest to dodatkowy parametr operacji pozwalający np. ustalić, który klient żąda danej usługi. Operacja jest elementem proceduralnym, którą klient może zastosować w stosunku do obiektu. Sygnatura operacji specyfikuje jej nazwę, typ wyniku, nazwy i typy parametrów, tryb określający, czy parametr jest wejściowy czy wyjściowy, oraz nazwę wyjątku skojarzoną ew. z lokalnym kontekstem klienta. Domyślnie wykonywanie operacji jest synchroniczne, tj. po wywołaniu operacji aplikacja klienta czeka na jej zakończenie. Możliwe są inne tryby wykonywania operacji (oneway). Typ danych używany do opisu wartości parametrów, atrybutów i zwracanych wartości.