Bazy danych i inżynieria oprogramowania
advertisement
Bazy danych i inżynieria oprogramowania
Wykład 5:
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 5, Folia 1
listopad 1999
Usługi nazewnicza
Name Service
• Zapewnia możliwość wiązania nazwy do obiektu relatywnie w stosunku do kontekstu.
• Kontekst nazwowy jest to pewien obiekt zawierający wiązania nazw.
• Wszystkie obiekty muszą być nazwane.
• Nazwy są relatywne w stosunku do kontekstu; w ramach kontekstu są unikalne.
• Usługa nazwowa nie zajmuje się ani składnią ani znaczeniem nazw.
Graf nazw:
user
u1 u2
u3
home
bill
- kontekst nazwowy
- nazwa obiektu
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 5, Folia 2
sys
alden
bin
c1
lib
c2
l1
l2
listopad 1999
Usługa nazewnicza: wiązanie, rozstrzyganie
binding, resolving
Wiązanie: przypisanie nazwy do obiektu
void bind( in Name n, in Object obj )
raises(NotFound, CannotProceed, InvalidName, AlreadyBound)
Przykładowe wywołanie:
kontekst -> bind( foo, myobj )
Rozstrzyganie: odszukanie obiektu posiadającego przypisaną nazwę.
Object resolve( in Name n)
raises (NotFound, CannotProceed, InvalidName)
Przykładowe wywołanie:
myobjref = kontekst -> resolve( foo )
Nazwy mogą mieć postać ciągów <c1;c2;...;cn>.
Wiązanie i rozstrzyganie rekurencyjne.
user; u2; foo
kontekst
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 5, Folia 3
kontekst
nazwa prosta
listopad 1999
Usługa nazewnicza: kroki dla uzyskania referencji
Otrzymaj początkowy kontekst nazwowy:
org.omg.CORBA.Object objRef =
orb.resolve_initial_references(“NameService”);
NamingContext rootContext = NamingContextHelper.narrow(objRef);
Utwórz nazwę złożoną:
NameComponent
NameComponent
NameComponent
NameComponent
comp1 =
comp2 =
comp3 =
[] name
new NameComponent(“user”,””);
new NameComponent(“u2”,””);
new NameComponent(“foo”,””);
= {comp1, comp2, comp3}
Znajdź obiekt opatrzony tą nazwą:
org.omg.CORBA.Object objRef = rootContext.resolve(name);
orb.resolve_initial_references(“NameService”);
FooClass fooRef = FooHelper.narrow(objRef);
Wywołaj metodę na docelowym obiekcie zidentyfikowanym przez fooRef .
narrow - kast do określonego typu.
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 5, Folia 4
listopad 1999
Usługa handlowa (Trader)
Trade Service
Trader jest bazą danych, która umożliwia klientom wyszukanie informacji o
usługach dostarczanych przez obiekty. Na podstawie uzyskanych informacji klient
moze wybrać obiekt, który go interesuje jako dostawca usługi. Obiekt informuje o
swoich usługach poprzez zapisanie odpowiedniej informacji w bazie danych Trader.
Klient może odpytywać tę bazę danych celem wyszukania odpowiedniego obiektu.
Klient
Trader
Rejestracja usługi wraz z opisem
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 5, Folia 5
Obiekt
listopad 1999
Funkcje bazy danych Trader
Podstawową funkcją tej bazy jest dostarczenie klientom możliwości wyszukiwania
ofert usług zgłoszonych (zareklamowanych) przez dostarczające je obiekty.
Dodatkowo pozwala ona na:
tworzenie nowych typów usług, ich usuwanie i listowanie
rejestrację nowych ofert usług, wycofywanie ofert, pobieranie ich
opisu i modyfikację wartości ich właściwości
administrację, czyli modyfikację rożnych parametrów bazy, jak
również pobieranie listy zarejestrowanych ofert, zarówno zwykłych
jak i zastępczych.
tworzenie, usuwanie i modyfikację połaczeń danej instancji bazy
danych Trader z innymi jej egzemplarzami
rejestrację i wycofywanie ofert zastępczych
Można tu odnieść wrażenie, że twórcy standardu CORBA próbują
skonstruować na własną rękę coś, co dawno zostało dobrze opanowane
przez technologie znane jako zmaterializowane perspektywy i (relacyjne,
obiektowe) bazy danych. Koncepcja razi plataniną szczegółów.
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 5, Folia 6
listopad 1999
Definicja typu usługi
Z każdą usługą przechowywaną w bazie danych Trader związany jest typ:
• typ interfejsu dostarczającego usługę
• typ właściwości opisujących tę usługę
usługa OperacjeBankowe {
interfejs :: Finanse :: Bank;
obowiązkowa właściwość short ProcentROR;
właściwość float MaxWysokośćKredytu;
tylko_do_odczytu właściwość boolean GwarancjePaństwowe;
};
Jest to schemat (format) zapisu w bazie danych Trader.
Usługa OperacjeBankowe służy do zapisu informacji o warunkach kredytowania.
Taka deklaracja przypomina deklarację schematu tablicy w SQL. Odpowiednio do
tego, CORBA definiuje coś w rodzaju języka zapytań (a la SQL, ale znacznie
niższego poziomu), przy pomocy którego można wyszukać obiekt (obiekty)
spełniające kryteria wyszukiwania.
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 5, Folia 7
listopad 1999
Usługi w zakresie zdarzeń
Event Service
Usługa ustala dwie role obiektów: dostawcy zdarzeń i konsumenta zdarzeń.
Komunikacja pomiędzy dostawcą i konsumentem wykorzystuje standardowe
zlecenia CORBA.
Dwa modele komunikacji zdarzeń pomiędzy ich dostawcami i konsumentami:
- pchający (push): dostawcy “pchają” zdarzenia i ich dane do konsumentów
interface PushConsumer {
void push( in any data ) raises(Disconnected);
void disconnect_push_consumer(); };
- ciągnący (pull): konsumenci “ciągną” dane zdarzeń od dostawców.
Np. notowanie aktualizacji obiektu: aktualizowany obiekt działa jako dostawca zdarzenia.
Inne relewantne obiekty (np. posiadające wskaźniki do obiektu aktualizowanego
działają jako konsumenci zdarzenia.
W modelu “ciągnącym” konsumenci periodycznie odpytują dostawcę (metoda try_pull)
na okoliczność wystąpienia zdarzenia.
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 5, Folia 8
listopad 1999
Usługi w zakresie cyklu życiowego
Life Cycle Service
Tworzenie obiektów
Przesuwanie obiektów
Kasowanie obiektów
Kopiowanie obiektów
Przykładowe problemy do rozstrzygnięcia:
• Czy klient może sterować lokacją nowo tworzonego obiektu?
• Czy taka lokacja może być ustalona poprzez pewien serwis administracyjny?
• W jakim stopniu klient może decydować o implementacji obiektu?
• Jak klient może wpłynąć na początkowe wartości obiektu?
• Jeżeli obiekty tworzą powiązany graf, jak ustalić granice takiego grafu?
Object create_object(
in Key k,
in Criteria the_criteria
raises( NoFactory, InvalidCriteria, CannotMeetCriteria );
Key: nazwa obiektu, zgodnie z usługami w zakresie nazw;
Criteria: ciąg par <nazwa, wartość>, służący jako zestaw parametrów tworzenia obiektu,
np. inicjalizacja, warunki, ograniczenia, lokacja logiczna, preferencje dotyczące sprzętu, itd.
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 5, Folia 9
listopad 1999
Usługi w zakresie trwałych obiektów
Persistent Object Service
Zawiera
zestaw interfejsów
do zarządzania
trwałymi obiektami.
Klient
Trwały identyfikator,PID
Trwały obiekt, PO
Protokół
Zarządca Trwałymi Obiektami, POM
Usługi w/z trwałych obiektów, PDS
Skład danych
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 5, Folia 10
Ze względu na niski poziom koncepcyjny,
brak niezależności danych, przywiązanie do
bardzo partykularnych protokółów, usługa
bardzo przypomina styl DBTG CODASYL,
który dawno temu został odrzucony.
listopad 1999
Usługi w zakresie związków (1)
Relationship Service
Umożliwia powiązanie obiektów przy pomocy związków,
np. powiązanie samochodu z osobą będącą jego właścicielem.
• Definicja typów związanych encji i typów związków
• Definicja ról, które odgrywają encje w poszczególnych związkach
• Definicja stopnia (degree) związku: binarny, ternarny, itd.
• Definicja kardynalności związku (minimum i maksimum powiązań encji)
• Definicja semantyki związków, tj. jego atrybutów.
Encje są reprezentowane jako obiekty CORBA.
Związek jest tworzony poprzez przesłanie zestawu ról do obiektu-wytwórcy związku.
Można tworzyć związki dowolnego stopnia.
Typy i kardynalności mogą być zadeklarowane i kontrolowane.
Do związku mozna dodać atrybuty.
Podobnie jak w przypadku trwałości,
usługa w zakresie związków jest
zdefiniowana na niskim poziomie abstrakcji.
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 5, Folia 11
listopad 1999
Usługi w zakresie związków (2)
Operacje:
• Tworzenie ról i obiektów przechowujących związki
• Nawigacja wzdłuż związków
• Skasowanie ról i związków
• Iterowanie po związkach w których uczestniczy dana rola
Rola obiektu jest tworzona niezależnie poprzez wytwórnię ról.
Ciąg ról jest parametrem dla wytwórni związku.
Role create_role ( in RelatedObject related_object )
raises ( NilRelatedObject, RelatedObjectTypeError )
struct NamedRole { RoleName name; Role aRole; } ;
typedef sequence <NamedRole> NamedRoles;
Relationship create ( in NamedRoles named_roles )
raises ( RoleType Error, MaxCardinalityExceeded,
DegreeError, DuplicateRoleName, UnknownRoleName)
RelatedObject get_other_related_object (
in RelationshipHandle rel, in RoleName target_name )
raises ( UnknownRoleName, UnknownRelationship )
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 5, Folia 12
listopad 1999
Usługi w zakresie zapytań (1)
Query Service
Zapewnia operacje w zakresie zapytań na kolekcjach obiektów.
Typowe zapytanie zwraca kolekcje obiektów.
Termin “query” obejmuje także operacje:
wstawiania (insert), aktualizacji (update) i usuwania (delete).
Zasady projektowe:
- zgodność z usługami w/z nazw, cyklu życiowego, trwałych obiektów i związków;
- zapytania mogą dotyczyć dowolnych obiektów, z dowolnymi atrybutami i operacjami
- powinny umożliwiać metody podwyższenia wydajności, takie jak indeksy
- aby być użyteczne w wielu środowiskach, usługi muszą dobrze odwzorowywać
lokalne mechanizmy zapytań
Okoliczności związane z przetwarzaniem zapytań:
- Środki graficzne konstruowania zapytań
- Zapamiętywanie zapytań celem ich poźniejszego wykonania, z różnymi parametrami
- Prekompilacja zapytań celem późnieszego wykonania
- Wykonanie zapytań w trybie asynchronicznym
- Sprawdzanie statusu długo przetwarzanego zapytania z możliwością jego zerwania
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 5, Folia 13
listopad 1999
Usługi w zakresie zapytań (2)
Usługa jest zorientowana na wiele języków zapytań, przede wszystkim na SQL i OQL.
Porozumienie pomiędzy ANSI X3H2 (SQL-3) i ODMG (OQL) zmierza do opracowania
wspólnego identycznego języka zapytań (w sensie języka wyszukiwania).
Co zapewnia usługa w zakresie zapytań?
• Operacje selekcji, wstawiania, aktualizacji i usuwania na kolekcjach obiektów.
• Obiekty mogą być chwilowe i trwałe, lokalne lub odległe, z dowolnymi atryb. i operac.
• Dowolna granulowość obiektów
• Zakres dostępnych obiektów regulowany przez kolekcje będące argumentami zapytań
• Wspomaganie dla odpytywania i zwracania złożonych struktur danych
• Wspomaganie dla użycia atrybutów, dziedziczenia, operacji w predykatach zapytań
i w obliczeniach zwracanego rezultatu
• Dowolne użycie interfejsów wyspecyfikowanych w OMG IDL.
• Dowolne użycie związków dla nawigacji, z użyciem testowania występowania związku
pomiędzy obiektami
• Nie łamanie zasady hermetyzacji przewidzianej przez interfejsy do obiektów.
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 5, Folia 14
listopad 1999
Bieżące prace OMG (1)
OMG jest w tej chwili ogromnym, największym w świecie i bardzo aktywnym
konsorcjum. Prowadzi prace badawczo-rozwojowe i standardyzacyjne w bardzo wielu
tematach: przetwarzanie w czasie rzeczywistym, Internet, telekomunikacja, systemy
finansowe, systemy medyczne, analiza i projektowanie obiektowe, elektroniczne
systemy komercyjne, bezpieczenstwo, systemy baz danych, języki programowania.
Komitety:
Dziedzinowy Komitet Techniczny (DTC, Domain Technical Committee):
skupia się na technologiach, ktore są zorientowane dziedzinowo:
Finanse, Wytwarzanie, Medycyna, Biznes, Telekomunikacja.
Platformowy Komitet Techniczny (PTC, Platform Technical Committee):
skupia się na technologiach wspólnych dla wielu dziedzin:
ORB/ObjectServices (ORBOS), Common Facilities.
Rada d/s Architektury (AB, Architecture Board):
skupia sie na integralności i spojności architektury OMA i modelu obiektowego.
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 5, Folia 15
listopad 1999
Bieżące prace OMG (2)
ORBOS (ORB/Object Services) Task Force
Dotychczas CORBA pozwala przesyłać referencje do obiektów, ale nie pozwala
przesyłać obiektów jako wartości (objects by values). Stwarza to problemy dla
niektórych języków programowania, np. C++. ORBOS Task Force rozpowszechnia
obecnie RFP majace na celu technologię przesyłania obiektow jako wartości.
Drugim tematem ORBOS Task Force jest dwukierunkowe współdziałanie ze
standardami Microsoft COM i DCOM.
COM/CORBA jest właśnie zaakceptowany, natomiast
DCOM/CORBA jest w trakcie opracowania.
COM/DCOM niekoniecznie jest konkurentem dla CORBA, raczej
jest to inna technologia, która może być zintegrowana pod parasolem standardu CORBA.
(Jest to pogląd twórców CORBA. Microsoft uwaza inaczej.)
Docelowo (i nieco idealistycznie) CORBA ma być realizacją prawdziwego komercyjnego
off-the-shelf (COTS) rynku składników oprogramowania, które może być składane
w dowolne konfiguracje architektoniczne. Trudno powiedzieć, czy ten cel jest osiągalny.
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 5, Folia 16
listopad 1999
Najbardziej znane implementacje CORBA
Producent
Nazwa systemu
BEA
Systems
ObjectBroker
Iceberg
Borland/
Visigenic
VisiBroker
Expertsoft
PowerBroker
IBM
SOM
ComponentBroker
ICL
DAIS
IONA
Orbix
OrbixWeb
JavaSoft
Java IDL
Opis
http://beasys.com/
Pierwsza i najbardziej dojrza ła implementacja ORB na
rynku. Iceberg jest integracją ObjectBroker z Tuxedo,
tworzac Object Transaction Monitor (OTM).
http://www.visigenic.com/prod
VisiBroker for Java jest czołowym CORBA/Java ORB.
VisiBroker for C++ jest bardzo szybkim O RBem opartym
na IIOP. Jest on włączany w produkty Netscape, Oracle,
Novell, Sybase, Netscape, etc.
http://www.expertsoft.com/
Jeden z najlepszych ORBów dla C++.
http://www.software.ibm.com/objects/somobjects/
http://www.software.ibm.com/ad/cb/
SOM jest teraz częścią ComponentBroker. Zintegrowany z
OTM i DB2.
http://www.icl.co.uk/products/dais/home.html
Pierwszy ORB implementujacy OMG Security Service.
http://www.iona.ie/
Bardzo popularne ORBy. Orbix bazuje na C++.
OrbixWeb bazuje na Java. Firewalls, pomosty do DCOM,
usługa w zakresie transakcji.
http://www.javasoft.com/
CORBA/Java ORB zanurzony w JDK 1.2. Dostępny bez
opłat.
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 5, Folia 17
listopad 1999
Wady OMG CORBA
Zbyt maksymalistyczne cele, zbyt wolne tempo rozwoju, nie nadążanie za rozwojem
współczesnych technologii (Konkurenci: DCOM, serwisy Internet’u).
Niski poziom abstrakcji, zbytnie przywiązanie do szczegółów technicznych jęz.prog.
niskiego rzędu takich jak C++ i protokółów transportowych (przypadek podobny do DBTG
CODASYL). Jako konsekwencja -współdziałanie i przenaszalność jest często trudne do
osiągnięcia.
Tendencja do rozrostu standardu w kierunku nowego języka programowania,
z rozbudowanymi specjalizacjami “pionowymi” i “poziomymi”.
Ograniczenia modelu danych: brak rozdzielenia typów i “interfejsów”, brak niektórych
typów masowych (wielozbiorów), brak relatywizmu i ortogonalności typów,
Problemy wydajności: komunikacja klient-serwer na poziomie dostępu do pojedynczych
obiektów jest dla wielu aplikacji nieakceptowalna. Konieczna jest komunikacja
makroskopowa, np. w stylu (optymalizowanych) języków zapytań takich jak SQL lub OQL.
Problem bezpieczeństwa nie jest dotychczas traktowany z wystarczającą uwagą.
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 5, Folia 18
listopad 1999
Podsumowanie (1)
OMG CORBA jest standardem współdziałania systemów obiektowych i nieobiektowych,
heterogenicznych i rozproszonych, opracowany przez gremium OMG.
Dość ambitnym celem standardu OMG CORBA jest uzyskanie możliwości współdziałania
pomiędzy niekompatybilnymi systemami, pracującymi na różnych platformach
sprzętowych i programowych, oddalonych geograficznie.
Osiągnięcie tego celu wymagało zwiększenia poziomu abstrakcji w taki sposób, aby
(zazwyczaj zasadnicze) różnice implementacyjne nie miały znaczenia. Ten poziom
abstrakcji osiąga się poprzez opis obiektów w uniwersalnym języku IDL (Interface
Definition Language), który oprócz struktury obiektów ustala także specyfikacje metod
działających na obiektach oraz zależności (wielo-) dziedziczenia.
Do współdziałania konieczne jest także określenie odwzorowania (mapping) implementacji
obiektów na abstrakcyjną postać implikowaną przez IDL. Temu celowi poświęcony jest
adapter obiektów, w szczególności BOA (Basic Object Adapter); jest on specyficzny dla
danego języka programowania.
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 5, Folia 19
listopad 1999
Podsumowanie (2)
Powiązanie pomiędzy aplikacją (odwołującą się do obiektów) i implementacją obiektów
może mieć charakter statyczny lub dynamiczny, w zależności od tego, czy wiązanie
następuje w czasie kompilacji czy też w czasie wykonania.
W przypadku statycznym, z wyrażenia IDL jest generowany automatycznie tzw. pniak
(stub), czyli fragment kodu, który jest konsolidowany z aplikacją klienta. Po stronie
serwera obiektów z wyrażenia IDL generowany jest szkielet (skeleton) implementacji,
który
programista
musi
zapełnić
konkretnym
kodem
implementacyjnym
wyspecyfikowanych metod.
W przypadku dynamicznym, dostęp następuje bezpośrednio poprzez odwołania
dynamiczne, na zasadzie podobnej do RPC.
OMG CORBA obejmuje także dużą kolekcję usług i udogodnień, zarówno poziomych
(niezależnych od dziedziny aplikacyjnej, np. usługi w zakresie nazw, zdarzeń, trwałych
obiektów, związków, zapytań), jak i pionowych (specyficznych dla danej dziedziny
aplikacyjnej, np. telekomunikacja, medycyna, finanse, wytwarzanie).
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 5, Folia 20
listopad 1999
Podsumowanie (3)
Podstawowym elementem architektonicznym standardu CORBA jest tzw. pośrednik
(Object Request Broker, ORB), skupiający w sobie funkcjonalności niezbędne do
przetwarzania rozproszonych obiektów i współdziałania.
Pakiety ORB komunikują się ze sobą w sieci komputerowej przy pomocy protokółu GIOP
(General Inter-ORB Protocol) lub jego internetowego odpowiednika IIOP.
W tej chwili zaimplementowano kilkanaście pakietów ORB.
CORBA ma ogromne znaczenie kulturotwórcze w dziedzinie informatyki.
Maksymalistyczne cele tego standardu są trudne do osiągnięcia, szczególnie w zakresie
akceptowalnej wydajności (performance). Niektórzy specjaliści głoszą, że oparcie
rozproszonych aplikacji o standard CORBA będzie zbyt kosztowne. Opinie te są
prawdopodobnie nie zawsze prawdziwe, ale są podsycane przez konkurencję (np. Microsoft
z technologią COM/DCOM).
Argument Microsoft’u przeciwko CORBA dotyczy zbyt wolnego rozwoju (COM już działa
w skali masowej, natomiast pakiety ORB nie działają w tej skali i są zbyt zróżnicowane.)
K.Subieta. Bazy danych i inżynieria oprogramowania, Wykład 5, Folia 21
listopad 1999
