Stavebnice se nejlépe skládá z komponent

Komponenty, komponentové programování a komponentový software (tzv. „componentwa

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.