re") se staly jedním z fenoménů současné doby. Jaké výhody přináší použití
komponent při vývoji softwaru?
Trocha historie
Jedním z motorů zlepšování technologií pro vývoj softwaru je snaha o
znovupoužitelnost napsaného kódu. To byl také asi hlavní důvod vzniku
technologie komponent. V dobách velmi dávných začali programátoři používat
procedury a funkce umístěné v knihovnách. Ačkoliv to přineslo veliký pokrok,
programátorům to nestačilo. Přišla doba objektově orientovaného programování a
funkci knihoven nahradily třídy. Ty se v mnoha směrech již blíží koncepci
komponent, ale třídy byly vždy vázány na jeden konkrétní vývojový prostředek.
Ve světě Windows přišla myšlenka dynamicky připojovaných knihoven (DLL), které
byly méně závislé na použitém vývojovém prostředku a byly v binárním tvaru.
Nevýhodou knihoven DLL však byla jejich dostupnost pouze na Windows a také
skutečnost, že je nebylo vždy možné modifikovat bez nutnosti rekompilace
programu, který je využíval.
Přichází věk komponent
Komponenty jsou v tomto směru posledním vývojovým stupněm. Jedná se o takovou
část kódu v binární podobě, jejíž rozhraní je v přesně definovaném a
normalizovaném tvaru, takže je zcela nezávislá na použitém vývojovém prostředku.
Snaha využít již jednou hotový kód však není jedinou výhodou z použití
komponent. Ukazuje se, že komponenty jsou vhodným nástrojem pro transparentní
řešení distribuovaných úloh. Z hlediska implementace je totiž jedno, zda bude
daná komponenta spuštěna na lokálním nebo na vzdáleném systému. O vyvolání
komponenty a komunikaci s komponentami se nemusíte starat, ať už jste tvůrce či
uživatel o vše se totiž postará příslušná technologie.
Není všechno zlato
Vývoj s použitím komponent má nepochybně své výhody, ale je třeba počítat i s
určitými obtížemi.
Vážným problémem může být správa aplikace složené z komponent. Pokud je
aplikace "monolit" v podobě EXE souboru, není problém jej snadno instalovat na
kterýkoliv počítač. Správa aplikace, která je rozložena do mnoha souborů DLL,
OCX apod. (jež je navíc obvykle nutné korektně zaregistrovat), je obvykle
náročnější.
Důležité je při vývoji aplikace správně navrhnout rozložení na jednotlivé
komponenty tj. určit, jak velkou funkcionalitu zapouzdřit do jedné komponenty,
aby se maximalizovala možnost znovupoužití. Ukazuje se, že tuto vlastnost
nejlépe splňují komponenty "střední velikosti". Příliš malé komponenty nemají
vlastně smysl a příliš velké jsou zase málo flexibilní.
Je třeba si uvědomit, že při přístupu ke komponentě je nutné vykonat poměrně
velké množství kódu, který řeší předávání parametrů a vrácení výsledku v
porovnání s vyvoláním nějaké procedury v běžných vývojových prostředcích je
kódu mnohem více. Je proto nutné počítat s tím, že časté vyvolávání metod
nějaké komponenty bude značně brzdit zpracování (zejména pokud je komponenta
spuštěna jako samostatný proces). Při definování jednotlivých komponent
vyvíjeného systému je proto nutné myslet na to, aby komunikace mezi nimi byla
co nejmenší.
V literatuře o komponentovém programování je často popisován "programátorský
ráj", kde na všechno je nějaká komponenta a vývoj aplikace spočívá jen v jejich
propojování.
Už dnes je možné si poměrně snadno přímo na Internetu zakoupit mnoho různých
komponent. Problém je ale v tom, že u takovýchto komponent není nijak
garantována kvalita a obvykle ani není k dispozici technická podpora. Tvůrci
aplikací proto nechtějí riskovat, že zakoupená komponenta (od které obvykle
nemají k dispozici ani zdrojový kód) se bude chovat za všech okolností
korektně, a proto obvykle preferují vlastní tvorbu. Je však možné, že vznikne
několik velkých dodavatelů komponent, kteří budou schopni zajistit technickou
podporu a garantovat (alespoň svou autoritou) kvalitu.
Obecné vlastnosti
Na komponentu se můžeme dívat podobně jako na objekt její funkcionalita je
přístupná prostřednictvím volání metod. Komponenty se popisují obvykle různými
mutacemi jazyka IDL (Interface Definition Language). V takovém popisu komponent
je možné najít jejich rozhraní (interface), jejich metody a parametry a
návratové hodnoty těchto metod. Vývojové prostředky obvykle generují příslušné
popisy komponent automaticky a obdobně také zpracovávají popisy od cizích
komponent.
Aby se klientská strana ani komponenta nemusely starat, jakým způsobem probíhá
komunikace mezi klientem a komponentou, vývojové prostředky (ve spolupráci s
komponentovou infrastrukturou) jsou schopny automaticky vygenerovat objekty,
které tuto komunikaci zajišťují v případě, že komponenta není připojena ve
stejném procesu.
Proces volání komponenty by se dal popsat následujícím způsobem: v případě, že
komponenta i klient běží ve stejném procesu, komunikují spolu přímo a
vyvolávání komponenty by se dalo přirovnat k vyvolávání běžných funkcí a metod.
Pokud běží komponenta i klient v samostatných procesech (anebo na samostatných
počítačích), jsou mezi ně vloženy objekty proxy a stub (podle terminologie
CORBA to jsou objekty stub a skeleton).
Proxy objekt běží v procesu klienta a nabízí stejné rozhraní, jaké poskytuje
daná komponenta. Klient může s tímto proxy objektem komunikovat přímo, jako by
to byla komponenta, kterou proxy objekt zastupuje. V případě, že klient vyvolá
některou z jeho metod, proxy objekt provede pouze tzv. "marshalling" (převod
parametrů do nějaké standardní podoby) a začne komunikovat s příslušným stub
objektem.
Konkrétní způsob komunikace mezi objekty proxy a stub probíhá podle
komponentové technologie a možností příslušných systémů. Pro komunikaci mezi
lokálními procesy se využívá obvykle nějaká forma meziprocesové komunikace; pro
komunikaci mezi různými počítači se používá obvykle RPC (Remote Procedure Call
standardizovaný postup pro volání vzdálených procedur). Stub objekt, který běží
v procesu komponenty, převezme parametry od proxy objektu, provede jejich
unmarshalling (převod z nějaké standardizované podoby do formátu lokálního
systému) a přímo zavolá příslušnou metodu dané komponenty. Komponenta již může
být ze stub objektu vyvolána přímo, a ani přitom nemusí vědět, zda je
vyvolávána přímo, nebo nepřímo. Proces vracení výsledku je obdobný.
Druhy volání
Při využívání komponent rozlišujeme dva způsoby volání synchronní a
asynchronní. Pokud klientská strana přerušila zpracování po dobu, kdy čeká na
odpověď od komponenty, jde o zpracování synchronní. V případě, že klientská
strana pokračuje nadále ve své práci, jde o zpracování asynchronní. Obecný
trend je rozšiřování asynchronního režimu práce.
Při tvorbě komponent je také důležité rozhodnout, zda bude komponenta schopna
paralelního zpracování více požadavků. Paralelní zpracování může zrychlit
průchodnost systému, ale je daleko obtížnější na realizaci. Je nutné zajistit,
aby jednotlivé zpracovávané požadavky nezpůsobovaly kolize uvnitř komponenty.
Na komponentové technologie úzce navazují transakční servery. Ty nabízejí
hostitelské prostředí pro komponenty, kterým poskytují jisté nadstandardní
služby. Podle konkrétní implementace serveru a komponent nabízejí servery lepší
administraci, možnost nastavování bezpečnostních pravidel pro komponenty apod.
Mezi hlavní funkce ale patří řízení transakcí nad komponentami. S tím také
souvisí tvorba "stavových" (stateful) komponent, které mohou být "předávány"
podle potřeby mezi různým klienty, což šetří systémové prostředky. Častou
službou je také sdílení databázových připojení, které opět šetří systémové
prostředky a zrychluje přístup k datům.
Komponenty (D)COM
Komponentový model COM (Component Object Model) od firmy Microsoft je dnes asi
nejužívanějším standardem. Model se dokázal komerčně prosadit a dnes existuje
již ohromné množství aplikací, které jsou na této technologii vystavěny. Model
COM Microsoft dříve označoval termínem OLE, a tímto způsobem je v některých
zdrojích označován dodnes.
Ačkoliv je technologie COM koncipována jako nezávislá na vývojovém prostředku,
některé vlastnosti jsou zjevně ušity na míru Visual Basicu. Tomuto nástroji
vyhovoval nejvíce model zvaný OLE Automation (dnes jen Automation). V OLE
Automation musí mít komponenta interface IDispatch a v něm metodu Invoke.
Metody komponenty se vyvolávají prostřednictvím metody Invoke, jejímž
parametrem je jednak číslo volané metody, jednak její parametry (ve velmi
nepřívětivém formátu). Číslo volané metody je samozřejmě možné zjistit jinou
metodou. Tvorba těchto komponent v jiných nástrojích, než je Visual Basic, je
velmi nepříjemná, a z tohoto důvodu Microsoft od tohoto modelu pomalu ustupuje.
Microsoft posléze přišel s rozšířením technologie COM o distribuované
zpracování, které nazval DCOM (Distributed COM). Jelikož už technologie COM a
DCOM prakticky srostly dohromady, ono "D" na počátku se někdy neuvádí. Poslední
novinkou v této technologické řadě je technologie COM+, která bude uvedena s
novými Windows 2000.
Technologie COM byly původně koncipovány pro platformy 32bitových Windows.
Omezená verze je k dispozici také na Windows CE.
Později začal Microsoft usilovat o implementaci této technologie i na jiných
platformách. V současné době existuje implementace COM na počítačích Macintosh
a některých Unixech. Je však třeba říci, že tyto implementace nefungují zcela
uspokojivě, a pokud chcete aplikaci distribuovat mezi více platforem, je asi
vhodnější použít jinou komponentovou technologii.
Veškeré komponenty a rozhraní jsou označeny "globálně unikátním
identifikátorem" (GUID), což je 16B číslo. To je automaticky vygenerováno při
vytváření komponenty ze sériového čísla síťové karty, času a několika náhodných
čísel (pravděpodobnost, že na světě vzniknou dva objekty se stejným GUID je
zanedbatelně malá). Jelikož vyvolávání komponent pod těmito identifikátory by
přinášelo jisté problémy, má každý objekt také běžné jméno.
Na rozdíl od jiných architektur může komponenta COM nabízet více rozhraní tedy
více sad metod, které nabízí klientským aplikacím.
Informace o rozhraních a komponentách jsou v technologii COM uchovávány v tzv.
"typových knihovnách" (type libraries) v binární podobě. Pomocí dodávaných
nástrojů jsou však převoditelné zpět do textové podoby v jazyce Microsoft IDL.
Tyto typové knihovny mohou být samostatné soubory, ale mohou být také součástí
souborů dll, ocx nebo exe.
Jelikož je na proces instancování komponent v paměti vhodné aplikovat objektový
přístup, byla pro tyto účely zavedena tzv. Class Factory. Komponenta může být
klientskou stranou využívána trojím způsobem. Může běžet s klientem ve stejném
procesu (in-process), v samostatném procesu (out-process) anebo na vzdáleném
počítači (remote process). Implementace komponent, které poběží v samostatném
procesu anebo na vzdáleném počítači, je obtížnější, neboť v takovém případě
není možné snadno předávat parametry a návratové hodnoty. Další problémy
souvisejí s tím, že v případě distribuovaných aplikací může být na každém
počítači jiný způsob kódování numerických datových typů a ostatně i znakových
datových typů.
Možností je celá řada
Standard COM také přinesl možnost "složených dokumentů". Technologie COM
zajišťuje manipulaci se souborem, do kterého se ukládají data z více
perzistentních COM objektů. V praxi je tento mechanismus implementován
prakticky ve všech kancelářských aplikacích (běžících na platformě Windows),
které potřebují do jednoho dokumentu uložit text s obrázky, grafy, tabulkami,
zvukem a v podstatě čímkoliv dalším.
Výhodou technologie COM je, že definuje poměrně speciální typy komponent, které
mají předepsané určité chování. Příkladem mohou být prvky ActiveX, které slouží
jako uživatelské prvky v různých oknech. Jako další lze uvést tzv. Automation
objekty (komponenty, použitelné ve Visual Basicu přes rozhraní IDispatch).
Mnoho aplikací, např. Microsoft Management Console nebo Visual InterDev,
definuje požadavky na komponenty, které bude tato aplikace využívat jako
průvodce (wizardy).
Microsoft dodává také Microsoft Transaction Server, což je klasický transakční
server pro platformu Windows. Zajímavý je také Microsoft Message Queue Server,
který zajišťuje bezpečné (tj. bezeztrátové) předávání zpráv mezi částmi
systému, které nejsou trvale spojeny anebo jsou spojeny nespolehlivými spoji
(např. Internetem). Infrastruktura MSMQ zajišťuje výběr vhodné dostupné linky
(k dispozici je též optimalizace dle nákladů).
Architekturu COM podporují snad všechny vývojové prostředky pro platformu
Windows, tedy nástroje od Microsoftu, Inprise, Sybase a dalších firem.
Pro tvůrce informačních systémů je pak důležité, že implementace komponentové
architektury COM je (včetně transakčního serveru) k dispozici zdarma ve všech
32bitových Windows.
COM+
S novými Windows 2000 bude také uvedena nová verze technologie COM+, která
rozšíří standard COM o nové prvky.
COM+ rozšíří komponenty o možnost využití atributů a událostí. Využití atributů
sice nepřináší v podstatě nic nového, ale jejich využití může být přirozenější.
COM+ také nabídne infrastrukturu pro šíření zpráv (událostí) objektům, které o
to požádají. Události bude možné šířit synchronně i asynchronně.
COM+ se zaměří rovněž na rozšíření služeb a součástí architektury se stane
Microsoft Transaction Server a Microsoft Message Queue Server. Důležitou
službou je mj. rozkládání zátěže (load balancing). Mezi klienty a servery bude
v COM+ možné vložit nový prvek, "router". Ten bude sledovat dobu odezvy
jednotlivých serverů a na základě těchto údajů směrovat požadavky nových
klientů. Další novinkou bude podpora "In-Memory Database" tedy databáze
umístěné přímo v paměti. Microsoft slibuje plně transakční databázi, ke které
bude možné přistupovat přes ADO/ /OLE DB.
CORBA
Hlavní současný konkurent modelu COM, architektura CORBA (Common Object Request
Broker Architecture), je přímo koncipována pro vývoj distribuovaných aplikací.
Byla vyvinuta mnoha velkými softwarovými společnostmi, které jsou členy
sdružení OMG. V současnosti je CORBA k dispozici ve specifikaci 2.2.
Architekturu CORBA tvoří (kromě již známé komponenty, klienta a pomocných proxy
a stub objektů) také poměrně mnoho dalších prvků. Je to především ORB (Object
Request Broker), který zajišťuje vyhledávání volané komponenty v distribuovaném
systému a obstarává přenos požadavků, parametrů a výsledků. Vlastní komunikaci
mezi ORB zajišťuje protokol GIOP (General Inter-ORB Protocol). Mutace
protokolu, která využívá TCP/IP, je nazývána IIOP (Internet Inter-ORB Protocol).
CORBA je jako jediná z komponentových architektur opravdu nezávislá na
platformě je implementována na platformách Windows, Macintosh a Unix, v Javě a
možná ještě na dalších platformách. Tuto technologii je také možné vcelku
uspokojivě implementovat v neobjektových jazycích.
Problém však je, že výsledkem práce OMG je "pouze" specifikace architektury
CORBA, nikoliv však konkrétní implementace. Tato specifikace popisuje různé
věci s různou mírou přesnosti. Proto se jednotlivé implementace této
architektury od různých výrobců mírně liší a nejsou mezi sebou zcela
kompatibilní.
CORBA nabízí poměrně velké množství objektově orientovaných služeb, jež jsou
definovány ve zvláštních standardech. Jsou to např. "Naming Service", který
zajišťuje jmenné služby, "Life Cycle Service", který řídí vytváření a rušení
objektů, "Persistent Object Service", který se zabývá ukládáním dat
perzistentních objektů, "Transaction Service", který je určen pro řízení
transakcí, atd.
CORBA je přímo navržena pro distribuované využití pro volání lokálních
komponent je poněkud těžkopádná (nicméně i to je možné). Při distribuovaném
zpracování nabízí CORBA infrastrukturu pro automatické vyhledání volaného
objektu v distribuovaném systému. Klient se tedy nemusí starat o to, kde zrovna
která komponenta běží.
9 1653 / pahn
Komponentový boj
Mezi silné stránky technologie COM patří snadná instalace, správa a doplňkové
služby. Silnou stránkou architektury CORBA je naproti tomu široká paleta
nativních implementací pro mnoho platforem. Komponenty Enterprise JavaBeans
umožňují využít jednu implementaci na všech platformách.
Jelikož jsou si jednotlivé komponentové architektury značně podobné, mnoho
vývojových prostředků bude v budoucnu umožňovat generování více typů komponent
z jednoho zdrojového kódu. Proto lze předpokládat, že z pohledu tvůrců se budou
rozdíly jednotlivých architektur smývat a distribuované zpracování se bude
stávat stále transparentnější. Na druhé straně Microsoft usilovně pracuje na
zabudování určitých unikátních prvků do své architektury, a tímto způsobem chce
vývojářům nabízet přístup ke speciálním možnostem.
Enterprise JavaBeans
Specifikaci Enterprise JavaBeans přivedlo na svět sdružení vedené firmou Sun
Microsystems. Technologie je založena na platformě Java. Konkrétní implementace
serverových komponent je tedy platformově nezávislá a takto implementované
komponenty mohou být umístěny kamkoliv, kde pracuje Java.
Celá specifikace je poměrně nová, byla zveřejněna přibližně před rokem. Od té
doby je tato architektura zkoušena teprve na několika pilotních projektech a
prototypech. Firma Sun Microsystems oficiálně nestaví tuto architekturu jako
konkurenci vůči technologii CORBA, ale spíše jako její doplněk.
Architektura Enterprise JavaBeans 1.0 je stavěna na JDK 1.1. Příští specifikace
už bude údajně stavěna na standardu Java 2.
EJB využívá různých standardů Javy: Pro vyvolávání metod je používána třída RMI
(Remote Metod Invokation). Pro práci s transakcemi je zase využíván standard
Java Transaction API (JTA). Architektura EJB také logicky navazuje na
komponenty JavaBeans, které se vesměs používají na implementaci prvků
uživatelského rozhraní. Firma Sun Microsystems také pracuje na referenční
implementaci technologie Enterprise JavaBeans, kterou bude používat mimo jiné
pro testy kompatibility komponent.
Architektura Enterprise JavaBeans pracuje se třemi základními pojmy klient,
server a kontejner (container). Kontejner je entita, kterou hostí jednotlivé
servery. Klienti nekomunikují přímo se servery, ale komunikují s nimi
prostřednictvím kontejnerů.
V EJB rozeznáváme dva typy komponent (beanů) "Session Beans" a "Entity Beans".
"Session Bean" je vytvářen na serveru klientem a pro klienta provádí různé
operace. Tyto komponenty mohou být stavové, mohou být zařazeny do transakcí,
ale v případě havárie systému nejsou obnovitelné.
"Entity Bean" je komponenta, která reprezentuje nějaká perzistentní data, jež
jsou uchovávána v nějakém datovém zdroji (např. databázi). Jednotlivé instance
"Entity Bean" jsou identifikovány primárním klíčem. Tyto komponenty mohou být
také zařazeny do transakcí a mohou být v případě havárie systému obnoveny.
Architektura Enterprise JavaBeans nabízí také skupinu služeb, kterou poskytuje
komponentám. Jsou to služby spojené s životním cyklem objektů (vytváření a
uvolňování), bezpečností, transakcemi, perzistencí a správou stavu.
Velkým kamenem úrazu pro celou technologii je, že Java zatím příliš nepronikla
do enterprise systémů. Architektura EJB je zatím v porovnání s technologiemi
CORBA a DCOM používána nejméně. Zatím je podporována např. v nástrojích firem
Sybase, Inprise a Oracle.
PŘEDPLATNÉ
ČLÁNKY DO MAILU