Bazy danych i inżynieria oprogramowania

1. Bazy danych i inżynieria oprogramowania Wykład 2: Wprowadzenie do OMG CORBA Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa

2. CORBA: schemat wywoływania dynamicznego Host klienta Host serwera Klient Obiekt Dynamiczna implementacja interfejsu (szkielet + kod) Wywołanie operacji zlecenie DII Pośrednik (ORB, Object Request Broker) wynik, parametry wyj 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.

3. Wołania dynamiczne Wołania poprzez pniaki i szkielety jest statyczne, tj. odpowiednie fragmenty kodu są wprowadzane do aplikacji podczas kompilacji. DII (Dynamic Invocation Interface) umożliwia dynamiczne wywołanie zlecenia do 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). 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.

4. Rodzaje wołań dynamicznych 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. 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.

5. DSI: Dynamiczny szkielet 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.

6. CORBA: Rdzeń ORB: przezroczystość ORB Core, transparency Kluczowa własność ORB - przezroczystość, czyli ukrywanie nieistotnej informacji. ORB ukrywa: • 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.) Klient może skupić się na problemach związanych z dziedziną aplikacyjną, a nie na problemach realizacyjnych związanych ze środowiskiem komputerowym.

7. Rdzeń ORB: referencje do obiektów object references 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.

8. Model obiektowy OMG (1) 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 ientyfikuje 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.

9. Model obiektowy OMG (2) 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.

10. Model obiektowy OMG (3) 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óchoperacji: pierwszej, która odczytuje wartość tego atrybutu, i drugiej, która tę wartość zmienia.

11. Model obiektowy OMG: zestawienie typów Wartość Referencja do obiektu Wartość konstruowana Wartość bazowa Struct Sequence Union Array Short Long UShort Ulong Float Double Char String Boolean Octet Enum Any

12. OMG IDL Interface Definition Language • 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. 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. module Bank { interface Konto { ... }; interface Klient { ... }; .... };

13. Przykład opisu w IDL Pies wiek Szczekaj() Usiądź() Warcz() Kot Miaucz() Mrucz() Specyfikacja wirtualnych zwierzątek: 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); }; }; Ulubieniec właściciel Zwierzę

14. OMG IDL - inny przykład interface Osoba { Osoba Imię Nazwisko Data_Urodzenia wiek() 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 ); ... }; Kierowca Punkty_Karne Numer_Prawa_Jazdy Wykroczenie(..)

15. IDL: jeszcze inny przykład interface Konto{ readonly attribute float bilans; void zmień_bilans( in float wartość); }; interface SprawdzKonto : Konto attribute float LimitPrzekroczKonta; }; interface Bank{ KontoNoweKonto( in string nazwisko) ; SprawdzKontoSprawdzNowe( in string nazwisko ); void UsuńKonto( in Kontokonto_klienta ); };

16. OMG IDL: pojęcia (1) 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).

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

18. IDL: typy wbudowane long (signed and unsigned) long long (signed and unsigned) short (signed and unsigned) float, double, long double char , wchar boolean octet enum any 32-bitowe typy arytmetyczne 64-bitowe typy arytmetyczne 16-bitowe typy arytmetyczne IEEE 754-1985 typy zmienno-przecinkowe typ znakowe i szeroko-znakowe typ boolowski 8-bitowa wartość (nie zmienialna przy transmisji) typy wyliczeniowe typ, 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. Przykład typu wyliczeniowego: enum Waluta {złoty, frank, dolar, funt};

19. IDL: typy konstruowane, typy wzorcowe constructed types, template types Typy konstruowane: struct - agregacja danych podobna do struct w C/C++ union - rozłączna unia typów, j.w., ewentualnie z dyskryminatorem umożliwiającym dynamiczne rozróżnienie typu wartości. Pojęcie unii jest identyczne z podobnym pojęciem w C/C++. Typy wzorcowe: string i wstring - typy stringowe i stringowe z rozszerzonym zakresem znaków string<10> - ograniczenie do 10-ciu znaków string - brak ograniczenia długości sequence - liniowy kontener o ograniczonej lub nieograniczonej długości. Typ elementu i ograniczenie - w nawiasach trójkątnych, np. sequence<Factory> - dowolnie długa sekwencja referencji do obiektów Factory, sequence<string,10> - sekwencja stringów ograniczona do max 10-ciu

20. IDL: typy referencji do obiektów Operacja find_factories jest jedną ze standardowych operacji w ramach OMG Common Object Services Lifecycle Specification //OMG IDL interface FactoryFinder { // definicja sekwencji referencji do obiektów Factory typedef sequence<Factory> FactorySeq; FactorySeq find_factories ( in string interface_name ); }; FactorySeq - nieograniczona sekwencja referencji do obiektów Factory find_factories - operacja, która bierze jako parametr nieograniczony string i zwraca jako rezutat taką sekwencję referencji