Václav Kadlec 12.10.2005
V dnešním článku budeme pokračovat na naše tradiční téma – komponentový vývoj softwaru. Nejprve si řekneme několik málo zbývajících obecných věcí o komponentách, jejich rozhraních a o komponentovém vývoji, a následně si začneme povídat o komponentové technologii Microsoft COM.
Vítejte u dalšího pokračování našeho seriálu o programování v Delphi. Znovu se potkáváme u článku na téma Komponentní technologie. Na úvod si provedeme tradiční stručné shrnutí toho, co o komponentách zaznělo dosud.
Takže, pověděli jsme si, co jsou to komponentové technologie a proč se o nich vlastně bavíme. Víme už tedy, že rozhodneme-li se zvolit pro vývoj své aplikace komponentní technologii, velmi zjednodušeně řečeno vlastně „vyskládáme“ svou aplikaci ze vzájemně nezávislých komponent. Co to ony komponenty jsou? Softwarová komponenta je definována jako softwarový element, který odpovídá komponentovému modelu, může být nezávisle šířen a může se skládat s ostatními komponentami podle definovaného kompozičního standardu bez jakýchkoliv změn.
Komponentový model pak definuje specifické interakce mezi komponentami a kompoziční standardy. Implementace komponentového modelu je specializovaná množina spustitelných softwarových elementů vyžadovaná k podpoře spouštění komponent odpovídajících tomuto modelu.
V následujícím jsme se zabývali výhodami komponentních technologií. Pověděli jsme si o pěti bodech, jež bývají uváděny jako největší bonusy, které může práce s komponentními technologiemi nabídnout:
1.vývoj aplikace nekončí jejím přeložením,
2.aplikace jsou
přizpůsobitelnější,
3.existence knihoven komponent,
4.distribuované
komponenty,
5.jazyková nezávislost komponent.
Před týdnem jsme pak zmínili požadavky na komponenty. Požadavků existuje celá řada, v obecnosti můžeme mluvit třeba o následujících:
Tolik k dosavadní náplni „komponentových“ dílů našeho seriálu. A co si povíme dnes? Budeme už podstatně konkrétnější a začneme se učit o komponentovém modelu dodávaném firmou Microsoft – o modelu COM. Předtím jen krátce zmíníme dvě důležité věci: nejdříve se podíváme na to, jaké komponentové modely existují kromě modelu COM, a potom si vysvětlíme trochu více o rozhraních komponent.
Obecná definice komponentového modelu byla uvedena v předchozích dílech tohoto seriálu. Dodejme proto jen, že komponentový model definuje množinu standardů pro implementaci, pojmenování, schopnost komponent používat jiné komponenty, přizpůsobitelnost, kompozici, rozvoj a šíření (nasazení) komponent.
V současnosti existuje několik nejpoužívanějších komponentových modelů, které
definují své
vlastní standardy a které vyjadřují svou vlastní představu o
komponentovém vývoji. Jedná se
zejména o následující modely:
Elementy každého komponentového modelu odpovídají kategoriím uvedeným výše (implementace, pojmenování apod.): každý komponentový model tedy popisuje všechny tyto aspekty komponentového vývoje.
Před časem jsme si vysvětlovali mechanismus tzv. rozhraní. Řekli jsme si, o co se jedná: pokud kdokoliv (klient, jiná komponenta, prostě kdokoliv) usoudí, že by mohl využívat služeb komponenty A, nikdy nevolá metody a služby poskytované komponentou A přímo. V každém případě komunikuje pouze a výhradně s tzv. rozhraními komponenty A. Jinak řečeno, pokud komponenta A obsahuje například metodu „spočti_úroky“, nebude klient při potřebě spočítat úroky volat přímo metodu „spočti_úroky“, ale zavolá nějaké z rozhraní, které komponenta A poskytuje, například „I_spočti_úroky“. Rozhraní bude zodpovědné za to, že tento požadavek „přepošle“ přímo metodě spočti_úroky a následně vrátí klientovi výsledek, který tato metoda vyrobila.
Tohle jsme si o rozhraních už v podstatě řekli. Nyní pojďme trochu dál.
Jedním z hlavních účelů komponent je jejich znovupoužitelnost. Ta může být
obecně jednoho
ze dvou typů:
Především v případě black-box znovupoužitelnosti je nutné, aby klient byl odstíněn od implementace komponenty, ideálně aby komponenta mohla být nahrazena jinou, aniž by to klient vůbec zaregistroval.
Rozhraní tedy není základní součástí komponenty, ale slouží spíše jako kontrakt mezi komponentou a jejími klienty. Rozhraní specifikuje služby, které je komponenta připravena poskytovat klientům.
Specifikace rozhraní jsou tedy centrálním, nejdůležitějším elementem
komponentového modelu. Tyto specifikace jsou totiž klíčové jak pro výrobce
komponent, tak i pro klienty, kteří se na jejich
základě budou ke komponentám
připojovat. Komponentový model definuje elementy tvořící
rozhraní, stejně
jako sémantiku (význam) těchto elementů.
Obvyklé elementy rozhraní jsou:
Rozhraní kromě toho mohou zahrnovat výjimky (které vznikají v případě chyb),
podmínky
používání jednotlivých operací apod. Mnohé komponentové modely
definují i jazyk pro popis
rozhraní a jejich elementů (Interface Description
Language, IDL).
Zkratka COM je zažitým označením komponentní technologie vyvinuté firmou Microsoft: Component Object Model. Zkratka označuje komponentový model, který je v současnosti jedním ze tří hlavních přístupů ke komponentnímu vývoji softwaru.
COM je metoda vývoje softwarových komponent – „malých“ spustitelných fragmentů zdrojového kódu, které poskytují své služby ostatním aplikacím, operačnímu systému a dalším komponentám – svým klientům.
Na COM jsou v současnosti postaveny další technologie společnosti Microsoft, např. ActiveX, DirectX, OLE a další.
Společnost Microsoft si zakládá na tom, aby COM nebyl chápán pouze jako technologický rámec pro vývoj komponentního softwaru, ale jako způsob psaní programů (the way of writing programs). Microsoft tím chce ve vývojářích posilovat přesvědčení, že komponentám patří budoucnost a že se k tomuto způsobu vývoje bude postupně přesouvat více a více aplikací.
Technologie COM má za sebou dlouhou cestu vývoje. Vznikala postupně, jak se předchozí technologie vyvíjely a přizpůsobovaly rostoucím požadavkům.
Na počátku byly první verze Windows, které umožňovaly spuštění více aplikací zároveň. Ruku v ruce s tímto požadavkem šla potřeba komunikace mezi těmito spuštěnými aplikacemi. Ta byla na počátku realizována velmi jednoduchým způsobem, který však přetrval až do dneška: schránkou systému Windows (clipboard).
Další technologie, která umožňovala výměnu informací mezi běžícími aplikacemi, se nazývala Dynamic Data Exchange (DDE): ta byla interně využívána výše zmíněnou schránkou. Principem DDE bylo zasílání zpráv mezi DDE klientem (jednou spuštěnou aplikací) a DDE serverem (druhou spuštěnou aplikací). DDE komunikace se členila do témat (topics) a položek (items); celý mechanismus je založen na zasílání zpráv systému Windows. Mechanismus DDE již není v moderních aplikacích využíván.
V roce 1992 přišla společnost Microsoft s technologií Object Linking and Embedding (OLE), která znamenala další průlom v komunikaci mezi aplikacemi. První verze OLE byla založena na DDE, což se ukázalo jako těžkopádné a nevyhovující, v roce 1993 tedy spatřila světlo světa druhá verze – OLE2 založená na myšlence komponentní technologie. OLE je obecně založeno na propojování a vkládání dokumentů a ve výsledku umožňovala pracovat s dokumenty jedné aplikace v jiných aplikacích, které o těchto dokumentech typicky nemusely nic vědět. Uvnitř jedné aplikace (OLE klienta) se otevřelo okno druhé aplikace (OLE serveru) – tzv. OLE kontejner, který tak poskytoval funkčnost OLE serveru uvnitř OLE klienta. Důležitou vlastností bylo propojení dokumentů – kromě dokumentu si klient uchovával i informace o jeho uložení, takže mohlo více aplikací pracovat s jednou fyzickou verzí dokumentu.
OLE2 byla sice postaveno na komponentní technologii, avšak sloužilo pro jeden konkrétní účel a technologii nebylo možné použít pro stavbu obecných aplikací. Až v roce 1995 se objevila zcela obecná technologie, která navazovala na OLE, avšak byla určena pro vývoj obecných aplikací na komponentním základě. Technologie se nazývá Component Object Model (COM).
Ani poté však vývoj neustal. Brzy se objevila potřeba komunikovat mezi komponentami uloženými na rozdílných strojích. Microsoft se rozhodl implementovat tento požadavek za použití existující technologie Remote Procedure Calling (RPC). (RPC je jen jednou z mnoha konkrétních technologií, které definuje specifikace Distributed Computing Environment – DCE - vytvořená konsorciem Open Software Foundation - OSF). Výsledkem byla v roce 1996 distribuovaná verze technologie COM: Distributed COM (DCOM).
V současnosti vývoj pokračuje snad stále rychleji: Microsoft přináší stále nové služby, které jeho komponentové technologie poskytují (podpora bezpečnosti, škálovatelnosti, distribuovaných transakcí, vysoce bezpečných síťových aplikací apod.). Vzniká tak nová specifikace COM+ umožňující využívat všech nových služeb. Lze říci, že technologie COM+ je integrací dalších služeb:
Závěrem zmiňme strategickou architekturu Microsoftu, která má sloužit pro vývoj internetových aplikací na platformě Microsoft Windows. Jedná se o Windows Distributed Internet Application Architecture (DNA). Architektura obsahuje tři základní vrstvy:
Dnes jsme si pověděli některé obecné zbývající věci o komponentách a začali jsme povídat o technologii COM. Příště navážeme tam, kde jsme dnes skončili – u podrobností o komponentovém modelu COM.
