K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 2, Folia 1 listopad 1999 Bazy danych i inżynieria oprogramowania Kazimierz Subieta Instytut.

Prezentacja na temat: "K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 2, Folia 1 listopad 1999 Bazy danych i inżynieria oprogramowania Kazimierz Subieta Instytut."— Zapis prezentacji:

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

2 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 2, Folia 2 listopad 1999 CORBA: schemat wywoływania dynamicznego Host klienta Klient Wywołanie operacji Host serwera Obiekt 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

3 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 2, Folia 3 listopad 1999 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). 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). 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. Wołania dynamiczne

4 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 2, Folia 4 listopad 1999 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. 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

5 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 2, Folia 5 listopad 1999 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

6 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 2, Folia 6 listopad 1999 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ść

7 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 2, Folia 7 listopad 1999 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

8 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 2, Folia 8 listopad 1999 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. Model obiektowy OMG (1)

9 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 2, Folia 9 listopad 1999 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)

10 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 2, Folia 10 listopad 1999 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] (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. Model obiektowy OMG (3)

11 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 2, Folia 11 listopad 1999 Wartość Referencja do obiektuWartość konstruowana Wartość bazowaStructSequenceUnionArray Short Long UShort Ulong Float Double Char String Boolean Octet Enum Any Model obiektowy OMG: zestawienie typów

12 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 2, Folia 12 listopad 1999 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 {... };.... };

13 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 2, Folia 13 listopad 1999 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); };

14 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 2, Folia 14 listopad 1999 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

15 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 2, Folia 15 listopad 1999 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

16 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 2, Folia 16 listopad 1999 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)

17 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 2, Folia 17 listopad 1999 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 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 2, Folia 18 listopad 1999 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. long (signed and unsigned) long long (signed and unsigned) short (signed and unsigned) float, double, long double char, wchar boolean octet enum any IDL: typy wbudowane enum Waluta {złoty, frank, dolar, funt}; Przykład typu wyliczeniowego:

19 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 2, Folia 19 listopad 1999 constructed types, template types Typy konstruowane: Typy wzorcowe: 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++. string i wstring - typy stringowe i stringowe z rozszerzonym zakresem znaków string - 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 - dowolnie długa sekwencja referencji do obiektów Factory, sequence - sekwencja stringów ograniczona do max 10-ciu IDL: typy konstruowane, typy wzorcowe

20 K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 2, Folia 20 listopad 1999 //OMG IDL interface FactoryFinder { // definicja sekwencji referencji do obiektów Factory typedef sequence 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 Operacja find_factories jest jedną ze standardowych operacji w ramach OMG Common Object Services Lifecycle Specification IDL: typy referencji do obiektów