Jedním z hitů 90. let v oblasti softwarového inženýrství jsou vícevrstvé
architektury (multi-tier architectures). Jedná se nástupce klasického
klient-server paradigmatu, jehož hlavní výhodou je snadná údržba (maintenance)
aplikací spolu se znovupoužitelností (reusability) jejich programových částí.
Klientské části aplikací obsahují pouze prezentační logiku; jak logika
aplikační (někdy též business), tak i datová jsou přesunuty do specializovaných
serverů. Prostředí podporující implementace aplikačních vrstev se nazývá
middleware.
Nejúspěšnější middleware dneška je CORBA. Ta vytváří jednotný objektový model,
nezávislý na operačním systému, programovém vybavení, programovacím jazyku a na
síťovém spojení počítače. Úspěšně, jednoduše a elegantně se vypořádává s
heterogenním prostředím, které je v současné době tím nejpalčivějším problémem
ať už podnikových sítí na straně jedné, nebo Internetu na straně druhé.
Object Management Architecture
Za vznikem architektury CORBA stojí skupina OMG (Object Management Group), jež
v roce 1991 publikovala svou představu základního frameworku pro distribuované
objektově orientované technologie Object Management Architecture (OMA). OMA
definuje následujících pět základních komponent:
- Object Request Broker (ORB) páteř celé architektury, propojující zbylé
komponenty. Zajišťuje komunikaci mezi jednotlivými objekty v distribuovaném
prostředí formou doručování požadavků (requests) a následných odpovědí
(replies).
- Object Services základní služby se standardizovaným rozhraním, které vývojáři
aplikací mohou potřebovat k práci s distribuovanými objekty (např. jmenná
služba (naming), katalogové vyhledávání (trading), persistence).
- Common Facilities sdružují rozhraní objektů napříč aplikačními doménami
(např. Internationalization Facility, Time Facility).
- Domain Interfaces standardizují rozhraní objektů charakteristických pro
určitou aplikační doménu (např. telekomunikace, zdravotnictví či elektronické
obchodování).
- Application Objects objekty ryze specifické pro konkrétní aplikaci. Tato
komponenta není standardizována OMG.
Object Request Broker
Základní komponentou architektury OMA je ORB, jehož funkcionalitu OMG
specifikuje v architektuře CORBA (Common Object Request Broker Architecture).
Je to objektová sběrnice, která objektům umožňuje transparentně vysílat
požadavky (requests) směrem k jiným objektům (ať již lokálním nebo vzdáleným) a
následně od těchto objektů přijímat odpovědi (replies). Toto prostředí je
nezávislé jak na programovacím jazyce, tak na operačním systému či hardwarové
platformě.
Na počátku je IDL
Pro komunikaci mezi CORBA objekty jsou důležité specifikace jejich rozhraní v
jazyce IDL (Interface Definition Language). Ty slouží jako jakási forma
kontraktu mezi CORBA objekty a jejich potenciálními klienty jinak řečeno,
klient volá pouze metody nad rozhraním definovaným v IDL, a nestará se o to,
jakým způsobem je daný objekt implementován. IDL specifikace rozhraní jsou
následně, s pomocí IDL kompilátoru, mapovány do konkrétních programovacích
jazyků, ve kterých jsou již pak dané CORBA objekty implementovány. Použitím
tohoto mechanismu dochází k oddělení implementace CORBA objektů od jejich
rozhraní, čímž se dosahuje již jednou zmíněné nezávislosti CORBA prostředí na
programovacím jazyce. V současné době existují OMG standardy mapování IDL do
následujících jazyků: C, C++, Smalltalk, Ada95, COBOL a Java.
Volání metod CORBA objektů
Vzdálený CORBA objekt je v klientském adresovém prostoru zastupován jiným
objektem, tzv. proxy. Proxy má obvykle stejné rozhraní jako cílový objekt, a
jeho metodami jsou tzv. stuby (stubs). Stubem se označuje kód, který vezme
všechny parametry volání, vloží je spolu s identifikací dané operace do zprávy
(marshalling) a tuto zprávu předá jádru ORBu k doručení směrem k cílovému
objektu.
Na straně serveru předá ORB došlou zprávu skeletonu. Úkolem skeletonu je
vyjmout z ní identifikaci požadované operace spolu s jejími parametry, a tuto
operaci zavolat nad implementací CORBA objektu.
Formát zpráv předávaných mezi klientem a serverem je specifikován protokolem
IIOP (Internet Inter-ORB Protocol), který zajišťuje interoperabilitu mezi ORBy
různých výrobců.
Z popsaného mechanismu je patrno, že lokální volání metody nad proxy má tedy za
následek pro klienta transparentní vyvolání odpovídající metody nad vzdáleným
objektem (tento mechanismus již známe z RPC).
Poznamenejme pouze, že kód klientského proxy i serverovského skeletonu je
automaticky generován IDL kompilátorem na základě popisu rozhraní cílového
CORBA objektu. V případě, že toto rozhraní je v době kompilace klienta či
serveru neznámé (typická situace: implementujeme-li např. most (bridge) do
jiného prostředí), nabízí CORBA programátorovi možnost "ručně" suplovat práci
stubu či skeletonu pomocí Dynamic Invocation Interface (DII) na straně klienta
či Dynamic Skeleton Interface (DSI) na straně serveru.
Závěrem...
Jako všechny věci, které když jsou "geniální", tak jsou i principiálně
jednoduché, je i CORBA samotná technologií, jejímž základům se lze naučit za
několik dní. CORBA však není jenom výše popsaný princip. Podstata je skryta ve
standardizovaných rozhraních, ať už pro Object Services, Common Facilities či
Domain Objects, jejichž detailní znalost se však vymyká možnostem jedince.
Případní zájemci se s nimi mohou seznámit na adrese http://www.omg.org.
9 0183/OK