Řešení pro vzájemnou spolupráci prvků distribuovaných aplikací

Začátkem druhé poloviny 80. let, kdy se počítače začaly čím dál více vměšovat

do běžného života, se architektura klient-server začala rozvíjet stále

rychlejším tempem. Nejdříve se začala uplatňovat na mainframech a s nástupem

databázového inženýrství i na databázových serverech.

Z prostředků, které programátoři zprvu používali ve svých aplikacích, jasně

převládalo jejich vlastní proprietární řešení. Tento stav nedovoloval

propojení programového vybavení mezi více výrobci a mnohdy ani mezi produkty

jednoho výrobce.

Jedním z prvních standardů bylo RPC firmy Sun Microsystems. Toto řešení ovšem

nezachytilo rozjíždějící se vlak objektových technologií, ale i tak se dodnes

používá (např. v souborovém systému NFS). Nedlouho po boomu Internetu se

začaly hledat technologie, které by propojily programové vybavení jak přes

síť, tak mezi jednotlivými výrobci a to s co nejmenšími náklady (finančními a

intelektuálními). S nástupem dvouúrovňové architektury (two-tier) a později

tří a více úrovňových architektur (three/multi-tier) se začal vyvíjet

objektový distribuovaný systém, který by byl nezávislý na platformě jak

hardwarové, softwarové (operační systém), tak i na implementační (programovací

jazyk).

Klient-server a co dál?

Na počátku byla architektura klient-server, která byla používána již od roku

1980, ale až koncem 80. let získala na popularitě (zvláště na mainframech,

později v databázích). Zde si vývojáři sami implementovali vlastní systém pro

vzdálená volání ať už funkcí či metod při nástupu objektových technologií,

což v důsledku znamenalo sice rychlý rozvoj technologie, ale také poněkud

chaos a jistou nekompatibilitu mezi jednotlivými produkty. Tehdy se začaly

firmy sdružovat do různých konsorcií, která měla za úkol nastolit pořádek.

S nástupem tříúrovňové (three-tier) a víceúrovňové (multi-tier) architektury v

90. letech, se řada problémů odbourala, a to vložením další vrstvy (vrstev)

mezi klienta a server. Tato mezivrstva (často nazývaná aplikační server)

logicky odděluje účastníky, může také přidávat další funkcionalitu (např.

transakce, zpracování zpráv, připojení k databázovým serverům) a zvyšuje

výkonnost celého systému. Současně s vývojem architektur došlo i k rozvoji

Internetu a vznikl problém propojení různorodých počítačů a jejich operačních

systémů. Nastala otázka, jak spojit rozdílné operační systémy.

Jedna z mála technologií, které se v tříúrovňové architektuře úspěšně

používají, je CORBA. Vytváří jednotný objektový model, který není 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řádala 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é.

V současné době není problém zpřístupnit pomocí standardu CORBA (CORBA by se

mělo v češtině skloňovat buď předsunout slovo standard, které skloňovat

můžeme, nebo by to mělo znít CORBAy (což je strašné, že)) nesíťové staré

aplikace, které se v podnicích používají s uživateli a to tak, že pro

uživatele není rozdílu v tom, odkud k nim přistupují.

Object Management Architecture (OMA)

Historie architektury CORBA začíná v roce 1989, kdy byla založena OMG (Object

Management Group). Organizace, původně čítající 8 členů, v dnešní době

sdružuje přes 800 společností, firem a univerzit. Jejími členy jsou v podstatě

všichni významní výrobci softwaru i hardwaru (Sun, IBM, HP, atd.). Hlavním

cílem OMG je poskytnout svým členům prostředí pro vzájemnou komunikaci

vyúsťující v tvorbu široce přijímaných a životaschopných standardů pro oblast

distribuovaných objektově-orientovaných systémů.

Základem zapouzdřujícím všechny OMG technologie je OMA, poprvé zveřejněná v

roce 1991 v publikaci „Object Management Architecture Guide“. Tvoří ji 2

