|
Common Object Request Broker Architecture - CORBA
Common Object Request Broker Architecture - CORBA
OBSAH2 ÚVOD2 VÝVOJ DISTRIBUOVANÝCH SYSTÉMŮ3 Monolitické systémy Architektura klient/server Distribuované systémy CORBA HISTORIE6 ARCHITEKTURA6 Object Request Broker (ORB) Interface Definition Language (IDL) CORBA a komunikační model CORBA a objektový model CORBA klienti a servery Skeleton serveru a stub klienta CORBAservices a CORBAfacilities JINá ŘEŠENí14 BSD sockets Remote Procedure Call (RPC) OSF Distributed Computing Environment (DCE) Distributed Component Object Model (DCOM) Java Remote Method Invocation (RMI) ZáVĚR16 APENDIX17 Seznam použité literatury Seznam obrázků Rejstřík termínů
Úvod Co to CORBA je a k čemu se používá? Pokusím se ve zkratce odpovědět. Řekněme, že potřebujeme vytvořit aplikaci, jejíž části spolu budou komunikovat pomoci počítačové sítě. Můžeme použít například už téměř klasickou komunikaci pomocí soketů. Při tomto způsobu jedna část aplikace do navázaného soketu zapisuje a druhá čte. Toto řešení je však značně nízko-úrovňové, neboť umožňuje posílat jen bloky bytů a vyžaduje znalost spousty detailu komunikace. Při vývoji složitějších aplikací je výhodnější použít distribuovanou architekturu jako je CORBA. Programátor potom pouze používá služeb (volá metody) jiných objektu a CORBA zajistí všechnu potřebnou komunikaci. Dokonce ani komunikace mezi různými platformami není problém, stačí pouze mít k dispozici pro danou platformu příslušný produkt splňující podmínky architektury CORBA. Ve svém referátu jsem se zaměřil zejména na vysvětlení principů a nejzajímavějších vlastností systému CORBA. Při popisu architektury jsem se snažil co nejméně zabíhat do podrobností a soustředil jsem se na části zajišťující takové zajímavé vlastnosti jako nezávislost na platformě. Nezabývám se zde implementací aplikací a neuvádím ukázky kódu, a proto tento text neposkytuje návod jak napsat fungující aplikaci. Za tímto účelem je možné použít například článek "Writing CORBA Aplications", který napsal Dr. Douglas C. Smith nebo dokument [1]. Nejprve uvedu něco o vývoji distribuovaných systémů a architektury CORBA, aby bylo zřejmé, proč tento systém vůbec vznikl a kde má své uplatnění. Potom popíši architekturu, abych ji mohl na konci porovnat s jinými existujícími řešeními (např. DCOM). Nejdůležitější termíny jsem trochu "vysunul" z ostatního textu, aby bylo snadné se k nim v případě potřeby vrátit. Seznam těchto termínu je umístěn na konci toho referátu. Předpokládám, že čtenář zná základní principy objektového programování, znalost konkrétního jazyku však není nutná.
Vývoj distribuovaných systémů Při popisu vývoje distribuovaných sytému začneme u monolitických systémů, potom se podíváme, jak byl tento sytém ovlivněn nástupem PC (osobních počítačů) a vznikl model klient/server. Dále budeme pokračovat vlivem Objektově Orientovaného Programování a následným objevem distribuovaných systému, abychom skončily u tak flexibilního systému jako CORBA.
Monolitické systémy Pomineme-li dávkové zpracování, stojí na začátku vývoje mainframe (sálový počítač) se svými terminály. Sálové počítače se objevily, neboť oproti dávkovému zpracování nabízely interakci s procesy. Terminály zajišťovaly pouze přístup k sálovému počítači, kde běžela celá aplikace. Jeden mainframe byl schopný obsloužit zároveň velké množství klientů. Mezi výhody také patří centralizovaný charakter, který umožňoval relativně snadnou administraci systému a poměrně snadnou implementaci aplikací (nejsou kladeny žádné velké speciální požadavky). Nevýhodou byl často monolitický software - uživatelské rozhraní, výkonná část a přístup k datům byly obsaženy v jedné velké aplikaci, a proto jakákoliv změna mohla ovlivnit celou aplikaci.
obr.1 Monolitický systém
Architektura klient/server Nástup osobních počítačů umožnil změnu aplikačního modelu. Zatímco předchozí programy vyžadovaly mainframe pro celý běh, dovolila architektura klient/server přenést část zátěže na desktopy uživatelů a tím pádem i zlepšit uživatelské rozhraní. Sever je v tomto případě počítač nebo část aplikace, která nabízí služby klientům. Spolu s revolucí v architektuře přišel rozvoj na UNIXu založených serverů, neboť tyto servery mohly být menší a cenově výhodnější než sálové počítače. Klient/server aplikace typicky rozdělily aplikaci tak, že databáze sídlila na serveru, uživatelský interface na klientovi a logika aplikace mohla být na jedné nebo na obou stranách. Dnes se tento typ klient/serveru nazývá dvouvrstvý. Přestože toto řešení odstraňuje problémy předchozího modelu jako je monolitičnost softwaru, nevyhnulo se vlastním chybám. Například máme-li aplikaci komunikující s databází pomocí dotazů, potom změna v přístupu k databázi nebo dokonce změna databáze samotné vyžaduje přepsat klienty a dopravit je ke všem uživatelům. Problémy dvouvrstvého klient/serveru tak daly vzniknout modelu vícevrstvého klient/serveru. Obecně může mít aplikace libovolně vrstev, nejoblíbenější je však dělení do tří vrstev: uživatelské rozhraní, logika aplikace a přístup k datům. Vícevrstvá architektura klient/server zlepšuje původní verzi dvěma způsoby. První je celková izolace klienta od zbytku aplikace a ne jenom izolace interface jako u dvouvrstvého klient/serveru. To zvyšuje odolnost a částečně i flexibilitu aplikace. Nabízí také větší oddělení a izolaci mezi vrstvami. Uživatelské rozhraní komunikuje s hlavní častí aplikace a nikdy ne přímo s vrstvou zajištující přistup k databázi. Hlavní část potom komunikuje s uživatelským rozhraním na jedné straně a s vrstvou přistupující k databázi na straně druhé. Proto změny v přístupu k databázi neovlivní vrstvu uživatelského rozhraní, neboť jsou od sebe izolovány. Tato architektura umožňuje vytvářet aplikace s menší pravděpodobností ovlivnění klienta (které by znamenalo jeho redistribuci). Druhým vylepšením je větší volnost v rozmístění aplikace. Protože vícevrstvá architektura klient/server dělí aplikaci na více nezávislých částí, je možné například umístit výpočet aplikace na jeden server, zatímco přístup k databázi bude zajišťovat server jiný. Pokud to povaha řešení dovolí můžeme také u složitých výpočtů rozdělit zátěž na více počítačů.
obr.2 Vícevrstvý klient/server
Distribuované systémy Příchod Objektově Orientovaného Programování (OOP) znamenal další krok ve vývoji architektury aplikaci. Přidáním základních principům OOP jako encapsulation (zapouzdření), inheritance (dědičnost) a polymorphism (polymorfismus) vznikl z předchozího model distribuovaný. Místo rozlišování mezi vrstvami, si tento model představuje aplikaci jako objekty, které mohou používat služby nabízené jinými objekty v systému nebo samy tyto služby nabízet. Tato architektura může smazat rozdíly mezi klientem a serverem, neboť se objekt může chovat jako klient k jednomu objektu a zároveň být serverem pro jiné objekty. Distribuované systémy jsou v podstatě vícevrstevné klient/server systémy, kde počet různých klientů a serverů může být obrovský. Tento model je dnes vrcholem flexibility. Architektura distribuovaných systémů dosahuje své pružnosti vyžadováním definice interfacu mezi komponentami (část systému např. nějaký objekt). Interface komponenty specifikuje ostatním komponentám, které služby komponenta nabízí a jak se mají používat.
Termín: Interface (rozhraní) definuje protokol komunikace mezi dvěma oddělenými komponentami systému. (tyto komponenty mohou být oddělené procesy, objekty, uživatel a aplikace -- jakékoliv oddělené jednotky, které spolu potřebují navzájem komunikovat). Interface popisuje, které služby jsou nabízeny a způsob jejich použití. V případě objektů může být interface množina metod definovaných objektem včetně počtu a typů parametrů.
Dokud zůstane rozhraní beze změn, může se implementace komponenty dramaticky měnit, aniž by to ovlivnilo jiné komponenty. Například u komponenty nabízející seznam zboží ve skladu, pokud se nezmění domluvené rozhraní, vůbec nezáleží, jakým systémem je databáze zboží provedena. Kromě flexibility přineslo použití objektů také větší úroveň abstrakce a následně redukci složitosti, neboť zapouzdření izoluje programátora od detailů sytému. Také je možné skládat části aplikace z již existujících komponent. Distribuované systémy navíc poskytují dodatečné služby - tykající se bezpečnosti, uschování objektů nebo adresářové služby, které umožňují hledat jiné komponenty.
Termín: Directory services (adresářové služby) je sada služeb, které umožňují objektům (serverům, společnostem, lidem) se navzájem vyhledávat. Ne jenom typy objektů se mohou lišit, dokonce způsoby uložení těchto informaci mohou být různé. Například telefonní seznam se používá k hledaní telefonních čísel a adresář pro nalezení adres. Adresářové služby seskupují související informace dohromady (jako "žluté stránky").
Adresářové služby je možné použít i k rozložení zátěže v systému, klient se prostě se svým požadavkem obrátí na nejméně zatíženou komponentu. CORBA nabízí tyto a spoustu jiných služeb pod názvy CORBAservices a CORBAfacilities. Vše bych shrnul asi následovně. Vývoj probíhal od relativně křehké monolitické architektury až po velmi pružnou, jak ji známe dnes. Během této dlouhé cesty umožňovaly architektury vývoj stále robustnějších a více rozčleněných aplikací.
CORBA CORBA je jednou z možností jak vyvíjet distribuované aplikace. Distribuované systémy spoléhají na definici rozhraní mezi komponentami a na existenci různých služeb pro aplikaci. CORBA nabízí jak mechanizmus definice rozhraní mezi komponentami tak i nástroje pro implementaci komponent v jazyce, který si programátor vybere. Dosahuje toho pomoci speciálního jazyku pro definici rozhraní. Také je možné vygenerovat část klienta a serveru zajišťující převod komunikace z na jazyce nezávislého formátu do jazyka zvoleného pro implementaci komponent. Navíc je specifikována zdravá sada standardních služeb, které mohou komponenty používat, jako například adresářové služby. Nakonec CORBA poskytuje všechno to potrubí, zajišťující komunikaci různých komponent aplikací. Dvě nejzajímavější vlastnosti, které CORBA nabízí, tedy jsou nezávislost na platformě a nezávislost na programovacím jazyce. Nezávislost na platformě znamená, že CORBA aplikace mohou komunikovat s jakoukoliv platformou, pro kterou existuje implementace "CORBA serveru" (nazývá se ORB). Nezávislost na jazyce znamená, že implementace klienta i serveru může být provedena v jakémkoliv jazyce pro které existuje kompilátor z jazyku pro definici rozhraní do tohoto jazyka. V kapitole zabývající se architekturou se zaměřím na časti, které tyto klíčové vlastnosti umožňují. Samozřejmě, že CORBA má i své nevýhody, konkrétně zajištění předchozí vlastnosti vyžaduje určitou režii. Dále pro psaní jednoduchých aplikací není potřeba použít takto složitý a místy trochu těžkopádný nástroj.
Historie Následuje krátký přehled vývoje standardu CORBA. V roce 1989 byla založena organizace Object Management Group (OMG), tato skupina má vytvořit obecnou soustavu architektur pro objektově orientované aplikace založených na specifikaci rozhraní. Tohoto cíle dosáhla OMG zveřejněním architektury Object Management Architecture (OMA), jehož součástí je také CORBA. Hlavní částí OMA je Object Request Broker (ORB), dále obsahuje služby objektům (CORBAservices) a příslušenství (CORBAfacilities). Úlohou CORBA v této architektuře je realizovat žádosti o objekty (ORB funkce). První verze vznikla v roce 1990, následovala CORBA 1.1 obsahující jazyk pro definici rozhraní -- Interface Definition Language (IDL). To však byl jen první krok, nikoliv kompletní specifikace, neboť nedefinovala komunikaci mezi ORB servery, a proto byly implementace od různých výrobců nekompatibilní. Tyto problémy řeší CORBA 2.0 uvolněná roku 1994, která definuje protokol pro komunikaci mezi ORB -- Internet Inter-ORB Protocol (IIOP). IIOP bohužel řeší předchozí problém pouze u sítí založených na protokolu TCP/IP. Vývoj pokračoval drobnějšími změnami až do aktualní verze 2.2.
Architektura Vývoj distribuovaných systému máme za sebou, nyní můžeme prozkoumat architekturu. Především je CORBA objektově orientovaná architektura, a proto u ní vidíme všechny rysy typické pro objektově orientované systémy, včetně dědičnosti rozhraní a polymorfismu. Rozlišujeme dva druhy dědičnosti.
Termín: Interface inheritance (dědičnost rozhraní) toto pojetí by mělo být známe programatorům pracujících v Jave či Objective C. Zde může být odvozen jeden interface od jiného, aniž by existovala vazba mezi implementacemi. Naproti tomu v implementation inheritance (dědičnost implementace), se dědí přímo kód třídy (např. C++).
Velmi zajímavá je možnost používání CORBA v neobjektově orientovaných jazycích jako C a COBOL, přesto je však práce v objektově orientovaných jazycích přirozenější.
Nyní postupně probereme jednotlivé části architektury:
Dále se podíváme na:
Object Request Broker (ORB) 36852nvl15gxx6h Jak jste asi uhodli, prvním základním kamenem Common Object Request Broker architecture je Object Request Broker (ORB). Je to softwarový prostředek, který zajišťuje komunikaci mezi objekty. Za pomoci ORB může klient transparentně volat metody jiných objektů tím přistoupit na požadované služby. Volané objekty mohou sídlit na stejném počítači jako klient nebo kdekoliv v síti.
Nezávislost na platformě Účelem ORB je také zajistit nezávislost komunikace na platformě. Všechny parametry jsou před posláním upraveny do formátu nezávislého na platformě. Po přijetí jsou naopak z toho nezávislého formátu převedeny do tvaru stravitelného cílovou platformou. Například klient běžící na systému počítačů Macintosh může volat služby poskytované UNIXovým serverem. Rozdíl nemusí být jen v operačním sytému, ORB se postará dokonce i o rozdíly v hardware (např. malý a velký endian). V podstatě je možné komunikovat s jakoukoliv platformou, pro kterou existuje implementace ORB. Neboť celý proces předávání parametrů je prováděn transparentně k serveru i ke klientovi, nemusí se programátor s tím souvisejícími detaily zabývat.
Přenos parametrů Postup jakým probíhá volání metody je následující. Nejprve musí komponenta aplikace získat odkaz na objekt, jehož služby chce využívat. Učinit to může například použitím adresářových služeb (str. 5). Pokud ORB přijme požadavek o volaní, nalezne požadovaný objekt a připraví ho na přijetí požadavku. Dále přenese vstupní parametry, zajistí vyvolání požadované metody a výstup vrátí zpět klientovi. ORB po přijetí vstupní parametrů od volající komponenty provede takzvaný marshaling těchto parametrů. To znamená, že ORB přeloží tyto parametry do formátu nezávislého na platformě, který může být přenesen k implementaci ORB u volaného objektu. Potom ORB provede naopak unmarshaling těchto parametrů. Prostě po přenosu převede parametry do formátu, kterému volaná komponenta rozumí.
Termín: Marshaling parametrů je proces, převodu parametrů do formátu přenášeného po síti. Termín: Unmarshaling parametrů je opakem, přeloží po síti přenesená data do parametrů metody.
Celý proces přenosu parametrů se odehrává bez jakéhokoliv zásahu programátora. Klient jednoduše zavolá požadovanou vzdálenou metodu a je mu vrácen výsledek, přesně jako u volání lokálních metod. Celý proces skládající se z marshalingu vstupních parametrů, přenesení, unmarshalingu, spuštění metody na volaném serveru, marshalingu výstupních parametrů, přenosu zpět, unmarshaling a návratu výstupních parametrů provádí ORB automaticky a transparentně.
obr. 3 Object Request Broker
Přehled Princip fungování ORB je pro pochopení architektury CORBA nezbytný a proto nabízím krátký přehled:
Interface Definition Language (IDL) Druhým základním kamenem architektury CORBA je IDL. IDL je jazyk používaný pro definici interfaců mezi komponentami. Každá komponenta má svůj interface popsán v jazyce IDL. Zdůrazňuji, že IDL není jazyk pro psaní funkcí objektů, pouze specifikuje interface komponent, proto není možné napsat aplikaci v IDL.
Termín: Interface Definition Language (IDL) je jazyk používaný k definici rozhraní (interface) CORBA objektů.
Programátoři v C++ si mohou soubor napsaný v jazyce IDL představit jako hlavičkový soubor, je to vlastně definice třídy bez implementace metod.
Nezávislost na jazyku Účelem IDL je umožnit programátorovi implementovat klienta a server v jazyce, který si sám vybere. Dosahuje toho pomocí principu mapování jazyka (language mapping).
Termín: Language mapping (mapování jazyka) je proces, který převádí konstrukce jazyka IDL na konstrukce v daném programovacím jazyku.
Například v jazyku IDL je typ long 32-bitové znaménkové celé číslo, které se mapuje na long v C++ nebo int v Javě. Je úkolem specifikace IDL, aby definovala převod na jazyce závislých typů. Organizace OMG definovala spoustu standardních mapování pro mnoho jazyků, samozřejmě mezi ně patří C, C++, COBOL, Java a Smalltalk. Existuje mapování i pro jiné jazyky, ale buď je to privátní řešení, nebo se na jeho standardizaci OMG teprve pracuje. Existence mapování, je jediná věc omezující nezávislost na jazyku.
Použití IDL Při tvorbě aplikace se IDL uplatní následovně. Programátor napíše definici interface komponenty v jazyce IDL. Potom si vybere v jakém jazyce chce napsat implementaci klienta a IDL kompilátor vygeneruje část klienta v požadovaném jazyce. Programátor následně dopíše zbytek. Stejný postup se provede i při implementaci serveru. Jediné, co omezuje výběr jazyka pro implementaci je fakt, že musíme mít k dispozici kompilátor z IDL do námi vybraného jazyku. Nezávislost na jazyce je velmi důležitou vlastností architektury CORBA. Protože použití CORBA nenařizuje použitím určitého jazyku, dává vývojářům svobodu vybrat si jazyk, který nejlépe vyhovuje potřebám aplikace. To je velký krok dopředu, neboť si programátor může dokonce vybrat různé jazyky pro různé komponenty aplikace. Například je možné napsat klientské komponenty v Javě, aby byly nezávislé na platformě, zatímco sever můžeme implementovat pomocí C++ (např. kvůli vysokého výkonu).
CORBA a komunikační model K pochopení CORBA architektury je nutné nejprve porozumět její úloze v počítačových sítích. Typicky se počítačová sít skládá z prvků, které jsou fyzicky spojeny (ačkoliv s nástupem bezdrátových sítí budeme asi muset tento termín přehodnotit). Tato fyzická vrstva prostě poskytuje medium, přes které se může komunikovat. Tímto médiem může být telefonní linka, optický kabel, satelitní propojení nebo jiná kombinace síťových technologií. Někde nad fyzickou vrstvou leží transportní vrstva (podrobnější informace najdete v modelu OSI), která obsahuje protokoly odpovědné za přesun paketů mezi dvěma body. Dnes, v době Iternetu, je pravděpodobně nejběžnější transportní protokol TCP/IP (Transmission Control Protocol/Internet Protocol). Většina aplikací využívajících Internet spolu komunikuje pomocí TCP/IP, to jest včetně aplikací založených na FTP (File Transfer Protocol), SSH (Secure shell) a HTTP (Hypertext Transport Protocol, který je základem služby World Wide Web).
Protokoly pro komunikaci ORB Jak tedy zapadne CORBA do sítového modelu? Velice snadno, neboť specifikace architektury CORBA je nezávislá na síťovém protokolu. Standard CORBA specifikuje General Inter-ORB Protocol (GIOP), což je obecný standard komunikace mezi dvěma různými implementacemi ORB. GIOP je pouze zastřešující protokol, CORBA standard upřesňuje tento protokol pro určité transportní protokoly. Například protokoly vycházející z GIOP existují pro TCP/IP, DCE (Distributed Computing Environment protokol vytvořený organizací Open Software Foundation), navíc výrobci software si mohou definovat a definují vlastní protokoly založené na GIOP pro komunikaci mezi CORBA komponentami. Termín: General Inter-ORB Protocol (GIOP) je velmi obecný protokol pro komunikaci mezi implementacemi ORB, tento protokol se přímo nepoužívá, místo toho se pro určitý transportní protokol specifikuje jiný protokol a ten se potom využívá.
Specifikací GIOP pro sítě založené na TCP/IP vznikl Internet Inter-ORB Protocol (IIOP). Standard CORBA 2.0 vyžaduje, aby výrobci implementovali tento protokol ve svých ORB, mohou však přidat i své vlastní řešení. Je to nutný základ, aby se mohli dvě implementace ORB domluvit. ORB však mohou mezi sebou vyjednávat o použití jiných, například na výrobcích závislých protokolů.
Termín: Internet Inter-ORB Protocol (IIOP) je specializace GIOP. IIOP je standardní protokol pro komunikaci ORB na TCP/IP založených sítích. Každý ORB musí IIOP podporovat, aby splňoval CORBA 2.0 specifikaci. obr. 4 GIOP
Síťový model Následující obrázek ukazuje možnosti síťové části architektury CORBA. Komunikace mezi různými ORB probíhá v protokolech odvozených z GIOP jako například IIOP, tím CORBA vlastně vytváří v této komunikaci novou vrstvu a skrývá pod ní ležící transportní vrstvu. Nyní už je doufám vidět další výrazný rys architektury CORBA, aplikace totiž nejsou omezeny jedním transportním protokolem, protože je možné vytvářet mosty mezi sítěmi s různými protokoly.
obr. 5 Distribuovaná architektura CORBA
CORBA a objektový model Každá objektově orientovaná architektura má svůj objektový model, který popisuje, jak jsou objekty v systému reprezentovány. Nyní se podíváme na tři nejdůležitější rysy CORBA objektového modelu .
Distribuce objektů Pro CORBA klienta volání vzdálené metody vypadá jako volaní běžné lokální metody. Tedy distribuce CORBA objektů je pro klienta transparentní, on ani netuší, že se to odehrává. Ve skutečnosti není předchozí odstavec úplně pravda. Při přenosu objektu se mohou vyskytnou chyby, a proto musí CORBA nabídnout prostředky pro jejich ošetření. To se děje pomocí systému vyjímek, které mohou vzdálené metody generovat. Pokud je detekována chyba, CORBA objekt způsobí vyjímku, ta může signalizovat například síťovou chybu nebo nedostupnost serveru. Vyjímky však mohou generovat i lokální metody.
Reference V distribuovaných systémech může komponenta získat přístup k objektu dvěma způsoby. Jedna metoda je známá jako předávání odkazem (passing by reference), kdy volající komponenta získá pouze odkaz (něco jako pointer) na volaný objekt, a pomocí této reference může k objektu přistupovat, volaný objekt však zůstává na svém původním místě. Druhá metoda se nazývá předávání hodnotou (passed by value). V tomto případě je volající metodě předána kopie požadovaného objektu a operace se potom provádí na této kopii. Jakékoliv změny na této kopii neovlivní originální objekt a naopak změny provedené na originálním objektu neovlivní kopii. Jedním důležitým rysem CORBA objektového modelu je předávání všech objektů odkazem. Organizace OMG však na předávání objektů hodnotou pracuje. Problém při předávání objektu hodnotou v distribuovaném prostředí je, že se volající metoda nemusí mít implementaci funkcí tohoto objektu, neboť komunikující platformy se mohou lišit. Tento problém u předávání odkazem nenastává, protože metody se vykonávají na straně objektu a všechny potřebné převody zajistí ORB. Nevýhodou předávání odkazem je nárůst administrace při složitějších voláních.
Basic Object Adapters (BOAs) Standard CORBA nabízí několik rozhraní mezi implementací objektu a ORB. Tyto adaptéry jsou samozřejmě závislé na implementaci ORB.. Nejpoužívanějším je Basic Object Adapter, který nabízí CORBA objektům sadu metod pro přístup k funkcím ORB, mezi ně patří například autentizace nebo aktivace uložených objektů. Jedna z nejužitečnějších vlastností nabízených BOA jsou různé způsoby aktivace a deaktivace volaného serveru včetně sdílení serveru pro více žádostí nebo start serveru až po příchodu nějakého požadavku.
CORBA klienti a servery vx852n6315gxxx Tradičně, v klient/server aplikacích, se server nazývá komponenta nebo komponenty poskytující služby jiným komponentám. Klient je naopak komponenta využívající služeb serveru. Jistě není překvapením, že architektura CORBA zavádí stejné pojmenování. Komponenta aplikace často nabízí služby jiným komponentám, zatímco sama přistupuje na služby jiných komponent. V tomto případě, jak je vidět na obrázku 6, se komponenta chová zároveň jako server i klient.
obr. 6 Klient a server
Jistě není těžké představit si případ, kde jsou si dvě komponenty navzájem servery a klienty.
Skeleton serveru a stub klienta Nyní už znáte vše potřebné, abychom se mohli podrobněji podívat na ony malé kousky klienta a serveru generované IDL kompilátorem, o kterých jsem mluvil v kapitole o IDL (str. 8). Tyto "kousky" (klient stub a server skeleton) jsou tmelem mezi interfacem komponenty, který je definován pomocí IDL a tedy nezavislý na jazyce použitém pro implementaci, a implemantací klienta a serveru.
Termín: Client stub, který je generován IDL kompilátorem, je malá část kódu, která zpřístupňuje klientovi příslušný interface serveru. Termín: Server skeleton je rovněž generován IDL kompilátorem, je to část kódu vytvářející kostru pro implementaci serveru.
Při vývoji aplikace nejdříve vývojář vytvoří definice rozhraní komponenty za použití jazyka IDL. Potom si vybere jazyk pro implementaci klient a serveru. Dále na soubory s definicí interfaců zavolá IDL kompilátor. Ten vytvoří stub klienta a skeleton serveru v požadovaném jazyce. Stub je pro každý interface vytvořená část kódu, který komunikuje s daným interfacem na serveru. Stub zajistí mapování na jazyce nezávislé komunikace do datových struktur, které používá jazyk použitý pro implementaci klienta. Volání vzdálené metody se prostě děje skrze stub, který navíc sám zabezpečí komunikaci s ORB . Na druhé straně - u serveru stejným způsobem pracuje skeleton. Pro každou metodu interfacu vygeneruje IDL kompilátor prázdnou metodu, kam musí programátor doplnit implementaci této metody. Je v podstatě kostra, na které je server vybudován Výsledek kompilace rozhraní dostaneme v námi požadovaném jazyce. Je možné nechat si vygenerovat stub třeba v Javě, zatímco skeleton budeme požadovat v C++.
obr. 7 Stub a skeleton
Volání vzdálené metody potom vypadá následovně:
obr. 8 Vzdálené volání
Někdy můžeme potřebovat připojit se na interface, který není znám při kompilaci, potom se použije Dynamic Invocation Interface (DII). V tomto případě klient až za běhu zjišťuje, která rozhraní server nabízí. Nicméně používání DII je velmi složité a proto je mimo dosah tohoto článku.
CORBAservices a CORBAfacilities Spoustu věcí je možné splnit s použitím základů CORBA architektury: za pomoci IDL vytvořit interface, implementovat server a vyvinout klienty používající jeho služby. Nicméně někdy nemusí služby, které objektům poskytuje BOA, stačit, a proto OMA (jak již víme je obrovská architektura, jejíž součástí je CORBA) nabízí mnohem víc než tyto základní služby. OMA definuje dodatečný seznam služeb a jejich interface, implementaci však nechává na výrobci. CORBAservices a CORBAfacilities jsou obvykle výrobci dodávány zvlášť a produkt je nemusí obsahovat, aby splňoval standard CORBA 2.0
obr. 9 OMA
CORBAservices CORBAservices jsou různé služby poskytované objektům. Myslím si, že toto není klíčová vlastnost a proto pro přehled uvedu pouze nejzajímavější služby . Event service poskytuje mechanizmus, s jehož pomocí si mohou CORBA objekty posílat události. Služba nabízí doručení a potvrzení doručení události, anonymní zprávy a kanály zprav, kdy objekt dostává jen zprávy, které si objednal. Transaction monitor service dohlíží na transakce mezi objekty. Transakce je sada operací, které musí být prováděny automaticky, to znamená buď všechny účastnící se objekty provedou transakci (a změní své záznamy) nebo všechny objekty transakci zruší a (obnoví své záznamy). Toto je velmi zajímavá služba například pro banky, které také provádějí transakce. Security service obsahuje služby, jako jsou identifikace a autentizace uživatelů, autorizace a řízení přístupu k objektům, podpisy, záznamy a provedených operací .
CORBAfacilites CORBAfacilites je různé příslušenství skládající se ze dvou častí. Za prvé jsou to objekty, které se dají využít v mnoha typech aplikací, a za druhé objekty specifické pro jisté druhy aplikací, například aplikace pro finanční oblast. Mezi tímto příslušenstvím najdeme nástroje pro rychlý vývoj uživatelského rozhraní, přístup k databázím či kolekce. Zatímco v specializované části jsou to například nástroje pro CAD, telekomunikace či lékařství.
Jiná řešení Pokud chceme navrhnout distribuovanou aplikaci není samozřejmě CORBA jedinou možností. Záleží na aplikaci, které řešení je vhodné. Musíme brát v úvahu složitost aplikace, platformu, použitý programovací jazyk atd. V této kapitole uvedu přehled několika alternativ, spolu s jejich výhodami a nevýhodami.
BSD sockets V mnoha moderních systémech se komunikace mezi počítači odehrává přes sokety. Soket je kanál s jehož pomocí se mohou aplikace spojit a komunikovat. Nejpřirozenější je potom používat sokety přímo, jedna aplikace do soketu zapisuje, druhá čte. Nevýhodou, zvláště u složitých aplikací, je, že toto řešení je značně nízko-úrovňové. Vývojář se musí příliš zaměřovat na detaily komunikace, místo aby byl od nich abstrahován. To může vadit zejména při použití komplexnějších datových typů, zvláště pokud druhá strana pracuje na jiné platformě nebo je napsána v jiném programovacím jazyce.Výhodou může být rychlost aplikac&iacut |
