OMG CORBA

Standardy w zakresie systemów rozproszonych
i baz danych
Wykład 5:
Wprowadzenie do
OMG CORBA
Kazimierz Subieta
Polsko-Japońska Wyższa Szkoła
Technik Komputerowych, Warszawa
K.Subieta. SSR, Wykład 5, Folia 1
marzec 2009
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
- kontekst nazwowy
- nazwa obiektu
K.Subieta. SSR, Wykład 5, Folia 2
home
bill
sys
alden
bin
c1
lib
c2
l1
l2
marzec 2009
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. SSR, Wykład 5, Folia 3
kontekst
nazwa prosta
marzec 2009
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. SSR, Wykład 5, Folia 4
marzec 2009
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
może 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
K.Subieta. SSR, Wykład 5, Folia 5
Rejestracja usługi wraz z opisem
Obiekt
marzec 2009
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 plątaniną szczegółów.
K.Subieta. SSR, Wykład 5, Folia 6
marzec 2009
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. SSR, Wykład 5, Folia 7
marzec 2009
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. SSR, Wykład 5, Folia 8
marzec 2009
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. SSR, Wykład 5, Folia 9
marzec 2009
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. SSR, 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.
marzec 2009
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. SSR, Wykład 5, Folia 11
marzec 2009
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. SSR, Wykład 5, Folia 12
marzec 2009
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 późniejszego wykonania, z różnymi parametrami
- Prekompilacja zapytań celem późniejszego wykonania
- Wykonanie zapytań w trybie asynchronicznym
- Sprawdzanie statusu długo przetwarzanego zapytania z możliwością jego zerwania
K.Subieta. SSR, Wykład 5, Folia 13
marzec 2009
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ło do opracowania
wspólnego identycznego języka zapytań (w sensie języka wyszukiwania).
Nic z tego nie wyszło.
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. SSR, Wykład 5, Folia 14
marzec 2009
Bieżące prace OMG (1)
OMG jest w tej chwili ogromnym, największym w świecie i bardzo aktywnym
konsorcjum. Prowadzi prace badawczo-rozwojowe i standaryzacyjne w bardzo wielu
tematach: przetwarzanie w czasie rzeczywistym, Internet, telekomunikacja, systemy
finansowe, systemy medyczne, analiza i projektowanie obiektowe, elektroniczne
systemy komercyjne, bezpieczeństwo, 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. SSR, Wykład 5, Folia 15
marzec 2009
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 mające na celu technologię przesyłania obiektów 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 uważa 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. SSR, Wykład 5, Folia 16
marzec 2009
Specyfikacje OMG (1)

MDA - The Model Driven Architecture.

UML - the Unified Modeling Language

MOF - The MetaObject Facility

XMI - XML Metadata Interchange

CWM - The Common Warehouse Metamodel

CORBA - the Common Object Request Broker
Architecture
K.Subieta. SSR, Wykład 5, Folia 17
marzec 2009
Specyfikacje OMG (2)

Data-Distribution Service for Real-time
Systems™ (DDS™)

OMG Systems Modeling Language

Business Process Modeling Notation (BPMN)
K.Subieta. SSR, Wykład 5, Folia 18
marzec 2009
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
K.Subieta. SSR, Wykład 5, Folia 19
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.
marzec 2009
CORBA Vendor Directory Listing

















OMG Membership Level:
2AB Inc.
C - Contributing
AdNovum Informatik AG - OMG Member (I)
D - Domain
eCube Systems - OMG Member (I)
P - Platform
IBM Rational - OMG Member (C)
I - Influencing
IONA Technologies - OMG Member (C)
G - Government
iWay Software - OMG Member (T)
U - University
Liantis GmbH & Co. KG
T - Trial
Logical Tracking&Tracing International AG
A - Analyst
No Magic, Inc. - OMG Member (C)
Object Computing Inc. - OMG Member (I)
Objective Interface Systems, Inc - OMG Member (C)
ObjectSecurity Ltd.
PrismTech - OMG Member (C)
Remedy IT - OMG Member (P)
Southwest Research Institute - OMG Member (U)
Sparx Systems - OMG Member (C)
TenFold Corporation
K.Subieta. SSR, Wykład 5, Folia 20
marzec 2009
Wady OMG CORBA






Zbyt maksymalistyczne cele, wolne tempo rozwoju, nie nadążanie za rozwojem
współczesnych technologii (Konkurenci: DCOM/Remoting.Net, Web Services,
RMI+JavaBeans).
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, SBQL lub OQL.
Problem bezpieczeństwa nie jest dotychczas traktowany z wystarczającą uwagą.
K.Subieta. SSR, Wykład 5, Folia 21
marzec 2009
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. SSR, Wykład 5, Folia 22
marzec 2009
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. SSR, Wykład 5, Folia 23
marzec 2009
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. SSR, Wykład 5, Folia 24
marzec 2009