Transcript Bazy danych i inżynieria oprogramowania
Standardy w zakresie systemów rozproszonych i baz danych
Wykład 3:
Wprowadzenie do OMG CORBA
Kazimierz Subieta
Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa K.Subieta. SSR, Wykład 3, Folia 1 marzec 2009
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
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
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 rezultat taką sekwencję referencji K.Subieta. SSR, Wykład 3, Folia 3 marzec 2009
IDL: dziedziczenie interfejsów
interface inheritance
//OMG IDL
interface
Factory { Object create(); };
interface
Spreadsheet; // Pominięto resztę specyfikacji CORBA wprowadza specjalny interfejs
Object
z którego automatycznie dziedziczą wszystkie inne interfejsy.
// 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
K.Subieta. SSR, Wykład 3, Folia 4 marzec 2009
Zasady związane z dziedziczeniem
Zasada
Otwarte-Zamknięte
(
Open-Close
):
– –
otwarte
dla rozszerzeń
zamknięte
dla modyfikacji – Np. Można zamknąć i skompilować klasę Osoba, a następnie wprowadzić nową specjalizowaną klasę Student dziedziczącą z klasy Osoba.
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.
– Np. obiekt Student może być użyty wszędzie tam, gdzie może być użyty obiekt Osoba.
K.Subieta. SSR, Wykład 3, Folia 5 marzec 2009
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 union
SData {
short
Data
switch
( dzień, miesiąc, rok;};
short
) {
case case
1 : 2 :
default string long
formatNapisu; formatCyfrowy; : SData formatStruktury; }; K.Subieta. SSR, Wykład 3, Folia 6 marzec 2009
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
/* ostatnie 10 wpłat, data i nazwa wpłacającego */
interface
DaneWpłat[10][2]; /* synonim typu */ Konto {
readonly attribute
DaneWpłat wpłaty; ...
}; }; Stałe:
const string
AUTOR = “Jan Nowak”;
const long
MAX_ILOŚĆ_KONT = 10000; K.Subieta. SSR, Wykład 3, Folia 7 marzec 2009
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++: K.Subieta. SSR, Wykład 3, Folia 8 OMG IDL long, short,...
any string, wstring sequence referencja do obiektu interface operation module 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 marzec 2009
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. SSR, Wykład 3, Folia 9 marzec 2009
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 nawigacji do InterfaceDef pewnego interfejsu można nawigować do AttributeDef zdefiniowanego w ramach tego interfejsu.
Repository ModuleDef InterfaceDef AttributeDef OperationDef ExceptionDef TypedefDef ConstantDef
K.Subieta. SSR, Wykład 3, Folia 10 marzec 2009
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 funkcjonowania 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. SSR, Wykład 3, Folia 11 marzec 2009
Repozytoria interfejsów i implementacji
Definicje w IDL Instalacja implementacji Repozytorium Interfejsów Pniaki Pniaki Szkielety Szkielety Repozytorium Implementacji Implementacja obiektów Klient
K.Subieta. SSR, Wykład 3, Folia 12 marzec 2009
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 Interfejs X Wołający Wołający oczekuje interfejsu A K.Subieta. SSR, Wykład 3, Folia 13 Adapter obiektu Adapter obiektu adoptuje interfejs X do interfejsu A Obiekt Obiekt zapewnia interfejs X marzec 2009
Role adapterów obiektów
Rejestracja obiektów
języka programowania.
: 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
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 nadejścia 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. SSR, Wykład 3, Folia 14 marzec 2009
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 1.Aktywacja
implementacji
Implementacja obiektów
2.Rejestracja
implementacji 3.Aktywacja
obiektów
Metody
4. Wołanie metod 5.Dostęp do serwisów
BOA/POA
Rdzeń ORB Szkielet
K.Subieta. SSR, Wykład 3, Folia 15 marzec 2009
Co to są “osłony”?
wrappers
Zadaniem osłon jest: Inne terminy: adaptery klienta (
client adapters
) osłony serwera (
server wrapper
) • Hermetyzacja aplikacji: - istniejących aplikacji “spadkowych” (
legacy
) - komercyjnych aplikacji • Rozdzielenie aplikacji w zbiór usług, które są udostępnione z zewnątrz aplikacji • 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. SSR, Wykład 3, Folia 16 marzec 2009
Osłona: różne architektury
Wielo-funkcyjna aplikacja spadkowa
Serwer
Osłona
Serwer
CORBA (ORB)
Serwer Aplikacja spadkowa w postaci wielu serwerów
Wielo-funkcyjna aplikacja spadkowa Osłona
Serwer Serwer
CORBA (ORB)
K.Subieta. SSR, Wykład 3, Folia 17
Aplikacja Osłona
Serwer Klient Aplikacja może być logicznie podzielona; aplikacja może być klientem i serwerem marzec 2009
C O R B A Osłona wewnętrzna i zewnętrzna
inner and outer wrapper
Osłona zewnętrzna
(często określona przez wymagania zewnętrznego interfejsu, np.
charakter biznesu)
Osłona wewnętrzna
(specyficzna dla aplikacji)
Dostęp do danych Dostęp do API Emulacja terminalu ekranowego Aplikacja spadkowa Baza danych Kod aplikacji Interfejs użytkownika
K.Subieta. SSR, Wykład 3, Folia 18 marzec 2009
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. SSR, Wykład 3, Folia 19 marzec 2009
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
i Kowalsk Nowak
Referencje do obiektów odsyła do
referencja1 referencja2
Implementacja obiektów
K.Subieta. SSR, Wykład 3, Folia 20 marzec 2009
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 ORB
Znajduje właściwą implementację Adapter obiektu przydziela metodę aktywuje K.Subieta. SSR, Wykład 3, Folia 21 PodajZarobekPrac Kowalski marzec 2009
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.
Klient
ORB
Implementacja obiektu wynik 3000 PLN
PodajZarobekPrac Kowalski K.Subieta. SSR, Wykład 3, Folia 22 marzec 2009
Referencje
Referencje do obiektu nie są 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. SSR, Wykład 3, Folia 23 marzec 2009
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 parametró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. SSR, Wykład 3, Folia 24 marzec 2009
Mechanizm refleksji
reflection
Wołania dynamiczne są oparte o mechanizm określany jako
refleksja
. Refleksja posiada dwa aspekty: 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.
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. SSR, Wykład 3, Folia 25 marzec 2009