Standardy w zakresie systemów rozproszonych i baz danych

K.Subieta. SSR, Wykład 2, Folia 1 marzec 2009

Standardy w zakresie systemów rozproszonych i baz danych

Kazimierz Subieta

Polsko-Japońska Wyższa SzkołaTechnik Komputerowych, Warszawa

Wykład 2:

Wprowadzenie do OMG CORBA


CORBA: schemat wywoływania dynamicznego

Host klienta

KlientKlient

Wywołanieoperacji

Host serwera

ObiektObiekt

Pośrednik (ORB, Object Request Broker)

Klient wysyła zlecenia poprzez DII (Dynamic Invocation Interface), niezależnie od IDL (korzystając np. z repozytorium interfejsów).

Interfejs do obiektu po stronie serwera musi być zaimplementowany w postaci dynamicznie wiązanych operacji (a la DLL). Dynamiczny kod powstaje z dynamicznego szkieletu interfejsu do obiektu, który jest następnie wypełniany kodem implementacji operacji.

DII

Dynamiczna implementacja

interfejsu(szkielet + kod)

zlecenie

wynik, parametry wyj


Wołania poprzez pniaki i szkielety jest statyczne, tj. odpowiednie fragmentykodu są wprowadzane do aplikacji podczas kompilacji.

DII (Dynamic Invocation Interface) umożliwia dynamiczne wywołanie zleceniado obiektu od strony klienta (podobnie do pniaka, generic stub).

DII (Dynamic Invocation Interface) umożliwia dynamiczne wywołanie zleceniado obiektu od strony klienta (podobnie do pniaka, generic stub).

DSI (Dynamic Skeleton Interface) umożliwia dynamiczne przekazanie zlecenia do obiektu od strony serwera (podobnie do szkieletu, generic skeleton).

DSI (Dynamic Skeleton Interface) umożliwia dynamiczne przekazanie zlecenia do obiektu od strony serwera (podobnie do szkieletu, generic skeleton).

Nie zależą one od interfejsów w IDL. Klient nie musi podczas kompilacji znać interfejsy do obiektów. Może je ustalić dynamicznie, poprzez generyczną funkcjęcreate_request, należącą do interfejsu Object, oraz Repozytorium Interfejsów.

Tego rodzaju udogodnienie jest szczególnie ważne dla niektórych aplikacji, takich jak przeglądarki, które muszą przejrzeć aktualnie dostępne obiekty bez wiedzy, jakie one są, jak są zbudowane i jakie mają interfejsy.

Tego rodzaju udogodnienie jest szczególnie ważne dla niektórych aplikacji, takich jak przeglądarki, które muszą przejrzeć aktualnie dostępne obiekty bez wiedzy, jakie one są, jak są zbudowane i jakie mają interfejsy.

Wołania dynamiczne


Wołanie synchroniczne: Klient wywołuje zlecenie i następnie czeka na odpowiedź. Zachowanie się jest identyczne do RPC (Remote Procedure Call). Ten tryb wołania jest także cechą statycznych pniaków i szkieletów.

Wołanie synchroniczne: Klient wywołuje zlecenie i następnie czeka na odpowiedź. Zachowanie się jest identyczne do RPC (Remote Procedure Call). Ten tryb wołania jest także cechą statycznych pniaków i szkieletów.

Opóźnione wołanie synchroniczne: Klient wywołuje zlecenie, ale po tym kontynuuje przetwarzanie, podczas gdy zlecenie jest przekazywane do obiektu. Odpowiedź od obiektu jest zbierana i przetwarzana później. Klient może równolegle wysłać wiele zleceń dla uruchomienia niezależnie wielu długo trwających aplikacji.

Opóźnione wołanie synchroniczne: Klient wywołuje zlecenie, ale po tym kontynuuje przetwarzanie, podczas gdy zlecenie jest przekazywane do obiektu. Odpowiedź od obiektu jest zbierana i przetwarzana później. Klient może równolegle wysłać wiele zleceń dla uruchomienia niezależnie wielu długo trwających aplikacji.

Wywołanie w jedną stronę (oneway): Klient wywołuje zlecenie i nie czeka na odpowiedź. Ta forma jest często nazywana “fire and forget”. Klient może stwierdzić rezultat w inny sposób, np. poprzez wysłanie kolejnego zlecenia.

Wywołanie w jedną stronę (oneway): Klient wywołuje zlecenie i nie czeka na odpowiedź. Ta forma jest często nazywana “fire and forget”. Klient może stwierdzić rezultat w inny sposób, np. poprzez wysłanie kolejnego zlecenia.

