Komponenty ve službách pracujících procesů

COM, DCOM, COM+, OLE a ActiveX všechny tyto pojmy se vztahují ke komponentové technologii společnosti Microsoft. Ta se ča...


COM, DCOM, COM+, OLE a ActiveX všechny tyto pojmy se vztahují ke komponentové
technologii společnosti Microsoft. Ta se často používá jak v rozsáhlých
informačních systémech, tak i v relativně malých aplikacích.
Nejprve se však zaměřme na problematiku terminologie, čímž se zároveň seznámíme
s historickým vývojem uvedené technologie.

Ohlédnutí
Počátkem všeho byla v roce 1991 technologie Object Linking and Embedding (OLE),
která umožňovala vytvářet dokumenty, jež byly složeny z několika dílčích
dokumentů různých aplikací. Po úspěchu této technologie se Microsoft snažil
technologii OLE zobecnit tak, aby umožňovala ovládání jedné aplikace z druhé.
Tak vznikla technologie zvaná OLE 2 (přičemž původní význam zkratky OLE se
vytratil). Dalším vývojem a dalším propracováváním vnikla na přelomu let 1994 a
1995 technologie nazvaná COM (Component Object Model), která se stala základem
všech dále zmíněných technologií.
Prvním doplněním technologie COM bylo rozšíření o distribuované zpracování. To
přišlo v roce 1996 a nazývá se DCOM (Distributed COM). Poslední novinkou vývoje
této technologie je dlouho připravované COM+, které bylo ve finální verzi
uvolněno teprve letos s Windows 2000. Orientuje se na doplnění komponentových
služeb.
Ačkoliv je původní technologie COM z dnešního pohledu již překonána, často se
pojem COM používá jako souhrnný výraz pro standardy COM, DCOM a nyní i COM+.

Implementace
Microsoft produkuje nejen standard COM (a jeho deriváty), ale také jejich
implementace. Ty jsou často součástí firemních operačních systémů. Jednotná
implementace těchto standardů zajišťuje jednak bezproblémový přenos klientů i
komponent mezi různými systémy s implementací COM, ale také bezproblémovou
komunikaci různých komponent uvedených standardů.
Microsoft zajišťuje implementaci své komponentové technologie do 32bitových
verzí operačních systémů Windows (95, 98, NT, 2000, Millennium Edition) a s
jistými omezeními i do počítačů Apple Macintosh. Třetími stranami byl COM
implementován rovněž na některých unixových platformách. V dalším popisu se
zaměříme pouze na implementace do Windows, neboť jiné se v praxi takřka
nepoužívají.

Architektura
Architektura COM je, v porovnání s architekturami jiných komponentových
technologií, velmi prostá. Setkáváme se zde vlastně pouze s pěti entitami:
lKlientská aplikace: Programový kód, který využívá služeb nějaké COM
komponenty. Klientská aplikace musí znát rozhraní používané komponenty.
lKomponenta: Komponenta reprezentuje rozhraní a metody, které jsou nabízeny k
použití klientům.
lProxy-objekt: Představuje zástupný objekt. Jde o běžný objekt, který nabízí
stejné rozhraní jako komponenta, kterou zastupuje. Všechny metody ale pouze
přesměrovávají volání na skutečnou komponentu, která je v samostatném procesu
na stejném nebo jiném počítači (pro volání vzdálené metody je potřeba DCOM).
Proxy-objekt taktéž zajistí vrácení výsledku volané metody zpět klientovi.
Tento objekt je připojován přímo do procesu klienta, a jeho metody tudíž mohou
být vyvolávány jako běžné funkce, poskytované DLL knihovnou.
lStub (spojka): Představuje logický doplněk proxy-objektu na straně komponenty.
Ta přebírá volání od proxy-objektu a vyvolává metodu komponenty. Také od ní
přebírá výsledek volání metody a zasílá jej zpět proxy-objektu. Stub a
komponenta běží v jednom procesu, a proto stub může metody komponenty vyvolávat
přímo.
lCOM: Reprezentuje systémové knihovny COM, které zajišťují instancování a jiné
systémové služby.

