K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 3, 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 3: Wprowadzenie do OMG CORBA

K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 3, Folia 2 listopad 1999 interface inheritance //OMG IDL interface Factory { Object create(); }; interface Spreadsheet; // Pominięto resztę specyfikacji // SpreadsheetFactory jest definiowana na podstawie Factory: interface SpreadsheetFactory : Factory { Spreadsheet create_spreadsheet(); }; SpreadsheetFactory dziedziczy z Factory; czyli obiekt, którego interfejs jest określony poprzez SpreadsheetFactory zapewnia dwie operacje: - create, odziedziczoną od Factory - create_spreadsheet, zdefiniowaną w SpreadsheetFactory Zasada Otwarte-Zamknięte (Open-Close): - otwarte dla rozszerzeń - zamknięte dla modyfikacji Zasada Otwarte-Zamknięte (Open-Close): - otwarte dla rozszerzeń - zamknięte dla modyfikacji Zasada zamienialności (substitutability): referencja do obiektu specjalizowanego może być użyta wszędzie tam, gdzie może być użyta referencja do obiektu bazowego. Zasada zamienialności (substitutability): referencja do obiektu specjalizowanego może być użyta wszędzie tam, gdzie może być użyta referencja do obiektu bazowego. CORBA woprowadza specjalny intrfejs Object z którego automatycznie dziedziczą wszystkie inne interfejsy. CORBA woprowadza specjalny intrfejs Object z którego automatycznie dziedziczą wszystkie inne interfejsy. IDL: dziedziczenie interfejsów

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

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

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

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

K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 3, Folia 7 listopad 1999 Struktura repozytorium interfejsów Repository ModuleDef InterfaceDef ConstantDefExceptionDefOperationDefAttributeDefTypedefDef Powiązane obiekty, zorganizowane tak, jak na poniższym rysunku. Każdy obiekt przechowuje informacje o odpowiednim elemencie wyrażenia IDL. Nawigacja od obiektu do obiektu - zgodnie ze strzałkami. Np. po donawigowaniu do InterfaceDef pewnego interfejsu można nawigować do AttributeDef zdefiniowanego w ramach tego interfejsu.

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

K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 3, Folia 9 listopad 1999 Repozytorium Interfejsów Pniaki Szkielety Repozytorium Implementacji Klient Implementacja obiektów Instalacja implementacji Definicje w IDL Repozytoria interfejsów i implementacji

K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 3, Folia 10 listopad 1999 Object Adapters Adapter obiektów skleja implementację obiektów CORBA z samym ORB. Taki adapter jest sam obiektem, który adoptuje interfejs innego obiektu do postaci, która jest akceptowalna dla wołającego. Wołający Adapter obiektu Obiekt Interfejs A Interfejs X Wołający oczekuje interfejsu A Adapter obiektu adoptuje interfejs X do interfejsu A Obiekt zapewnia interfejs X Adaptery obiektów

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

K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 3, Folia 12 listopad 1999 CORBA definiuje BOA, Basic Object Adapter. POA, Portable Object Adapter, jest nowszą wersją BOA, w której usunięto błędy i niedoróbki BOA. Mogą być inne adaptery obiektów, specyficzne dla języka programowania. Funkcje BOA/POA: Generacja i interpretacja referencji do obiektów. Autentyfikacja subiektu, który wywołał metodę Aktywacja i deaktywacja implementacji Aktywacja i deaktywacja indywidualnych obiektów Wywołanie metod poprzez szkielety Rdzeń ORB BOA/POA Szkielet 1.Aktywacja implementacji Implementacja obiektów 2.Rejestracja implementacji 3.Aktywacja obiektów 4. Wołanie metod 5.Dostęp do serwisów Metody BOA i POA Basic Object Adapter, Portable Object Adapter

K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 3, Folia 13 listopad 1999 Zadaniem osłon jest: - istniejących aplikacji spadkowych (legacy) - komercyjnych aplikacji Hermetyzacja aplikcji: Rozdzielenie aplikacji w zbiór usług, które są udostępnione z zewnątrz apliakcji Zapewnienie dostępu do tych usług jako implementacji interfejsów CORBA. Inne terminy: adaptery klienta (client adapters) osłony serwera (server wrapper) Osłony przystosowują aplikacje spadkowe do interfejsów standardu CORBA. Aplikacja spadkowa Osłona CORBA (ORB) Co to są osłony? wrappers

K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 3, Folia 14 listopad 1999 Wielo-funkcyjna aplikacja spadkowa Osłona CORBA (ORB) Serwer Aplikacja spadkowa w postaci wielu serwerów Aplikacja może być logicznie podzielona; aplikacja może być klientem i serwerem Wielo-funkcyjna aplikacja spadkowa Osłona CORBA (ORB) Serwer Aplikacja Osłona Klient Osłona: różne architektury

