Umíme to s Delphi: 166. díl – Komponentový model Microsoft COM

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:

  • dynamické připojování,
  • skrývání detailů o implementaci,
  • možnost vícenásobného použití,
  • jednoznačná identifikace komponenty,
  • existence mechanismu rozhraní,
  • anonymita klienta,
  • rekurzivní skládání komponent

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 č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.

Dostupné komponentové modely

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:

  • COM/DCOM/COM+ společnosti Microsoft,
  • CORBA Component Model společnosti OMG,
  • JavaBeans a Enterprise JavaBeans společnosti Sun.

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.

Rozhraní komponent

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ů:

  • black-box (komponentu považujeme za černou skříňku, o níž nic nevíme, avšak využíváme její funkčnosti),
  • white-box (zdrojový kód komponenty je k dispozici a může být studován, modifikován a znovupoužit)

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:

  • jména metod,
  • jejich parametry,
  • platné typy parametrů.

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).

Model COM – úplné základy

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í.

Historie COM

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:

  • Microsoft Transaction Server (MTS): server pro správu komponent a transakcí, často se využívá ve spolupráci se SQL serverem Oracle nebo MS SQL a ve spolupráci s webovým serverem Microsoft Internet Information Server (IIS)
  • Microsoft Message Queue Server (MSMQ): server pro práci offline a synchronizaci

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:

  • Vrstva prezentační: zprostředkovává klientský styk s aplikací, obsahuje však jen uživatelské rozhraní, nikoliv aplikační logiku. Je obvykle realizována tlustými nebo tenkými klienty. Využívá technologií HTML, DHTML, skriptování, Win32 API apod.
  • Vrstva aplikační logiky: implementuje funkčnost aplikace a aplikačně specifické algoritmy. Tato vrstva je nejčastěji implementována komponentními technologiemi a využívá komponent. Používají se technologie COM, COM+, MTS, MSMQ apod.
  • Vrstva datová: zajišťuje uložení dat, přístup k datům, bezpečnost, transakce apod. Využívají se technologie ODBC, OLE DB, SQL Server (nebo jiný SQL server připojitelný přes ODBC či OLE DB, např. Sybase, Oracle, DB2), ADO apod.

Závěrem

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.

Témata článku: Software, Microsoft, Programování, .com, Apod

7 komentářů

Nejnovější komentáře

  • Veolw 22. 7. 2006 17:05:13
    Taky souhlasim. V Delphi neprogramuji vubec ale chtel jsem se dozvedet...
  • gully, gully 18. 10. 2005 9:35:38
    Ano, presne tak. Serial ma vysokou kvalitu take diky tomu, ze dana...
  • Vaclav Kadlec 17. 10. 2005 22:06:05
    Priklad prijde, ale chvilku to bude trvat; komponentni technologie nejsou...
Určitě si přečtěte

Sbíječky vyměnili za klávesnice. Nový projekt má za cíl přeučit horníky na programátory

Sbíječky vyměnili za klávesnice. Nový projekt má za cíl přeučit horníky na programátory

** Programátorů je málo a horníků bez práce po uzavření dolu Paskov bude moc ** Problém řeší unikátní projekt ** Pilotní kurz dává naději, že by z horníků mohli být použitelní kodéři

28.  11.  2016 | David Polesný | 78

ASUS ZenBook 3 se začal prodávat v Česku. Je ve všem lepší než MacBook, ale bude to stačit?

ASUS ZenBook 3 se začal prodávat v Česku. Je ve všem lepší než MacBook, ale bude to stačit?

** Novinka od Asusu míří přímo proti MacBooku od Applu ** Nabídne daleko více výkonu za stejné peníze

2.  12.  2016 | David Polesný | 123