Zajímavé je, že proxy-objekt a stub spolu komunikují přímo. U jiných
komponentových technologií do této komunikace vstupuje komponentová technologie
jako taková, která komunikaci zajišťuje sama. Zcela paralelně spolu komunikují
systémové knihovny COM na obou počítačích (v případě, že klient a server je
tentýž počítač, k žádné komunikaci logicky nedochází). Tento komunikační kanál
slouží pro předávání požadavků na instancování komponenty, informací o
uživateli a podobně.
Uvedený způsob funkce architektury odpovídá situaci, kdy je komponenta spuštěna
v jiném procesu na lokálním nebo vzdáleném počítači. Jak ale uvidíme dále,
často dochází k situaci, kdy jsou komponenty připojovány do stejného procesu,
ve kterém běží klient. To přináší efektivnější využití zdrojů a vyšší výkon.
Hodí se zejména pro malé a jednoduché komponenty.

V takovém případě tedy zcela odpadají entity proxy-objekt a stub. Jelikož jsou
komponenta i klient uvnitř jednoho procesu, může klient vyvolávat metody
komponenty přímo. Vlastnosti
Vlastnosti architektury COM lze rozdělit do několika sekcí: rozhraní, typy
serverů, vyvolávání metody komponenty apod.

Rozhraní komponent
Každá komponentová technologie pracuje nějakým způsobem s rozhraními komponent.
Komponentová technologie COM přistupuje k tomuto fenoménu velmi specificky.
Předpokládá totiž, že bude mít komponenta více rozhraní. Tento přístup sice
podporují i jiné komponentové technologie, ale COM přímo stanovuje, že
komponenta má v praxi mít vždy více rozhraní. Není ničím neobvyklým, že jich
komponenty mají třeba dvacet. Jednotlivá rozhraní mohou od sebe dědit, čehož se
velmi hojně využívá (vícenásobná dědičnost není podporována). Každá komponenta
musí mít rozhraní, které je označeno IUnknown. Každé další rozhraní, které
implementuje, musí být přímým nebo nepřímým potomkem rozhraní IUnknown. Toto
rozhraní poskytuje funkcionalitu, která je důležitá pro všechny aplikace v COM
a má tři metody. První QueryInterface je určena pro vrácení odkazu, na další
rozhraní objektu. Zbylé dvě metody umožňují systému sledovat, kolikrát je
instance komponenty v systému využita. Metoda AddRef oznamuje instanci, že je
využívána na dalším místě v kódu, a poslední metoda Release říká, že jedna
instance přestává komponentu používat. Komponenta počítá, kolikrát je
používána. Pokud zjistí, že již není používána nikde, je z paměti automaticky
uvolněna. Ukazatel na rozhraní IUnknown je také tím, co uživatel dostane, když
vytvoří novou instanci nějaké komponenty.

Standard COM definuje ještě další rozhraní a jejich metody (některé z nich
budou zmíněny dále), které jsou určeny pro různé speciální účely. Ty však již
nejsou povinné pro všechny komponenty, ale pouze pro ty, kde mají taková
rozhraní smysl.
Obecné zásady práce s komponentami říkají, že do rozhraní, která jsou
"vypuštěna do světa", se již nesmí zasahovat. Namísto toho je třeba vytvořit
nová rozhraní (která z nich mohou dědit) a v nich je možno příslušné změny
provést. Toto pravidlo zajišťuje, aby aplikace, které byly vyvíjeny pro starší
verzi komponenty, pracovaly korektně i s verzí novou. Pro jednoznačné
identifikování komponenty, jednotlivých rozhraní a ještě dalších entit se u
technologie COM používá tzv. globálně unikátních identifikátorů (Global Unique
IDentifier GUID). Jde o 16bajtové (128bitové) číslo. To je generováno mimo jiné
také z čísla síťové karty a přesného času, čímž je dosahováno celosvětové
unikátnosti. Komponenty i rozhraní mají samozřejmě také běžná "textová" (lidsky
srozumitelná) jména, která je alternativně možné rovněž používat (resp. která
mohou být na tyto identifikátory převedena). Jednotlivá rozhraní a komponenty
se pod těmito identifikátory také ukládají do registrační databáze Windows. Na
žádost klienta může být příslušná komponenta nebo příslušné rozhraní vyhledáno
a asociováno k nějakému programovému kódu. Bohužel, tato vazba na registrační
databázi je jedním z problémů při přenositelnosti uvedené komponentové
technologie na jinou platformu.
Rozhraní COM je možné popisovat pomocí jazyka IDL (Interface Definition
Language). IDL je standardizován nezávislou skupinou OMG, ale verze, kterou
používá Microsoft, je jí pouze "inspirována" mnohé vlastnosti standardizované
verze nejsou implementovány a naopak jsou lecjak rozšířeny.

