Architektura CORBA

Rozmanitost HW a SW se stala skutečností našeho všedního života a neklesá ani s pokrokem ve vývoji počítačů. Na je...


Rozmanitost HW a SW se stala skutečností našeho všedního života a neklesá ani s
pokrokem ve vývoji počítačů. Na jednom konci spektra jsou superpočítače
provádějící náročné vědeckotechnické výpočty nebo masivní databáze pro
rezervaci letenek. Uprostřed stojí výkonné servery a desktopy poskytující stále
rostoucí pole nejrůznějších služeb a na konci tohoto spektra jsou zabudované
systémy, o nichž už ani nepřemýšlíme jako o počítačích.
Je těžké dosáhnout toho, aby všechny součásti spolupracovaly. V podnicích je
nakoupena řada produktů, oddělení pracují na jiných platformách, SW vykonává
podobnou činnost, ale mluví jiným jazykem. Jeho integrace stojí mnoho času a
peněz.
Vývoj SW také zabírá mnoho času a peněz. V obecném případě každý projekt začíná
na zelené louce, což je akceptovatelné pouze pro malé projekty, ale ne pro
velké aplikace, které modelují činnost velkých podniků. Proto potřebujeme,
abychom mohli vyvíjet na společném základě.
Řešením jsou softwarové komponenty, které lze dynamicky kombinovat tak, aby si
uživatelé mohli vytvořit nástroj podle svých potřeb. Tyto komponenty budou
spolupracovat pouze tehdy, jestliže byly navrženy a vytvořeny podle
standardního interfejsu.
Nesnadného úkolu pokusit se vyřešit tyto problémy se ujala skupina OMG(Object
Management Group) neziskové konsorcium vytvořené v roce 1989 za účelem podpory
objektové technologie v distribuovaných výpočetních systémech. Původně tvořilo
OMG 13 společností, v současnosti jejich počet přesahuje 800.
OMG svůj cíl realizuje skrze vytváření standardů, které umožňují
interoperabilitu a portabilitu distribuovaných objektově-orientovaných
aplikací. Neprodukuje software nebo implementační návody, ale pouze specifikace.
Výsledkem práce OMG je specifikace OMA (Object Management Architecture), což je
vize úplného distribuovaného prostředí na nejvyšší úrovni. Sestává ze 4 složek,
které můžeme rozdělit na 2 části:
lsystémově orientované komponenty: ORB (Object Request Broker) a Object
Services (služby),
laplikačně orientované komponenty: Application objects (objekty a aplikace) a
Common Facilities (aplikační rámce).
ORB je základem OMA a řídí veškerou komunikaci mezi jednotlivými komponentami.
Umožňuje objektům interakci v heterogenním distribuovaném prostředí nezávisle
na platformách, na nichž jsou tyto objekty rezidentní a podporuje jejich
implementaci. Při vykonávání svých úloh se spoléhá na objektové služby, které
jsou zodpovědné za obecné řízení objektů, jako je jejich vytváření, řízení
přístupu k objektům, udržování záznamů o přemístění objektů atd.
Standardem pro ORB je CORBA (Common Object Request Broker Architecture). CORBA
je zajímavá tím, že používá objekty jako sjednocující prostředek pro přenos
existujících aplikací na sběrnici. Kromě toho je specifikace služby vždy
oddělena od její implementace. To umožňuje spojovat existující systémy uvnitř
sběrnice.
Návrh CORBY je založen na OM (Object Model). V tomto modelu klient požaduje
službu od objektu (někdy též nazývaného server) pomocí definovaného rozhraní.
Klient přistupuje k objektu tím, že vydá požadavek na objekt. Přitom
nepotřebuje vědět, kde se objekt nachází, v rámci jakého OS je vykonáván a jak
je implementován. Co ale klient potřebuje vědět, je interfejs, který server
nabízí. Interfejs je specifikován pomocí neutrálního IDL (Interface Definition
Language). IDL je čistě deklarativní a vychází z C++.
ORB je střední vrstva vytvářející vztah klient/server (K/S) mezi objekty.
Pomocí ORB může klientský objekt transparentně vyvolat metodu na libovolném
serverovském objektu v síti. ORB zachytí volání a je zodpovědný za nalezení
objektu, který může požadavek vykonat. Klient je s ORBem spojen přes statický
nebo dynamický stub. Na straně serveru je požadavek přijímán adaptérem objektů
a přes skeleton je předán serveru. Dynamické skeletony komunikují se vzdálenými
ORBy. V implemetačním repozitáři a repozitáři rozhraní jsou uloženy informace
nutné pro podporu interoperability.
Služby
rozšířují a doplňují funkcionality ORBu. Používají se pro vytváření komponent,
jejich pojmenování a zavedení do prostředí. OMG publikovala standardy pro 15
objektových služeb:
1.Life Cycle service definuje operace pro vytváření, kopírování, přesun a
rušení komponent na sběrnici.
2.Persistence service poskytuje jednoduchý interfejs pro trvalé ukládání
komponent do různých paměťových serverů včetně objektových databází (ODBMS),
relačních databází (RDBMS) a jednoduchých souborů.
3.Naming service umožňuje komponentám na sběrnici nalézt ostatní komponenty
podle jména. Podporuje také společný jmenný kontext.
4.Event service umožňuje komponentám dynamicky zaregistrovat či zrušit jejich
zájem o specifickou událost.
5.Concurrency Control service poskytuje řízení uzamykání.
6.Transaction service poskytuje dvoufázové potvrzení pomocí jednoduchých nebo
vnořených transakcí.
7.Relationship service poskytuje prostředky pro vytváření dynamických asociací
mezi komponentami, které o sobě navzájem nevědí.
8.Externalization service poskytuje standardní způsob pro zápis a čtení dat
z/do komponent pomocí mechanismu podobajícího se proudům.
9.Query service poskytuje dotazovací operace pro objekty. Tato nadmnožina SQL
je založena na specifikaci SQL3 a objektovém dotazovacím jazyku (Object Query
Language OQL) skupiny ODMG (Object Database Management Group).
10. Licensig service poskytuje operace pro licencování použití komponent a
zabezpečení zaplacení poplatků za jejich použití. Umožňuje placení poplatků za
seanci, za uzel, za vytvoření instance.
11. Properties service poskytuje operace, které umožňují spojit pojmenovanou
hodnotu (nebo vlastnost) s libovolnou komponentou. Pomocí této služby můžeme
dynamicky spojovat vlastnosti se stavem komponenty např. nadpis nebo datum.
12. Time service poskytuje interfejs pro synchronizaci času v distribuovaném
objektovém prostředí. Rovněž poskytuje prostředky pro definování a řízení
časově spouštěných událostí.
13. Security service poskytuje úplný rámec pro bezpečnost distribuovaných
objektů. Podporuje autentifikaci, seznamy pro řízení přístupu, důvěrnost a
nepopiratelnost převzetí. Kromě toho řídí i delegování pověření mezi objekty.
14. Trader service poskytuje "Yellow Pages" pro objekty, čímž jim umožňuje
nabízet svoje služby.
15. Collection service poskytuje CORBě interfejs pro generické vytváření a
manipulování s nejběžnějšími souhrny.
Obchodní objekty
poskytují přirozený způsob pro popis aplikačně nezávislých konceptů jako jsou
zákazník, objednávka, platba, pacient atd. Konečným cílem OO technologie a
komponent je poskytnout tyto středně velké komponenty, které se chovají stejně
jako v reálném světě a rozumí sémantice událostí.
V CORBě existují 3 druhy objektů:
1.Podnikový objekt zapouzdřuje paměť, metadata a obchodní pravidla spojená s
aktivní obchodní entitou.
2.Procesní objekt zapouzdřuje obchodní logiku na podnikové úrovni. Definuje,
jak proces reaguje na změny ve svém prostředí.
3.Prezentační objekty vizuálně reprezentují objekt uživateli. Každý objekt může
mít více prezentací pro různé účely.
Typický obchodní objekt sestává z podnikového objektu, jednoho nebo více
prezentačních objektů a procesního objektu.
VÝHODY CORBY
ldůsledně se využívá OO paradigma vývoje SW od počátku vývojového cyklu až do
konce,
lpomocí IDL a tenké vrstvy zapouzdřujícího kódu umožňuje, aby existující
aplikace mohly přejít do prostředí CORBY na společný základ s novými
komponentami,
lCORBA/OMA prostředí maximalizuje programátorskou produktivitu,
lběhem projektu lze mixovat použité nástroje např. pro vývoj desktopových
komponent můžeme používat interaktivní buildery a současně pro vývoj serveru
budeme používat jazyky nižší úrovně např. C++.
Srovnání s jinými produkty
Tato část by vydala na samostatnou knihu. Zmíníme se jen o několika základních
termínech pocházejících z dílny Microsoftu. OLE (Object Linking and Embeding)
ukládá odkazy k jednomu nebo více objektům dovnitř jiného nebo vkládá celé
objekty do jiného objektu. COM (Common Object Model) popisuje, jak se objekty
jeví a jak se chovají. DCOM (Distributed COM) je vlastně
distribuovaná verze specifikací OLE a COM definující protokol, podle něhož
objekty komunikují.
Rozdíly vyplývají z původního návrhu. Zatímco CORBA byla od začátku chápána
jako distribuovaná a heterogenní, OLE a COM byly navrženy pro nedistribuované,
homogenní víceúlohové prostředí. CORBA podporuje vícenásobnou dědičnost, COM
podporuje pouze jednoduchou dědičnost.
Existují však i podobnosti - odkaz na objekt v CORBě zhruba odpovídá ukazateli
v COM. Rozhraní je v CORBě přístuné z Interface Repository, v COM jsou objekty
dostupné přes systémový registr.
8 2141 / ram









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.