K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 3, Folia 15 listopad 1999 inner and outer wrapper C O R B A Osłona zewnętrzna (często określona przez wymagania zewnętrznego interfejsu, np. charakter biznesu) Dostęp do danych Dostęp do danych Dostęp do API Emulacja terminalu ekranowego Aplikacja spadkowa Baza danych Kod aplikacji Interfejs użytkownika Osłona wewnętrzna (specyficzna dla aplikacji) Osłona wewnętrzna i zewnętrzna

K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 3, Folia 16 listopad 1999 Aplikacja może mieć jedną lub wiele osłon - jedną dla metody - jedną dla klasy - jedną dla grupy ściśle związanych implementacji - jedną dla aplikacji Powody różnych decyzji: - efektywność - konieczność posiadania wspólnego kodu lub stanu - potrzeba wspólnych zasobów - pakiety komercyjne Grupowanie implementacji w osłony

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

K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 3, Folia 18 listopad 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 znajdujewłaściwą implementację PodajZarobekPrac Kowalski przydziela metodę aktywuje Adapter obiektu Scenariusz zarządzania obiektami (2)

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

K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 3, Folia 20 listopad 1999 Z punktu widzenia klienta, obiekt jest dostępny poprzez ORB z użyciem referencji Pojedyńczy obiekt może mieć wiele referencji (nie zalecane). Porównanie referencji nie jest zdefiniowane i nie jest zalecane. Referencja może być NULL Referencja jest nieczytelna (opaque), ale można dokonać konwersji na string i spowrotem Dane referencyjne (klucz relacji, Pesel, etc.) są sekwencją do 1024 bajtów. Id interfejsu Dane referencyjne Id implementacji Referencje do obiektu nie sa tym samym co OID: - mogą nie być unikalne - OID wymaga centralnego zarządzania (rozstrzyganie unikalności), co może powodować wąskie gardła - OID nie jest wygodny dla zastosowań spadkowych Referencje do obiektu nie sa tym samym co OID: - mogą nie być unikalne - OID wymaga centralnego zarządzania (rozstrzyganie unikalności), co może powodować wąskie gardła - OID nie jest wygodny dla zastosowań spadkowych Budowa referencji (efektywnie unikalna): Wyszukiwanie referencji - np. poprzez serwis nazwowy. Referencje

K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 3, Folia 21 listopad 1999 Zalety statycznego wołania metod: Łatwiejsze do programowania: odległa metoda jest wołana w programie tak samo jak metoda lokalna, z taką samą techniką określania prarametrów. Jest to naturalna forma programowania. Skuteczna kontrola typu: jest wykonywana podczas czasu kompilacji. Dobra wydajność: analiza składniowa, kontrola typu i wiązanie są wykonane podczas czasu kompilacji, nie muszą one być wykonywane dynamicznie. Samo-dokumentacja: programy są czytelne i łatwo zrozumiałe. Zalety dynamicznego wołania metod: Elastyczność: możliwość reakcji na dynamiczne zmiany w środowisku obiektów, np. dodanie nowego interfejsu. Generyczność: możliwość programowania aplikacji ogólnych, działających na dowolnym środowisku obiektów i interfejsów, takich jak. np. przeglądarka obiektów. Statyczne vs. dynamiczne wołania metod

K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 3, Folia 22 listopad 1999 Mechanizm refleksji Wołania dynamiczne są oparte o mechanizm okreslany jako refleksja. Refleksja posiada dwa aspekty: l Możliwość dynamicznego ustalenia (podczas działania programu) jego meta- danych. Np. można dynamicznie dowiedzieć się jaki jest typ danej zmiennej, mozna ustalić jakie typy lub interfejsy są obecnie zdefiniowane w systemie, itd. l Możliwość dynamicznego użycia tych informacji w programie, np. skomponowania fragmentu programu (np. w postaci stringu) i następnie wykonanie go w tym samym programie Refleksja jest ważną cechą umożliwiającą tworzenie oprogramowania generycznego (niezależnego od konkretnej aplikacji) i oprogramowania systemowego. Refleksja jest szeroko wykorzystywana przy tworzeniu kompilatorów języków programowania, systemów operacyjnych, systemów zarządzania bazami danych, systemów przetwarzania rozproszonego. Najwcześniejszym językiem z refleksją jest Lisp. Pewne (ograniczone) możliwości refleksji posiada Java. Wariant refleksji został wykorzystany w dynamicznym SQL. reflection