Standardy w zakresie systemów rozproszonych i baz danych
description
Transcript of Standardy w zakresie systemów rozproszonych i baz danych
K.Subieta. SSR, Wykład 3, Folia 1 marzec 2009
Standardy w zakresie systemów rozproszonych i baz danych
Kazimierz Subieta
Polsko-Japońska Wyższa SzkołaTechnik Komputerowych, Warszawa
Wykład 3:Wprowadzenie do OMG CORBA
K.Subieta. SSR, Wykład 3, Folia 2 marzec 2009
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ówstring<10> - ograniczenie do 10-ciu znakówstring - 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
IDL: typy konstruowane, typy wzorcowe
K.Subieta. SSR, Wykład 3, Folia 3 marzec 2009
//OMG IDLinterface 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 Factoryfind_factories - operacja, która bierze jako parametr nieograniczony string
i zwraca jako rezultat 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
K.Subieta. SSR, Wykład 3, Folia 4 marzec 2009
interface inheritance
//OMG IDLinterface 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
CORBA wprowadzaspecjalny interfejsObjectz którego automatyczniedziedziczą wszystkie inne interfejsy.
IDL: dziedziczenie interfejsów
K.Subieta. SSR, Wykład 3, Folia 5 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 6 marzec 2009
IDL: struktury i uniestruct - 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. SSR, Wykład 3, Folia 7 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 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. SSR, Wykład 3, Folia 8 marzec 2009
IDL nie ma konstrukcji sterujących języków programowania, nie może być więcbezpoś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 IDLlong, short,...anystring, wstringsequencereferencja do obiektuinterfaceoperationmodule
Przykładowe odwzorowanie IDL do C++:
C++long, short,...any classchar *, wchar_t *classwskaźnik lub obiektclassfunkcja członkowskanamespace
Obiekty CORBAsą implementowane jako obiekty języka programowania
IDL: odwzorowania językowelanguage mappings
K.Subieta. SSR, Wykład 3, Folia 9 marzec 2009
Każda aplikacja oparta na CORBA wymaga dostępu do systemu typów zapisanychw 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 danegojęzyka programowania, w którym jest pisana aplikacja, zgodnie z odwzorowaniem językowym. Ten kod następnie jest wbudowany w aplikację. Zmiany w środowiskuw 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łabytrudności. Alternatywą jest dynamiczny dostęp i wykorzystanie informacji o typie.
CORBA IR (Interface Repository) pozwala na dostęp do typów zdefiniowanych w IDLpodczas czasu wykonania. Dostęp jest hierarchiczny: np. po dostępie do modułumoż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. SSR, Wykład 3, Folia 10 marzec 2009
Struktura repozytorium interfejsów
Repository
ModuleDef
InterfaceDef
ConstantDefExceptionDefOperationDefAttributeDef TypedefDef
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.
K.Subieta. SSR, Wykład 3, Folia 11 marzec 2009
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 onotakż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 implementacjiImplementation Repository
K.Subieta. SSR, Wykład 3, Folia 12 marzec 2009
RepozytoriumInterfejsów
PniakiPniakiPniaki SzkieletySzkieletySzkieletyRepozytoriumImplementacji
Klient Implementacja obiektów
Instalacja implementacji
Definicje w IDL
Repozytoria interfejsów i implementacji
K.Subieta. SSR, Wykład 3, Folia 13 marzec 2009
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 Adapterobiektu Obiekt
Interfejs A Interfejs X
Wołający oczekujeinterfejsu A
Adapter obiektuadoptuje interfejs X
do interfejsu A
Obiekt zapewniainterfejs X
Adaptery obiektów
K.Subieta. SSR, Wykład 3, Folia 14 marzec 2009
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 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.
Role adapterów obiektów
K.Subieta. SSR, Wykład 3, Folia 15 marzec 2009
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/POASzkielet
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 POABasic Object Adapter, Portable Object Adapter
K.Subieta. SSR, Wykład 3, Folia 16 marzec 2009
Zadaniem osłon jest:
- istniejących aplikacji “spadkowych” (legacy)- komercyjnych aplikacji
• Hermetyzacja 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.
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. SSR, Wykład 3, Folia 17 marzec 2009
Wielo-funkcyjna aplikacja spadkowa
Osłona
CORBA (ORB)
Serwer Serwer Serwer
Aplikacjaspadkowaw postaciwieluserwerów
Aplikacjamoże być logicznie podzielona;aplikacjamoże byćklientem iserwerem
Wielo-funkcyjna aplikacja spadkowa
Osłona
CORBA (ORB)
Serwer Serwer Serwer
Aplikacja
Osłona
Klient
Osłona: różne architektury
K.Subieta. SSR, Wykład 3, Folia 18 marzec 2009
inner and outer wrapper
C ORBA
Osłonazewnętrzna
(częstookreślona
przezwymagania
zewnętrznego interfejsu,
np.charakterbiznesu)
Dostępdo danych
Dostęp do API
Emulacjaterminalu
ekranowego
Aplikacjaspadkowa
Baza danych
Kodaplikacji
Interfejsużytkownika
Osłonawewnętrzna(specyficznadla aplikacji)
Osłona wewnętrzna i zewnętrzna
K.Subieta. SSR, Wykład 3, Folia 19 marzec 2009
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. SSR, Wykład 3, Folia 20 marzec 2009
Obiekty są manipulowane poprzez metody wewnątrz implementacji obiektówObiekty są tworzone przez warstwę implementacji obiektów lub już istnieją wpewnych 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ę.
Kowalski Nowak
referencja1referencja2
Obiekty pracowników Referencje do obiektów
odsyła do
Implementacjaobiektów
Scenariusz zarządzania obiektami (1)
K.Subieta. SSR, Wykład 3, Folia 21 marzec 2009
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 mechanizmyCORBA; 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ą odpowiednichmanipulacji obiektami
ORBZnajduje właściwąimplementację
PodajZarobekPrac
Kowalski
przydziela metodę
aktywuje
Adapterobiektu
Scenariusz zarządzania obiektami (2)
K.Subieta. SSR, Wykład 3, Folia 22 marzec 2009
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. SSR, Wykład 3, Folia 23 marzec 2009
Z punktu widzenia klienta, obiekt jest dostępny poprzez ORB z użyciem referencjiPojedyńczy obiekt może mieć wiele referencji (nie zalecane).Porównanie referencji nie jest zdefiniowane i nie jest zalecane.Referencja może być NULLReferencja jest nieczytelna (opaque), ale można dokonać konwersji na string i spowrotemDane referencyjne (klucz relacji, Pesel, etc.) są sekwencją do 1024 bajtów.
Id interfejsu Dane referencyjne Id implementacji
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):
Wyszukiwanie referencji - np. poprzez serwis nazwowy.
Referencje
K.Subieta. SSR, Wykład 3, Folia 24 marzec 2009
Zalety statycznego wołania metod:
Łatwiejsze do programowania: odległa metoda jest wołana w programietak 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.
Statyczne vs. dynamiczne wołania metod
K.Subieta. SSR, Wykład 3, Folia 25 marzec 2009
Mechanizm refleksji
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.
reflection