Rodzaje wołań dynamicznych


Tak samo jak DII pozwala na dostęp do obiektów bez dostępu do statycznych pniaków, DSI umożliwia implementację strony serwera bez statycznej wiedzy zawartej w szkielecie.

Tak samo jak DII pozwala na dostęp do obiektów bez dostępu do statycznych pniaków, DSI umożliwia implementację strony serwera bez statycznej wiedzy zawartej w szkielecie.

Zastosowania podobne, np. przeglądarka. Taka aplikacja wymaga dynamicznego dostępu do operacji na obiekcie. Nie jest akceptowalna ponowna kompilacja części serwera po każdej zmianie zestawu, struktury lub interfejsów obiektów.

Własność ta jest dostępna w CORBA 2.0. Pewnym problemem okazało się zapewnienie współpracy z wieloma protokołami komunikacyjnymi. Własność jest istotna dla budowy pomostów (gateways) pomiędzy oprogramowaniem nie bazującym na CORBA, np. Microsoft COM/DCOM.

DSI: Dynamiczny szkielet


ORB Core, transparency

Kluczowa własność ORB - przezroczystość, czyli ukrywanie nieistotnej informacji. 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: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ść


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.

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: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ówobject references


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)


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 dowolnegoobiektu zawiera oprócz własnych operacji wszystkie odziedziczone operacje.



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.

Składnia sygnatury: [oneway] <op_type_spec> <identifier> (param1,...,paramL) [raises(except1,...,exceptN)][context(name2,...,nameM)] oneway: zlecający nie czeka na wynik. context: ustala dodatkową informację specyficzną dla danej operacji.

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.



Wartość

Referencja do obiektu Wartość konstruowana

Wartość bazowa Struct Sequence Union Array

Short Long UShort Ulong Float Double Char String Boolean Octet Enum Any

Model obiektowy OMG: zestawienie typów


Wady modelu obiektowego CORBA Po zaadoptowaniu standardu UML okazało się, że

modele obiektowe CORBA i UML „rozjechały się”. Przyczyną jest to, że CORBA była opracowana przez

środowisko języków programowania, zaś UML przez środowisko analizy i projektowania systemów.

Dotyczy to wielu kwestii, z których najważniejsze są następujące:– Kolekcje – występują w CORBA w formie uproszczonej

(sekwencje) oraz w formie specjalnej usługi– Asocjacje – występują w formie uproszczonej (pointerów)

oraz w formie specjalnej usługi, która jest dość ciężka do użycia.

Dodatkową wadą jest brak odniesień do baz danych (brak bazodanowych struktur, brak języka zapytań).– Również są odpowiednie usługi (persistency service, query

service), ale to nie jest efektywne.


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 IDLInterface Definition Language

module Bank {interface Konto { ... };interface Klient { ... };....

};


Przykład opisu w IDL

Ulubieniecwłaściciel

Zwierzę

Specyfikacja wirtualnych zwierzątek:

PieswiekSzczekaj()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); };};


OsobaImięNazwiskoData_Urodzeniawiek()

KierowcaPunkty_KarneNumer_Prawa_JazdyWykroczenie(..)

interface Osoba { attribute string<20> Imię;attribute string<30> 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<80> Przyczyna; ... };void Wykroczenie(in short punkty ) raises( Odebranie_Prawa_Jazdy ); ... };

OMG IDL - inny przykład


interface Konto{readonly attribute float bilans;void zmień_bilans( in float wartość);

};

interface SprawdzKonto : Kontoattribute 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


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, parametry 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)


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 liste 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.


32-bitowe typy arytmetyczne64-bitowe typy arytmetyczne16-bitowe typy arytmetyczneIEEE 754-1985 typy zmienno-przecinkowetyp znakowe i szeroko-znakowetyp boolowski8-bitowa wartość (nie zmienialna przy transmisji)typy wyliczeniowetyp, który może charakteryzować dowolną wartość

Specyfikacja CORBA określa rozmiary wszystkich typów bazowych, dla zapewnienia współdziałania pomiędzy heterogenicznymi platformami.

Specyfikacja CORBA określa rozmiary wszystkich typów bazowych, dla zapewnienia współdziałania pomiędzy heterogenicznymi platformami.

long (signed and unsigned)long long (signed and unsigned)

short (signed and unsigned)float, double, long double

char , wcharboolean

octetenum

any

IDL: typy wbudowane

enum Waluta {złoty, frank, dolar, funt};

Przykład typu wyliczeniowego:

Standardy w zakresie systemów rozproszonych i baz danych

Documents

Transcript of Standardy w zakresie systemów rozproszonych i baz danych