Na trh jsou dodávány nástroje, které z deklarace v IDL vygenerují základní
kostry v jazyce C++ pro implementaci komponent, proxy-objekty a stuby. Tyto
nástroje se však v praxi příliš nepoužívají. Deklarace rozhraní objektu jsou ve
většině případů generovány automaticky vývojovým nástrojem, který je pro vývoj
komponenty používán.
Informace o jednotlivých komponentách a jejich rozhraní je také možné (resp.
vhodné) uložit do typové knihovny (type library). V této knihovně jsou
informace, na rozdíl od IDL deklarací, uloženy v binární podobě. Technologie
COM nabízí funkce, které umožňují v těchto informacích vyhledávat jestli objekt
používá jisté rozhraní; jaké rozhraní má určitá funkce; jaká je struktura
určitého rozhraní apod. Tyto knihovny se používají například při pozdním
vazbení (viz dále).

Typy serverů
Serverem nazýváme programový kód (ve spustitelné podobě), který implementuje
metody nějakých COM rozhraní. Technologie COM rozlišuje tři typy COM serverů
podle způsobu jejich připojování ke klientovi:
lIn-process servery: Tyto servery jsou při použití nějakou aplikací spuštěny ve
stejném procesu jako aplikace sama. Pád takové komponenty způsobí také pád
aplikace. Servery jsou implementovány jako .dll knihovny, které lze při použití
připojit do stejného procesoru. In-process servery jsou specifické pouze pro
COM. Jejich výhodou je rychlost komunikace není totiž vyžadována náročná a
pomalá komunikace mezi procesy. Při používání komponenty ze serveru tohoto typu
není zapotřebí používat proxy-objekty a stuby.
lLokální servery (out-process): Tento typ serverů je spouštěn v samostatném
procesu. Pád komponenty by neměl bezprostředně ovlivnit stabilitu aplikace
(aplikace se ale musí vyrovnat s tím, že jí proces komponenty "zmizí"). Tento
server je schopen komunikovat s jinými procesy na lokálním stroji. Lokální
server může být implementován v podobě .dll knihovny nebo jako přímo
spustitelný .exe soubor.
lVzdálené servery (remote server): Vzdálené servery umožňují komunikaci s
jinými procesy na jiných strojích. Vzdálený server i klient musejí využívat
"rozšíření" DCOM. Je logické, že i v tomto případě běží klient a komponenta v
jiných procesech. Vzdálený server může být implementován v podobě .dll knihovny
nebo přímo jako spustitelný .exe soubor.
Z pohledu vývojáře je podstatné, že kód klienta i komponenty je ve všech
případech identický. Generování různých typů serverů je záležitostí vývojového
nástroje.

