Transcript Bazy danych i inżynieria oprogramowania

Bazy danych i inżynieria oprogramowania
Wykład 3:
Wprowadzenie do
OMG CORBA
Kazimierz Subieta
Instytut Podstaw Informatyki PAN,
Warszawa
Polsko-Japońska Wyższa Szkoła
Technik Komputerowych, Warszawa
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 3, Folia 1
listopad 1999
IDL: dziedziczenie interfejsów
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();
};
CORBA woprowadza
specjalny intrfejs
Object
z którego automatycznie
dziedziczą wszystkie inne
interfejsy.
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
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 3, Folia 2
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.
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 3
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 4
listopad 1999
IDL: odwzorowania językowe
language mappings
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.
Przykładowe
odwzorowanie
IDL do C++:
OMG IDL
long, short,...
any
string, wstring
sequence
referencja do obiektu
interface
operation
module
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 3, Folia 5
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
listopad 1999
Repozytorium interfejsów
Interface Repository
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.
Zastosowanie tego udogodnienia jest istotne dla wołań dynamicznych.
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 3, Folia 6
listopad 1999
Struktura repozytorium interfejsów
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.
Repository
ModuleDef
InterfaceDef
AttributeDef
OperationDef
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 3, Folia 7
ExceptionDef
TypedefDef
ConstantDef
listopad 1999
Repozytorium implementacji
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 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.
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 3, Folia 8
listopad 1999
Repozytoria interfejsów i implementacji
Definicje w
IDL
Repozytorium
Interfejsów
Pniaki
Pniaki
Pniaki
Klient
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 3, Folia 9
Instalacja
implementacji
Szkielety
Szkielety
Szkielety
Repozytorium
Implementacji
Implementacja obiektów
listopad 1999
Adaptery obiektów
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.
Interfejs A
Wołający
Wołający oczekuje
interfejsu A
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 3, Folia 10
Adapter
obiektu
Adapter obiektu
adoptuje interfejs X
do interfejsu A
Interfejs X
Obiekt
Obiekt zapewnia
interfejs X
listopad 1999
Role adapterów obiektów ost.14.10
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.
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 3, Folia 11
listopad 1999
BOA i POA
Basic Object Adapter, Portable Object Adapter
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
Metody
Implementacja obiektów
1.Aktywacja
implementacji
2.Rejestracja
implementacji
3.Aktywacja
obiektów
4. Wołanie
metod
BOA/POA
5.Dostęp do
serwisów
Szkielet
Rdzeń ORB
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 3, Folia 12
listopad 1999
Co to są “osłony”?
wrappers
Inne terminy:
Zadaniem osłon jest:
adaptery klienta (client adapters)
osłony serwera (server wrapper)
• Hermetyzacja aplikcji:
- istniejących aplikacji “spadkowych” (legacy)
- komercyjnych aplikacji
• 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.
Osłony przystosowują aplikacje spadkowe do interfejsów standardu CORBA.
Aplikacja spadkowa
Osłona
CORBA (ORB)
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 3, Folia 13
listopad 1999
Osłona: różne architektury
Wielo-funkcyjna aplikacja spadkowa
Osłona
Serwer
Serwer
Serwer
Aplikacja
spadkowa
w postaci
wielu
serwerów
CORBA (ORB)
Wielo-funkcyjna aplikacja spadkowa
Aplikacja
Osłona
Osłona
Serwer
Serwer
CORBA (ORB)
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 3, Folia 14
Serwer
Klient
Aplikacja
może być
logicznie
podzielona;
aplikacja
może być
klientem i
serwerem
listopad 1999
Osłona wewnętrzna i zewnętrzna
inner and outer wrapper
C
O
R
B
A
Osłona
zewnętrzna
Osłona
wewnętrzna
(często
określona
przez
wymagania
zewnętrznego
interfejsu,
np.
charakter
biznesu)
(specyficzna
dla aplikacji)
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 3, Folia 15
Dostęp
do danych
Aplikacja
spadkowa
Baza danych
Dostęp do
API
Emulacja
terminalu
ekranowego
Kod
aplikacji
Interfejs
użytkownika
listopad 1999
Grupowanie implementacji w osłony
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
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 3, Folia 16
listopad 1999
Scenariusz zarządzania obiektami (1)
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ę.
Obiekty pracowników
Kowalsk
i
Nowak
Referencje do obiektów
odsyła do
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 3, Folia 17
referencja1
referencja2
Implementacja
obiektów
listopad 1999
Scenariusz zarządzania obiektami (2)
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
przydziela metodę
ORB
znajdujewłaściwą
implementację
Adapter
obiektu
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 3, Folia 18
aktywuje
PodajZarobekPrac
Kowalski
listopad 1999
Scenariusz zarządzania obiektami (3)
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.
Implementacja obiektu
Klient
ORB
wynik 3000 PLN
PodajZarobekPrac
Kowalski
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 3, Folia 19
listopad 1999
Referencje
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):
Id interfejsu Dane referencyjne Id implementacji
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.
Wyszukiwanie referencji - np. poprzez serwis nazwowy.
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 3, Folia 20
listopad 1999
Statyczne vs. dynamiczne wołania metod
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.
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 3, Folia 21
listopad 1999
Mechanizm refleksji
reflection
Wołania dynamiczne są oparte o mechanizm okreslany jako refleksja.
Refleksja posiada dwa aspekty:

Możliwość dynamicznego ustalenia (podczas działania programu) jego metadanych. Np. można dynamicznie dowiedzieć się jaki jest typ danej zmiennej,
mozna ustalić jakie typy lub interfejsy są obecnie zdefiniowane w systemie, itd.

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.
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 3, Folia 22
listopad 1999