části: základní objektový model (Core Object Model) a referenční model

(Reference Model).

Základní objektový model

Přístup OMG k chápání objektově-orientovaného paradigmatu je odražen v

základním objektovém modelu. Ten definuje základní koncepty a pojmy, jakými

jsou např. objekt, rozhraní (interface), operace (operation), dědičnost

(inheritance), atd. Všechny tyto pojmy jsou definovány jako čistě abstraktní,

bez jakékoliv návaznosti na konkrétní implementace.

Základní objektový model může být rozšířen o další koncepty, které pak tvoří

komponentu (component). Komponenty by měly být ortogonální jak k základnímu

modelu, tak i k sobě navzájem (tj. koncepty v nich obsažené by se neměly

vzájemně překrývat, duplikovat či vylučovat). Kombinací základního modelu a

jedné či více komponent vzniká profil (profile). Typickými příklady profilů

jsou např. CORBA, či ODP Reference Model.

Referenční model

Základní infrastruktura aplikací spolu se strukturou služeb, které tyto

aplikace mohou využívat, je definována v referenčním modelu. Tento definuje

následujících 5 základních komponent OMA:

Object Request Broker (ORB) je páteří celé architektury propojující ostatní

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 jsou základní služby se standardizovaným rozhraním, které

vývojáři aplikací mohou potřebovat k vyhledávání a spravování distribuovaných

objektů, koordinaci složených operací, atd. Příkladem takové služby může být

naming, trading, perzistence nebo podpora pro transakční zpracování.

Common Facilities sdružují rozhraní objektů jdoucí napříč aplikačním doménám.

Příkladem mohou být např. Distributed Document Componet Facility,

Internationalization Facility nebo Time Facility.

Domain Interfaces standardizují rozhraní objektů charakteristických pro

určitou aplikační doménu (oblast). Takovými oblastmi mohou být např.

telekomunikace, zdravotnictví či elektronické obchodování.

Application Objects jsou objekty specifické ryze pro konkrétní aplikaci. Tato

komponenta jako jediná není standardizována OMG.

Object Request Broker (ORB)

Základní komponentou architektury OMA je ORB, jehož funkcionalitu OMG

specifikuje v architektuře CORBA (Common Object Request Broker Architecture).

Jedná se o objektovou sběrnici, která objektům umožňuje transparentně vysílat

požadavky 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.

Klientská strana

K vyslání požadavku směrem k serverovému objektu, je klientu k dispozici

dvojí mechanismus: statické či dynamické vyvolání. Jednodušší a mnohem častěji

využívané statické vyvolání (SII Static Invocation Interface) je založeno na

znalosti rozhraní cílového objektu v době kompilace klienta. Definice

rozhraní zapsaná v jazyce IDL je využita k automatickému vytvoření stubů

(stubs) pro všechny metody daného rozhraní; chce-li klient zavolat určitou

operaci nad cílovým objektem, zavolá odpovídající stub, ten vezme všechny

parametry volání, které spolu s identifikací dané operace zabalí do zprávy

(marshalling) a předá jádru ORBu k doručení.

Dynamické vyvolání (DII Dynamic Invocation Interface) se používá v ne tak

často se vyskytujících případech, kdy rozhraní cílového objektu není dopředu,

v době kompilace klienta, známo. V tomto případě je nutné dynamicky, za běhu

aplikace, zjistit IDL rozhraní cílového objektu, na základě této informace

připravit potřebné parametry konkrétní-ho volání, tyto „ručně“ vložit do

zprávy a předat ORBu k doručení.

Programátor tak vlastně zastupuje práci stubu. K dynamickému zjištění IDL

rozhraní cílového objektu lze použít Interface Repositorty (IR). IR je obvykle

samostatný server, který skrze standardizované rozhraní poskytuje IDL

definice CORBA objektů běžícím aplikacím.

Cílový CORBA objekt je v klientském adresovém prostoru obvykle zastupován

jiným objektem, tzv. proxy. V případě statického vyvolání má tato proxy stejné