Vyvolávání metody
Podívejme se nyní, jak probíhá volání metody v technologiích COM. Srovnáme zde
situaci, kdy je volána metoda nějakého in-process serveru, a případ, kdy je
volána metoda z out-process instance komponenty na lokálním nebo na vzdáleném
počítači.
Díky existenci proxy-objektů je vždy do procesu klienta připojena komponenta,
která má stejné rozhraní jako komponenta, kterou chceme používat. V případě
in-process serverů se do procesu klienta připojuje přímo instance komponenty v
opačném případě je to proxy-objekt. Klient s objektem nebo instancí komponenty
může každopádně komunikovat přímo. V případě in-process serveru dochází přímo k
vyvolání metody komponenty, ale v ostatních případech dojde pouze k vyvolání
metody proxy-objektu, která se ale klientovi jeví stejně.
Úkolem metody v proxy-objektu je zajistit vyvolání metody na lokálním počítači
nebo dokonce na počítači vzdáleném. Před vyvoláním metody je ale potřeba
provést tzv. marshaling. To je proces, při kterém jsou parametry volané metody
převedeny do nějaké standardní podoby. Standardizované je kódování datových
typů, pořadí parametrů apod. Následně provede proxy--objekt vlastní vyvolání
objektu stub. V případě, že voláme komponentu na stejném počítači, jsou pro
komunikaci se stubem použity mechanismy meziprocesové komunikace. V případě, že
je volána komponenta na vzdáleném počítači, je použit mechanismus RPC (Remote
Procedure Call).
Objekt stub přijme volání proxy-objektu a provede tzv. unmarshaling parametrů
tedy je převede do podoby, která je vhodná pro vyvolání metody. Jelikož je Stub
již součástí procesu instance komponenty, nic nebrání přímému vyvolání. S
výsledkem je zacházeno obdobně stub provede jeho marshaling, proxy-objekt jeho
unmarshaling a výsledek je vrácen na místo vyvolání metody.
Klient má ale dvě možnosti, jak vyvolávat metody. Tento způsob, který byl
doposud popisován (a který je nejčastější), je nazýván časné vazbení (early
binding). V tomto případě překladač doplní do kódu klienta přímo volání
požadované metody příslušného rozhraní. Druhým (a obtížnějším) případem je
pozdní vazbení (late binding), kdy klient nezná v okamžiku překladu rozhraní
komponenty. V takovém případě není možné vygenerovat proxy-objekt, který
provádí marshaling a unmarshaling. V případě pozdního vazbení tedy nezbývá
aplikaci, než provádět marshaling a unmarshaling vlastními prostředky (knihovny
COM nabízejí pro zjednodušení řadu funkcí).

Automation
Technologie Automation trochu kazí systém COM. Je to ale proto, že její základy
(v podobně OLE Automation) sahají do dob, kdy COM ještě neexistoval. Tehdy byla
tato technologie šita na míru Visual Basicu a jemu podobným nástrojům.
V dřívějších dobách totiž vyšší vývojové nástroje neuměly pracovat s takovými
rozhraními, jaké dnes používá COM. A ještě hůře se těmto vývojovým nástrojům
takové komponenty vytvářely. Proto jim byla vymyšlena berlička v podobě
dnešního rozhraní IDispatch a jeho metody Invoke. Tato jedna metoda slouží pro
vyvolání veškeré funkcionality, které komponenty nabízejí. Metoda, která má být
vyvolána, je specifikována pomocí speciálního číselného identifikátoru.
Parametry pro vyvolání metody jsou všechny uloženy v jednom poli a metodě
Invoke je předán odkaz na toto pole. Výsledek je vrácen také nestandardně na
místo specifikované pomocí ukazatele při vyvolávání metody Invoke.
Problém tohoto řešení je očividný. Tento způsob vyvolávání metod možná vyhovuje
Visual Basicu (a jemu podobným nástrojům), ale je velmi obtížně použitelný pro
vyvolávání metod z jiných nižších nástrojů (jako například C++). Obdobně
obtížné je v nižších nástrojích i vytváření takových komponent.
Obvyklým řešením naznačeného rozporu je, že komponenta poskytuje dvojí rozhraní
(někdy se též říká duální rozhraní). Funkcionalita komponenty je tedy jednak
nabízena pomocí běžných metod v běžných rozhraních (které dědí od IDispatch), a
jednak také prostřednictvím metody Invoke. Ta poté zajišťuje vyvolání správné
metody přes klasická rozhraní. Rozhraní, které je "virtuálně" tvořeno metodou
Invoke, je označováno jako dispatch interface. Toto virtuální rozhraní se také
zapisuje do IDL deklarace komponenty (a jazykem IDL se popisuje).
Umožňuje rovněž manipulaci s atributy (vlastnostmi), které jsou popsány dále u
prvků ActiveX.
Automation může být také směrována na vzdálený počítač. V takovém případě se
hovoří o Remote Automation. Remote Automation je dalším pokračováním
nesystémového řešení toto řešení totiž není založeno na technologii DCOM. Do
celé záležitosti pak vstupuje ještě tzv. Automation Manager, což je samostatný
proces, který běží na vzdáleném počítači. Vyvolávání metod z klienta je opět
zachytáváno speciálním proxy--objektem a je zasíláno na vzdálený počítač jako
volání RPC. Structured Storage a perzistentní objekty
Zajímavou službou, kterou přináší komponentová technologie COM, je služba
Structured Storage. Umožňuje vytváření složených dokumentů tedy dokumentů,
které v sobě mohou obsahovat dokumenty další. Nebo z opačného pohledu více
aplikací může ukládat své perzistentní informace do jednoho společného souboru
v souborovém systému.
Struktura těchto sdílených dokumentů je značně propracovaná. Z pohledu objektů
je do souboru možné ukládat dva typy objektů objekty storage a objekty stream.
Objekty typu storage jsou objekty, které mohou obsahovat další objekty typu
storage nebo stream. Objekt stream reprezentuje sekvenci bajtů tedy obecně
data. Tyto objekty tvoří uvnitř jednoho souboru zjednodušený souborový systém
objekty storage v tomto pojetí reprezentují adresáře a objekty stream
reprezentují soubory. Jednotlivé objekty takovéhoto úložiště jsou také
reprezentovány instancemi komponenty.
Takové dokumenty mohou být aplikací otevřeny ve dvojím režimu v režimu "přímém"
a v režimu transakčním. V přímém režimu jsou veškeré změny ihned promítány do
fyzického souboru. V transakčním režimu všechny změny nejsou provedeny, dokud
nedojde k potvrzení transakce (COMMIT). Problém ale je, že tento režim práce
není v některých implementacích standardu COM dostupný.

Technologie Structured Storage úzce souvisí s perzistentními objekty.
Perzistentní objekty jsou takové, které jsou schopny svůj obsah uložit do
nějakého perzistentního úložiště nejčastěji do souboru nebo do databáze.
Perzistentní objekty nabízejí rozhraní z rodiny IPersist, které obsahují metody
pro ukládání a načítání objektů do různých typů úložišť. Tyto metody jsou
vyvolávány klientem a jako jejich parametr může být použit odkaz na instanci
komponenty s rozhraním IStream nebo IStorage, případně běžný název souboru.
Ukládání všech potřebných informací o objektu do úložiště příslušného typu si
zajišťuje komponenta sama (načítání informací je řešeno ekvivalentně).
Prvky ActiveX ActiveX je standard pro tvorbu vizuálních prvků, které je možné
používat v oknech Windows a v HTML stránkách (nemusí jít nutně o stránky
stahované z Webu). Tento standard vznikl vylepšením (a zjednodušením) staršího
standardu OLE Controls (který byl ještě založen na technologii OLE). Ačkoliv
ActiveX prvky jsou téměř vždy vizuální, není to přímou podmínkou. Nevizuální
ActiveX prvky, jako například databázová knihovna ActiveX Data Objects,
využívají z technologie ActiveX pouze vlastnosti a události. Standard ActiveX,
který úzce navazuje na standardy COM, definuje požadavky na rozhraní takového
prvku (a potažmo na povinnou funkcionalitu). ActiveX také používá výše popsanou
technologii Automation. Počet rozhraní, která musí ActiveX prvek implementovat,
je asi 15 a nemá smysl se zde jimi podrobněji zabývat. Vývojář s nimi přichází
do styku jen zřídka, neboť je jich většina generována zcela automaticky
vývojovými nástroji.
Standard ActiveX také využívá podporu pro atributy neboli vlastnosti
(property), kterou přináší výše popsaná technologie Automation. Ty se uživateli
navenek jeví jako atributy, které může klient (při použití vyšších
programovacích jazyků) přímo načítat a modifikovat. Ve skutečnosti jsou tyto
atributy pouze simulovány pomocí dvou metod "Set" a "Get", které jsou
vyvolávány při získávání, resp. modifikaci hodnoty. Tam může být (dle
objektových zásad) zachován princip zapouzdření, ačkoliv uživatel komponenty
může s jednoduchými atributy manipulovat přímo. Typickým příkladem atributu
může být titulek, který je na prvku někde zobrazen, barva prvku a podobně.