rozhraní jako cílový objekt a jejími metodami jsou stuby. Lokální volání

metody nad proxy má tedy za následek pro klienta transparentní vyvolání

odpovídající metody nad cílovým objektem (tento mechanismus již známe z RPC).

Zbývá dodat, že pro serverovou stranu aplikace je transparentní, zda byl

požadavek zaslán skrze SII nebo DII.

Serverová strana

K doručení požadavku cílové implementaci na straně serveru může být taktéž

použito statického či dynamického mechanismu. Statický mechanismus (SSI Static

Skeleton Interface) opět vyžaduje znalost rozhraní cílového objektu již v době

kompilace serveru. K přijetí požadavku, vybalení parametrů a zavolání

implementace je použit automaticky generovaný skeleton.

Na druhé straně dynamický mechanismus (DSI Dynamic Skeleton Interface),

obdobně jako na straně klienta, nevyžaduje v době kompilace serveru žádnou

znalost rozhraní cílového objektu. Implementace od ORBu obdrží zprávu a je

sama zodpovědná za vyjmutí identifikace požadované operace, vybalení a

správnou interpretaci parametrů volání a za následné vykonání požadované

operace. Opět, ke zjištění očekávaného počtu a typu parametrů konkrétního

volání, lze použít Interface Repository.

Mezivrstvou mezi jádrem ORBu a implementacemi objektů je objektový adaptér

(Object Adapter), zakrývající z pohledu jádra ORBu rozdíly v prostředí, v němž

žijí implementace CORBA objektů. ORB tedy může být doplněn např. speciálním

adaptérem do prostředí databáze zprostředkujícím v databázi uložená data jako

CORBA objekty.

Standardně jsou definovány 2 adaptéry do objektově-orientovaných prostředí.

Starší, základní objektový adaptér (BOA Basic Object Adapter) a od verze CORBA

2.2 i nový, přenositelný objektový adaptér (POA Portable Object Adapter). Mezi

funkce objektových adaptérů patří např. vytváření a správa objektových

referencí (object references), aktivace či deaktivace cílových objektů, atd.

Objektové adaptéry obvykle spolupracují s Implementation Repository (ImplR),

kde se mohou nacházet data potřebná pro aktivaci CORBA objektů. Struktura

ImplR není standardizována a tudíž informace o CORBA objektech ukládané do

ImplR se u různých implementací ORBu liší.

Rozhraní ORBu, jádro ORBu a interoperabilita

Funkce ORBu, mezi něž patří např. duplikování či rušení objektových referencí,

jejich převod do řetězcové podoby, zjišťování rozhraní daného CORBA objektu

atd., jsou klientům i serverům zpřístupněny přes standardizované rozhraní (ORB

Interface).

Co se týče jádra ORBu, jeho podoba nebyla zpočátku standardizována. Až teprve

ve standardu CORBA 2.0 byl specifikován protokol GIOP (General Inter-ORB

Protocol) a jeho verze pro prostředí sítí TCP/IP a Internetu IIOP (Internet

Inter-ORB Protocol). V rámci těchto protokolů je definován formát zpráv

předávaných mezi klientem a serverem, který spolu s jednotným formátem

objektových referencí umožňuje interoperabilitu mezi ORBy různých výrobců.

Jazyk IDL a jeho mapování

Důležitým prvkem standardu CORBA je jazyk IDL (Interface Definition

Language), s jehož pomocí se, jak již název napovídá, definují rozhraní CORBA

objektů. Je to čistě deklarativní jazyk; nelze v něm zapsat žádný výkonný kód.

Syntaxe jazyka IDL, až na několik drobností, vychází z programátorům známé

syntaxe jazyka C++.

IDL specifikace rozhraní CORBA objektů jsou následně, s pomocí IDL

kompilátoru, mapovány do konkrétních programovacích jazyků, ve kterých již

lze dané objekty implementovat. 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. 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.

V současné době existují OMG standardy mapování IDL do následujících jazyků:

C, C++, Smalltalk, Ada95, COBOL a nově i Java s tím, že mapování do ostatních

jazyků existují zatím pouze v proprietární formě (příkladem může být Borland

Delphi 4.0 a mapování do jazyka Pascal).

Na závěr povídání o IDL lze pouze podotknout, že všechny IDL deklarace mohou

být zpřístupněny běžícím aplikacím skrze Interface Repository.

Závěr

Princip fungování součástí standardu CORBA je možno si vyzkoušet na příkladu

na str. 4.

9 0690 / pen

Jednoduchá CORBA aplikace

Základní principy psaní a následného fungování distribuovaných CORBA aplikací

ilustruje následující jednoduchý příklad. Serverovou část aplikace bude tvořit

jediný objekt bankovní účet poskytující svým klientům operace pro vkládání či

vybírání peněz, případně zjišťování aktuálního stavu účtu. Tento server bude

implementován v jazyce C++ a poběží v prostředí operačního systému Unix.

Klientem bude jednoduchý applet Java běžící v prostředí Netscape

Communicatoru. Pro implementaci tohoto příkladu použijeme VisiBroker, jednu z

nejúspěšnějších implementací standardu CORBA, nedávno představenou firmou

Inprise také na našem trhu. Výhodu VisiBrokeru v tomto konkrétním případě by

mohlo být např. i to, že firma Netscape se rozhodla klientské knihovny od

VisiBrokeru zakomponovat do svých produktů (knihovna, kterou náš applet bude

potřebovat pro komunikaci skrze ORB, je tedy dostupná lokálně; množství kódu,

které s naším appletem musí přijít po síti, je tedy redukováno na únosné

minimum). Kromě instalace VisiBrokeru potřebujeme ještě překladače jazyka C++

a Java (potřebné verze udává dokumentace VisiBrokeru).

Postup tvorby distribuované CORBA aplikace lze rozdělit do následujících

kroků:

Specifikace rozhraní CORBA objektů v jazyce IDL

Generování klientské proxy a serverového skeletonu pomocí IDL kompilátoru

Implementace klienta v konkrétním implementačním jazyce (v našem případě Java)

Implementace serveru v konkrétním implementačním jazyce (v našem případě C++)

IDL specifikace

Prvním krokem v tvorbě distribuované CORBA aplikace je specifikace rozhraní

všech CORBA objektů. V našem případě je to objekt jediný bankovní účet.

Atributem tohoto objektu bude stav účtu, který lze přímo pouze číst. Pro

ostatní manipulace s účtem (vkládání/vybírání peněz) si definujme metody vlož/

vyber. Parametrem těchto metod nechť je částka, o kolik se má stav účtu

změnit, návratovou hodnotou pak nový stav účtu. Vše zapsáno v jazyce IDL

vypadá následovně:

// file account.idl

interface Account {

readonly attribute float balance;

float deposit (in float amount);

float withdraw (in float amount);

};

Následuje fáze, ve které se s pomocí IDL kompilátoru vygenerují kódy

klientské proxy a serverového skeletonu. Připomínáme, že klientskou proxy

potřebujeme mít v Javě, serverový skeleton v C++; to odpovídá použití

kompilátorů idl2java a idl2cpp systému VisiBroker.

Klient

K tomu, aby mohl začít spolupracovat se serverovým CORBA objektem, musí

klient udělat 2 věci zjistit referenci na daný CORBA objekt (v našem případě

ji applet obdrží v řetězcové podobě jako parametr) a poté požádat ORB o

vytvoření proxy pro daný objekt (lze provést např. v rámci voláním

string-to-object). Toto vše se vykonává v rámci inicializace celého appletu.

Poté už jen zbývá v reakci na uživatelovy akce volat metody nad danou proxy,

což má vždy za následek vyvolání vzdálené metody nad cílovým CORBA objektem.

// file ClientApplet.java

import java.awt.*;