Prvky ActiveX také pracují s událostmi. A to nejen uvnitř, ale i navenek. Pokud
nastane nějaká událost, která není ošetřena uvnitř prvku, je předána výše do
tzv. Containeru, který ActiveX prvek hostuje. Tyto události mohou být ostatně
zasílány samotným ActiveX prvkem. Příkladem události může být kliknutí na prvek
nebo změna hodnoty, kterou prvek uživateli nabízí k editaci.
Služby COM Poslední verze COM, tedy COM+, přinesla řadu rozšíření v oblasti
služeb. Některé z nich byly dostupné již dříve (jako doplňky COMu), ale většina
z nich je zcela nová. Díky tomu, že tyto doplňkové služby jsou v současné době
novinkou, nejsou ještě vesměs tak propracované, jako obdobné služby u jiných
komponentových technologií. Důležité jsou především transakční služby. Ty
umožňují provádět s instancemi komponent transakce v obdobném duchu, jako to
umožňují transakční monitory. Transakční služba řídí přístup k jednotlivým
instancím, které jsou do transakcí zařazeny, a umožňuje od sebe jednotlivé
transakce izolovat. Klasickou službou je také Object pooling, který umožňuje
lepší využití systémových zdrojů. Instance, která není používána, je přiřazena
do zásobníků nevyužitých instancí. Následně může být znovu přiřazena dalšímu
klientovi, když o ní požádá. Tím se ušetří mnoho času s inicializací instancí
komponent. Komponenty však musejí pro pooling splňovat určité předpoklady.

Důležité jsou rovněž bezpečnostní služby. COM podporuje bezpečnostní model
založený na "rolích". Vývojář potom může v programovém kódu snadno otestovat,
jestli uživatel komponenty disponuje příslušnou rolí. Autentizace uživatelů je
přebírána z prostředí Windows. COM v nové verzi přináší také lépe fungující
práci s událostmi. Architektura událostí počítá s tím, že se některé komponenty
zaregistrují jako producenti událostí a jiné jako příjemci událostí. Komponenta
Systém událostí potom bude doručovat události od vydavatelů k příjemcům (s
možnostmi filtrování apod.).

Dostupnost
Ačkoliv jsou implementace COM součástí všech verzí Windows, není příprava
prostředí pro provoz aplikací nijak jednoduchá. Na různých verzích Windows
(verze 95 i 98 měly každá několik revizí) existují různé verze standardů COM.
Verze 95 obsahovala dokonce pouze COM (bez distribuovaných služeb).
Je také potřeba počítat s tím, že poslední verze tedy COM+ je (a bude) k
dispozici pouze pro Windows 2000 (není ani ve Windows Millennium Edition). Na
starší verze Windows bude možné instalovat pouze nejnovější verze DCOM. Z
tohoto důvodu je vhodné rozšíření, specifická pro COM+, používat velmi uváženě.
Pro verze Windows 95 a 98 je poslední verze DCOM k dispozici ve formě
instalačního balíčku, který lze nalézt na internetových stránkách Microsoftu
(http://www.microsoft.com ), v předplacené službě MSDN a s některými
vývojovými nástroji. Tento balíček je vhodné instalovat ve stejné jazykové
verzi, v jaké je provedena instalace systému Windows.
Pro Windows NT 4.0 je aktualizace DCOM k dispozici ve formě service packů.
Obdobným způsobem budou v budoucnu také šířeny aktualizace COM+ pro Windows
2000. Service packy jsou k dispozici ze stejných zdrojů jako balíčky DCOM
(Internet, MSDN a některé produkty). Tyto balíčky je nutné instalovat ve stejné
jazykové verzi, v jaké je provedena instalace systému Windows NT.
0 3173 / pen









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.