public class ClientApplet extends java.applet.Applet {

private TextField _amountField, _balanceField;

private Button _checkBalance, _deposit, _withdraw;

private Account _account;

public void init() {

setLayout(new GridLayout(3, 2, 5, 5));

add(new Label(„Amount“));

add(_amountField = new TextField());

add(_deposit = new Button(„Deposit“));

add(_withdraw = new Button(„Withdraw“));

add(_checkBalance = new Button(„Check Balance“));

add(_balanceField = new TextField());

_balanceField.setEditable(false);

org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(this,

null);

_account = AccountHelper.narrow(

orb.string_to_object(getPa­rameter(„IOR“)));

}

public boolean action(Event ev, Object arg) {

if(ev.target == _deposit) {

_account.deposit(new

Float(_amountField.getTex­t()).floatValue());

_balanceField.setText(Float.toString

(_account.balance());

return true;

}

if(ev.target == _withdraw)

{

_account.withdraw(new

Float(_amountField.getTex­t()).floatValue());

_balanceField.setText(Flo­at.toString(_account.balan­ce

)));

return true;

}

if(ev.target == _checkBalance)

{

_balanceField.setText(Float.toString(

_account.balance());

return true;

}

return false;

}

}

Zde by bylo vhodné poznamenat, že obecnějším a z hlediska teorie

distribuovaných systémů i „čistějším“ způsobem získání reference a následně i

proxy pro cílový objekt by bylo použití objektových služeb (Naming Service,

Trading Service). Ačkoliv VisiBroker prvně jmenovanou službu též nabízí, její

použití je pro jednoduchost ukázkové aplikace vynecháno.

Implementace serveru

Implementaci serveru lze rozdělit do 2 částí. První část spočívá ve vytvoření

objektu implementujícího rozhraní příslušného CORBA objektu (v odborné

terminologii se pro takový objekt začíná vžívat jméno servlet). To lze např.

poděděním od automaticky vygenerovaného skeletonu třídy s následnou

implementací IDL rozhraní odpovídajících metod, jak ukazuje následující kód:

// file account_srvr.C

#include „account_s.hh“

class AccountImpl : public _sk_Account {

private:

CORBA::Float _balance;

public:

AccountImpl(const char *object_name=NULL) :

_sk_Account(object_name) {}

virtual CORBA::Float balance() {

return _balance;

}

virtual CORBA::Float deposit(CORBA::Float amount) {

return _balance += amount;

}

virtual CORBA::Float withdraw(CORBA::Float amount) {

return _balance -= amount;

}

};

(Pozn.: Spuštěním idl2cpp překladače na account.idl se vygenerují soubory

account_c.hh a account_c.cc obsahující kód klientské proxy a soubory

account_s.hh a account_s.cc obsahující kód serverového skeletonu. V tomto

případě využijeme pouze serverovou část; vkládáme soubor account_s.hh).

Druhá část implementace serveru spočívá ve vytvoření procesu, který na počátku

inicializuje knihovny ORBu a BOA, poté vytvoří instanci v předchozí části

vytvořeného implementačního objektu, tuto instanci registruje u BOA a přejde

do smyčky, ve které bude zpracovávat požadavky doručené ORBem. Vše opět

zachycuje následující kód:

int main(int argc, char* const* argv)

{

try {

CORBA::ORB_var orb = CORBA::ORB_init(argc, argv);

CORBA::BOA_var boa = orb->BOA_init(argc, argv);

AccountImpl account(„TestAccount“);

boa->obj_is_ready(&account);

boa->impl_is_ready();

} catch(const CORBA::Exception& e) {

cerr << e << endl;

return(1);

}

return(0);

}

Implementace serveru byla opět pro potřeby jednoduchosti této demonstrace

poněkud zjednodušena skutečná implementace bankovního účtu by veškerý pohyb na

účtu zaznamenávala do databáze (oddělila by se aplikační a datová logika

aplikace tak jak jsme zvyklí z vícevrstvých architektur) a vše by podléhalo

transakčnímu zpracování. VisiBroker pro tyto akce nabízí podporu v podobě

Integrated Transaction Service.

Posledními kroky před samotným spuštěním výsledné aplikace jsou kompilace

klienta (překladačem jazyka Java) a kompilace serveru (překladačem jazyka

C++). Připomínáme pouze, že kompilátory těchto jazyků je třeba získat

separátně obvykle nebývají součástí instalace systému CORBA. Nyní již stačí

vše zkompilovat a poté spustit a otestovat funkčnost.

Implementace architektury CORBA VisiBroker

Když firma Inprise (tehdy ještě Borland) koupila loni na jaře firmu Visigenic,

zařadila tím mezi své produkty i úspěšnou implementaci architektury CORBA

VisiBroker. Koncem roku se tento produkt objevil i na našem trhu. Sama

implementace podporuje OMG standard CORBA 2.0 a implementuje rozšíření, která

programátorům a správcům zjednodušují vývoj a posléze správu systému.

VisiBroker nabízí mapování jazyka IDL do jazyků C++ a Java. Samotný VisiBroker

lze použít na mnoha operačních systémech (Windows 95, 98 a NT, nejrozšířenější

UNIX platformy Solaris, HP-UX, AIX, SGI IRIX) a tím nabídnout interoperabilitu

mezi rozdílnými prostředími.

S VisiBrokerem se uživatelé Internetu, kteří používají prohlížeč od

společnosti Netscape, setkávají dnes a denně, protože byl zdarma zakomponován

přímo do jeho kódu (pouze mapování IDL do jazyka Java). Toto si můžeme přímo

vyzkoušet v příkladu, který je součástí tohoto TECH-Tipu, kde si předvádíme

spolupráci mezi serverem napsaném v C++ a klientem v jazyce Java, který

poběží jako applet v prohlížeči Netscape Communicator.

Inprise nabízí vývojářům nejenom implementaci CORBA standardu, ale také

nástroje pro vývoj těchto aplikací mezi nejznámější patří JBuilder 2, Delphi

4.0, C++ Builder 3 Enterprise, který ulehčuje práci programátorům při návrhu a

implementaci.

V současné době se na trh uvádí ITS (Integrated Transaction Service), která

bude využívána při elektronickém obchodování (Electronic Commerce). Pro

zajištění spolupráce mezi technologiemi COM a CORBA existuje produkt COM-CORBA

bridge. Z další rodiny produktů jmenujme Inprise Application Server

(aplikační server nabízející vývojářům širokou škálu standardních technologií

pro implementaci, běh a správu distribuovaných aplikací), který rovněž v sobě

obsahuje VisiBroker.

Mezi největší a nejznámější uživatele VisiBrokeru patří společnosti Netscape

(v prohlížečích Netscape Communicator a serverech Enterprise Server), Oracle,

Novell, Sybase, Hitachi a mnoho dalších.

Zájemci mohou získat časově omezenou verzi VisiBrokeru na stránce společnosti

Inprise (http:// www.inprise.com) a společně s námi si vyzkoušet již zmíněný

příklad. Na stránce společnosti Inprise naleznete také dokumentaci k produktu

a mnoho odkazů a příkladů.

Přehled vlastností VisiBrokeru (současná verze 3.3):

OMG CORBA standard 2.0, částečně 2.2

mapování do C++ a Java

IIOP, DII/DSI

Event Service, Naming Service, Interface Repository

rozšířené datové typy v IDL

podpora implementace a aktivace objektů (implementation repository, transient

and persistent object references)

bezpečný komunikační protokol IIOP (pomocí SSL, jedná se o doplňující produkt)

vícevláknovou architekturu (multithreads architecture)

interceptory a inteligentní stuby (pro modifikaci komunikace mezi objekty bez

zásahu do kódu objektů)

nástroje pro správu, monitorování systému

podpora pro replikaci serverů,

fault tolerance

utility pro začlenění do WWW

(GateKeeper)



Webové adresy

OMG: http://www.omg.org

VisiBroker hlavní stránka: http://www.inprise.com/visibroker