Technologie COM ve vývojovém nástroji Microsoft Visual Studio

Transkript

1 Masarykova univerzita Fakulta informatiky BAKALÁŘSKÁ PRÁCE Technologie COM ve vývojovém nástroji Microsoft Visual Studio Ondřej Bystrý 2006

2

3 Prohlášení Prohlašuji, že jsem bakalářskou práci zpracoval samostatně a že jsem uvedl všechny prameny, ze kterých jsem čerpal. V Brně podpis

4 Poděkování Děkuji vedoucí bakalářské práce paní Mgr. Barboře Zimmerové za odborné vedení a panu Ing.Václavu Kadlecovi za ochotu a vstřícnost a za cenné rady, které mi poskytl.

5 Shrnutí: Práce popisuje obecné principy komponentních technologií a detailněji pak principy, na nichž je založena komponentní technologie COM. Jejím konkrétním zaměřením je tvorba komponent COM ve vývojovém nástroji Microsoft Visual Studio, s využitím programovacího jazyka Visual Basic. Případová studie, jejíž tvorba je v textu podrobně zdokumentována, názorně ilustruje specifika komponentní technologie COM v praxi. Summary: This thesis describes general principles of component technologies and focuses on principles, that component technology COM is based on. Thesis accords priority treatment to development of component COM using the Microsoft Visual Studio environment, specifically taking advantage of programming language Visual Basic. Thesis contains the description of the sample project implementation, which practically shows the unique aspects of component technology COM. Klíčová slova: Software, komponentní technologie, technologie COM, Microsoft Visual Studio, Microsoft Visual Basic, tvorba aplikace.

6 Obsah 1. Úvod Popis použité technologie Vývoj softwarových technologií Obecné principy komponentní technologie Charakteristika technologie COM Implementace technologie COM v Microsoft Visual Studio Tvorba aplikace Návrh komponent Tvorba komponent ActiveX Control Tvorba komponenty ActiveX DLL Tvorba komponenty ActiveX EXE Tvorba klienta Ukázka spolupráce komponent s klientem Závěr Literatura Přílohy Přehled komponent... i 6.2 Uživatelská dokumentace... v

7 1. Úvod Cílem mé bakalářské práce bylo seznámit se s vývojovým prostředím Microsoft Visual Studio a s implementací komponentní technologie COM v tomto prostředí a použít uvedený nástroj pro vytvoření vlastní aplikace. Jádro teoretické části práce je tvořeno kapitolami 2 a 3. V kapitole 2 uvádím základní informace o použité technologii. Jsou popsány výchozí principy objektově orientovaného programování, komponentní technologie obecně a speciálně pak komponentní technologie COM. V kapitole 3 popisuji postup tvorby aplikace v uvedené technologii. Uvádím, jaká základní rozhodnutí je nutno při vývoji aplikace učinit, jak jsem se v případě konkrétní vytvářené aplikace rozhodl a z jakých důvodů. Popisuji, na jaké problémy jsem při vývoji narazil a jak jsem je řešil. Přílohy obsahují seznam komponent s popisem jejich rozhraní a uživatelskou dokumentaci k vytvořené aplikaci. Praktickou část mé bakalářské práce představuje aplikace vytvořená ve vývojovém prostředí Microsoft Visual Studio v jazyce Microsoft Visual Basic. Aplikace demonstruje obecné principy používání komponentních technologií a většinu základních a nejčastějších činností, jako například tvorbu komponent, spolupráci mezi komponentami a využití komponent klientem

8 2. Popis použité technologie 2.1 Vývoj softwarových technologií Přestože software má v porovnání s jinými produkty lidské činnosti docela krátkou historii, prošla tvorba softwaru vývojem, na kterém je možno vysledovat několik odlišných fází. V první etapě softwarové tvorby byly aplikace vytvářeny ve formě jednoho programového celku, a to jak na úrovni zdrojového textu, tak na úrovni cílového strojového kódu. Zdrojový text nebyl nijak strukturován, větvení a cykly byly vytvářeny pomocí odskoků na návěští. Kompilací jednoho celku zdrojového textu vznikl jeden spustitelný celek ve strojovém kódu. Je zřejmé, že tvorba složitějších aplikací tímto způsobem byla nesmírně náročná. Čitelnost zdrojového kódu (zejména cizího, ale i vlastního s delším časovým odstupem) byla nízká, z čehož plyne, že modifikovatelnost aplikace byla obtížná a nesla vysoké riziko chyby. Důsledkem byla skutečnost, že při vývoji další aplikace, byť podobné, bylo zpravidla jednodušší naprogramovat vše znovu, než se pokoušet použít něco z dosud vytvořených programů. Metodika strukturovaného programování vycházela z analýzy vytvářeného systému a rozkladu složitého algoritmu do jednoduchých typizovaných struktur. To umožnilo vytváření knihoven funkcí a přineslo možnost opakovaného použití vytvořených softwarových elementů, zatím však pouze na úrovni zdrojového textu, tj. před kompilací. Další důležitou charakteristikou uvedené metodiky je přetrvávající oddělení datových struktur od funkcionality. Knihovny evidovaly funkce, ale nespojovaly je nijak s konkrétními datovými strukturami. 2.2 Obecné principy komponentní technologie Se snižováním ceny hardwaru došlo k výraznému rozšíření sfér použití výpočetní techniky z původní domény vědecko-technických výpočtů do mnoha dalších oblastí: obchodu, služeb, vzdělávání Při modelování reálných činností, které měly být automatizovány, se ukázalo, že návrh jednotlivých datových struktur společně s požadovanou funkcionalitou prováděnou nad každou strukturou daleko lépe odráží skutečnost než dosud používaný přístup relativně nezávislého návrhu datových struktur a návrhu funkcí

9 Odpovědí na tuto potřebu byl vznik metodiky objektově orientovaného programování. Byl definován pojem objekt jako uzavřená struktura programu splňující podmínky. 1. Obsahuje vnitřní paměť (atributy). 2. Obsahuje programový kód pro zajištění funkcionality nad vnitřní pamětí (metody). Důležitá je skutečnost, že metody pracují pouze nad vnitřní pamětí objektu. 3. Objekt je schopen přijmout zprávu zvnějšku a na základě toho spustit určitou metodu ( dle tzv. protokolu zpráv přiřazujícího každé přípustné zprávě určitou metodu objektu). 4. Objekt může obsahovat jiné objekty, kterým je schopen poslat zprávu ( a tímto způsobem může řídit jejich činnost). V praxi se pak jeví jako velmi významné některé další vlastnosti objektů, přestože z pohledu teorie stojí v pozici nikoliv základních, nýbrž pouze odvozených charakteristik. Jsou to především mechanismus tvorby objektů pomocí tříd, možnost dědění a polymorfismus. Objektový přístup představoval ve vývoji softwarových technologií velmi důležitý krok směrem ke standardizaci a opakovanému použití ucelených relativně nezávislých softwarových elementů. Uvedený proces však mohl být uplatňován pouze na úrovni zdrojového kódu, to znamená, že spolu mohly být spojovány pouze celky vytvořené v tomtéž, resp. v blízkém programovacím jazyce, a následně bylo nutno provést kompilaci. Uvedený nedostatek odstraňuje komponentní technologie. Pojem komponenta obecně označuje softwarový element, který může být spojován s dalšími elementy do funkčního celku a umožňuje opakované hierarchické skládání, a to vše na binární úrovni, to znamená na úrovni zkompilovaných prvků systému. Komponentní technologie vychází z objektového přístupu, instanci komponenty je možno považovat za speciální případ objektu. Komponentní technologie umožňuje tvorbu jednotlivých složek systému v různých vývojových prostředích i v odlišném programovacím jazyce, a tím maximální opakované využití prvků dříve vytvořeného softwaru. Dalším důležitým kladem komponentní technologie je snazší modifikovatelnost aplikací. Technologií rozumíme soubor pravidel a dohod, které musí programátor dodržet, aby jeho aplikace dokázala s ostatními komunikovat, jinými slovy, aby opravdu vytvořil použitelnou komponentu. Konkrétních technologií, které tyto standardy nějakým způsobem zavádějí, je několik

10 Třemi nejrozšířenějšími jsou komponentní technologie CCM (CORBA Component Model), založená na technologii CORBA (Common Object Request Broken Architecture), dále potom EJB (Enterprise JavaBeans) a COM (Component Object Model). COM má oproti EJB výhodu větší konzistence, v důsledku toho, že je vytvořen a poskytován jediným výrobcem společností Microsoft. Obrácenou stranou této mince je, že efektivní fungování technologie je omezeno na jedinou platformu, tj. Microsoft Windows. Technologie EJB může být realizována na různých platformách, nicméně přenosy z jedné platformy na jinou mohou být problematické. CCM je z uvedených technologií nejmladší a ve své specifikaci se snaží využít řadu prvků, které se osvědčily v ostatních technologiích. Všechny tři technologie mají mnoho společných vlastností a sílí snaha o jejich propojení. Například už existuje software, umožňující propojit komponenty technologií COM a CORBA navzájem

11 2.3 Charakteristika technologie COM Rozhraní objektu Jedním z postulátů objektově orientovaného programování je požadavek, aby každý objekt měl tzv. protokol zpráv. Protokol zpráv je v jednotlivých technologiích implementován různě, ale obecně platí, že jde o tabulku obsahující seznam zpráv, na které umí objekt reagovat, a přiřazující každé přípustné zprávě právě jednu metodu, která se při zavolání zprávy spustí. Vzhledem k zapouzdření, které uživateli objektu nedovoluje nahlížet či dokonce zasahovat do vnitřní struktury objektu, je zasílání zpráv jedinou možností, jak s objektem komunikovat. Seznam zpráv, kterým objekt rozumí, je tedy pro uživatele klíčovou informací o tom, jak je možno objekt použít. Seznam zpráv sám o sobě samozřejmě neposkytuje informaci o tom, jak se bude objekt chovat. Reakce objektu na zprávu závisí na tom, jaká metoda je k dané zprávě přiřazena. To znamená, že může nastat situace, kdy se dva objekty se stejnou množinou zpráv chovají zcela odlišně (tzv. polymorfismus). Seznam zpráv, které je možné objektu zaslat, označujeme termínem rozhraní, neboli interface. Pomocí rozhraní je objekt schopen komunikovat se svým okolím. Rozhraní může být chápáno jako entita nezávislá na konkrétním objektu, a následně je pak možno uvažovat situaci, kdy rozhraní vzniká nezávisle na objektu. Například je možno definovat rozhraní a teprve potom vytvářet objekt, který bude uvedené rozhraní implementovat. Přirozeným vyústěním těchto úvah je potom otázka, zda by takto vznikající objekt mohl případně implementovat i několik různých rozhraní. Z analytického hlediska se implementace několika rozhraní jeví jako výhodné řešení. Zejména když uvážíme, že v různých již existujících rozhraních se může opakovat volání stejných zpráv, je zřejmé, že tímto způsobem je možno použít jednu metodu (tzn. jednou napsaný kód) vícekrát. Praktická realizace několikanásobného rozhraní však není triviální. Řešení se v jednotlivých komponentních technologiích odlišuje, v kapitolách a bude popsáno řešení uvedeného problému v technologii COM Realizace rozhraní COM, metoda QueryInterface Realizace rozhraní je především otázkou zavedení určitých dohod a standardů, při jejichž dodržení jsou potom objekty schopné komunikovat pomocí zasílání zpráv

12 V komponentních technologiích je tento problém o to složitější, že se má jednat o komunikaci již zkompilovaných objektů, tj. na binární úrovni. Rozhraní komponent COM je řešeno jako pole adres, ve kterém jsou uloženy ukazatele na jednotlivé metody, tzn. na první příkazy těchto metod. Zprávy jsou jednoznačně identifikovány svým pořadím v poli, tedy pomocí svého indexu. Zpráva zaslaná binárnímu objektu je tímto zredukována na jediné číslo a je interpretována jako příkaz: Proveď instrukci nacházející se v paměti na adrese, kterou najdeš na x-tém místě v poli ukazatelů. Je zřejmé, že dané řešení zachovává požadované oddělení zpráv od metod a že metody nejsou spouštěny přímo, ale prostřednictvím protokolu zpráv. Výměnou obsahu tabulky ukazatelů je možno dosáhnout toho, že objekt se stejným rozhraním se bude chovat odlišně, neboť zprávám budou přiřazeny jiné metody. Několikanásobné rozhraní v binárních podmínkách je v technologii COM řešeno pomocí rozhraní IUnknown. Rozhraní IUnknown obsahuje tři zprávy: QueryInterface, AddRef a Release (jejich význam bude popsán v následujících odstavcích). Uvedené rozhraní je považováno za standardní a musí být součástí každé komponenty COM. Další standard pak nařizuje, že každé další rozhraní COM komponenty musí obsahovat mimo svých vlastních zpráv také všechny tři zprávy rozhraní IUnknown, a to povinně na začátku rozhraní, tedy na prvních třech místech v poli ukazatelů. Zprávy QueryInterface, AddRef a Release je tedy možno volat pomocí kteréhokoliv rozhraní komponenty COM. Další dohoda potom zajišťuje, že ať budeme tyto zprávy volat jakkoliv (tedy prostřednictvím kteréhokoliv rozhraní), výsledek bude vždy stejný. To znamená, že ve všech rozhraních se budou za těmito zprávami skrývat tytéž metody a jestliže vyšleme zprávu např. QueryInterface kterémukoliv rozhraní komponenty, spustí se vždy tatáž metoda. Dohoda v podstatě říká, že každá komponenta má jedinou metodu QueryInterface, jedinou metodu AddRef a jedinou metodu Release a že v každém rozhraní je k dispozici zpráva pro zavolání každé z těchto metod. Možnost používat několikanásobné rozhraní nám poskytuje konkrétně metoda QueryInterface. Jde o funkci, která na dotaz na určité rozhraní vrátí ukazatel na toto rozhraní, případně informaci o tom, že rozhraní neexistuje. Na rozhraní se dotazujeme pomocí jednoznačného identifikátoru (tzv. IID - Interface Identifier). Standardy technologie COM opět stanovují několik pravidel, podle nichž se musí metoda QueryInterface chovat:

13 1. Již zmíněné pravidlo o tom, že v komponentě existuje jen jediná implementace funkce QueryInterface. 2. Po celou dobu trvání života instance komponenty musí QueryInterface vracet na stejné dotazy stejné odpovědi, to znamená, že opakováním dotazu nemůžeme získat dva různé výsledky. 3. Nesmí dojít k chybě ani v situaci, kdy se klient zeptá na rozhraní, které právě v současné době používá. V takovém případě vrací rozhraní odkaz na sebe sama. 4. Pravidlo možné cesty zpět: Jestliže jsme dotazem zaslaným jednomu rozhraní úspěšně získali ukazatel na rozhraní další, pak od tohoto získaného rozhraní jsme schopni dotazem úspěšně získat odkaz na rozhraní původní. 5. Ať se na určité rozhraní ptáme dotazem přes kterékoliv rozhraní komponenty, výsledek dotazu musí být vždy stejný. Tedy odpověď nesmí záviset na tom, kterému rozhraní jsme dotaz zaslali. Takto metoda QueryInterface funguje jako jakýsi přepínač mezi rozhraními a dovoluje nám pracovat s několikanásobným rozhraním i na binární úrovní Reference, metody AddRef a Release Komponentní technologie musí také řešit problém, za který v případě OOP zodpovídá samotný programátor. Jde u určení doby vzniku a zániku objektu, který má být klientem používán. Pokud totiž vytváříme komponentu, která má být použitelná v různých programech, nemůžeme předem vědět, kdy ji bude který klient potřebovat. Je tedy potřeba rozhodnout, kdo má být zodpovědný za určení správné chvíle pro zrození a zničení komponenty. Tvůrce komponenty k tomu v době tvorby nemá dostatečné informace. Klient by mohl teoreticky nechat komponentu zrodit ve chvíli, kdy ji potřebuje, ale zůstává problém se zrušením, protože klient nemůže vědět, jestli je v danou chvíli jediným, kdo komponentu používá, a jestli nezničí komponentu, kterou v té době používá ještě někdo další. Svůj vznik a zánik by tedy měla řídit sama komponenta. Ale i tady narážíme na problém, protože na základě principů OOP by se komponenta neměla o své klienty nijak zajímat a měla by jen provádět příkazy, zaslané jí pomocí zpráv. Řešení spočívá ve vhodném rozdělení odpovědnosti mezi klienta a komponentu. Klient je povinen oznámit komponentě, že ji začal, resp. přestal používat, a komponenta si udržuje informaci o počtu referencí na sebe sama, tedy zná počet klientů, kteří ji používají. Svůj vznik a zánik je potom komponenta schopna ovládat sama na základě počtu referencí. Vzniká ve chvíli, kdy ji začne používat první klient (vzniku instance komponenty se

14 budeme podrobněji věnovat v následující kapitole), a zanikne, když ji přestane používat poslední klient, to znamená ve chvíli, kdy je počet referencí roven nule. Ke změně počtu referencí slouží klientům v technologii COM právě dvě zbývající metody rozhraní IUnknown, tzn. metody AddRef a Release. Klient zavolá metodu AddRef vždy v okamžiku, kdy získá odkaz na nějaké rozhraní komponenty, a následně metodu Release, když ji používat přestane, tedy když tento odkaz zruší nebo nahradí jiným. Je třeba zdůraznit, že nová reference vzniká i kopírováním odkazu do jiné proměnné, protože v té chvíli máme možnost k objektu přistupovat dvěma různými cestami. Pokud bychom při kopírování odkazu nezavolali metodu AddRef, komponenta by se po zániku odkazu v původní proměnné zničila a klientovi by v druhé proměnné zůstal odkaz na neexistující objekt. V okamžiku, kdy zkopírujeme odkaz na nějaké rozhraní komponenty do další proměnné, musíme situaci chápat jako používání komponenty dvěma klienty a v souladu s tím zavolat metodu AddRef Vznik instance komponenty, Class Factory V předcházející kapitole je několikrát použita formulace: komponenta bude sama schopna ovládat svůj vznik, v tomto obratu se ukrývá vcelku netriviální problém, a totiž, jak může nějaký objekt sám sebe vytvořit, když zatím neexistuje. V objektových programovacích jazycích je při tvorbě monolitického programu uvedený problém řešen tím, že konstruktor a destruktor jsou metodami třídy a za zrod svých instancí tak odpovídá sama třída. Toto řešení ovšem v komponentní technologii nepřipadá v úvahu, protože konstrukci, ve které považujeme třídu v podstatě za zvláštní druh objektu, můžeme použít ve vyšším programovacím jazyce, ale nikoliv na úrovni zkompilovaného kódu. Jednou z možností, jak lze problém řešit v komponentní technologii, je zavedení systémové funkce přístupné odkudkoliv. V takovém případě pak sám systém vystupuje v roli toho, koho žádáme o vznik objektu. V technologii COM se tato funkce nazývá CoCreateInstance a jejími parametry jsou kromě jiných především CLSID, což je jednoznačný identifikátor komponenty, a IID jako identifikátor rozhraní, které chceme použít jako první. Jako výsledek potom funkce CoCreateInstance vrací ukazatel na námi požadované rozhraní. Nevýhodou uvedeného řešení je ovšem jeho nedostatečná flexibilita. Protože při vytváření instance komponenty můžeme mnohdy vyžadovat, aby byl tento proces pod řízenou kontrolou (například z důvodů řešení přístupových práv ke komponentě, či optimalizace z hlediska dalších alokací paměti v případě, že žádáme víc instancí jedné komponenty)

15 Odpovědí na tyto požadavky je komponenta Class Factory. Pro každou komponentu existuje zvláštní komponenta Class Factory, která má starosti její zrod. Je vhodné zdůraznit, že Class Factory dané komponenty má na starosti pouze její zrod a nijak nesouvisí s aplikační logikou komponenty samotné, jedná se o čistě služební objekt. Postup při vzniku komponenty s použitím Class Factory vypadá takto: Nejprve je do systému nainstalována právě komponenta Class Factory, poté je možno nastavit podmínky vzniku komponenty samotné pomocí vnitřní paměti Class Factory v závislosti na konkrétních podmínkách, za nichž má být komponenta vytvořena. A teprve potom Class Factory zajistí vytvoření instance požadované komponenty. Na první pohled se může zdát, že popsaným mechanismem jsme problém nevyřešili, ale pouze ho přesunuli z jedné komponenty na jinou, protože u zrodu Class Factory vyvstává tentýž problém. Rozdíl však tkví v tom, že v případě Class Factory, vzhledem k tomu, že jde pouze o služební objekt, odpadají potíže s flexibilitou, na které jsme dříve narazili při použití systémové funkce. Vznik instance komponenty v technologii COM tedy vypadá takto: Jestliže klient požaduje vytvoření instance nějaké komponenty, nejprve je pomocí systémové funkce CoGetClassObject vytvořena Class Factory náležející k příslušné komponentě a potom se výše popsaným způsobem Class Factory postará o vznik instance komponenty, kterou chce klient používat Identifikace komponent a popis rozhraní Je zřejmé, že každá komponenta, stejně tak jako každé rozhraní, musí být jednoznačně identifikovatelné. Jako jedinečné označení se v technologii COM používá GUID (globally unique identifier). GUID je 128bitová struktura, vygenerovaná na základě času vzniku identifikátoru, relativního času od vzniku nového systému na stroji a jednoznačného identifikátoru stroje (ten vychází z identifikátoru síťové karty, nebo, v případě, že stroj síťovou kartu nemá, z kombinace identifikátorů pevného disku, CPU, příp. dalších součástí stroje) Technologie COM využívá uvedený systém identifikace jak k označování komponent (identifikátor CLSID), tak k označování jejich rozhraní (identifikátor IID). Ke generování GUID jsou využívány různé programy, např. UUIDGEN.EXE. Popsaným způsobem je možno komponentu jednoznačně identifikovat, nicméně tato informace nepostačuje uživateli k tomu, aby se dozvěděl, k čemu je komponenta určena a jak ji může využít. Aby byla komponenta využitelná jinými programátory, než je sám autor, je potřeba vhodným způsobem popsat její rozhraní, tedy jaké zprávy je

16 komponenta schopna přijímat, jejich vstupní a výstupní parametry, a především jejich význam. Přestože formát popisu není striktně předepsán, standardně se používá tzv. Interface Definition Language zkráceně IDL. Jedná se o jazyk se syntaxí podobnou C++, jehož pomocí lze vytvořit popis rozhraní obsahující především jeho jednoznačný identifikátor IID, vytvořený jako GUID, a dále jméno rozhraní, atributy, definice metod Využití tohoto prostředku výrazně zjednodušuje komunikaci mezi tvůrcem komponenty a jejími uživateli. Je vhodné upozornit na skutečnosti, že zveřejnění popisu komponenty je pro tvůrce určitým závazkem, protože v případě, že se rozhodne nějakým způsobem rozhraní změnit, nemůže ho pouze upravit (protože by pak neodpovídalo zveřejněnému popisu), ale musí zavést rozhraní nové Komponenty in-process, out-of-process V propojování komponent na binární úrovni se skrývá ještě další nebezpečí. Komponentu do systému připojujeme díky tomu, že známe ukazatel na její rozhraní. Vyvstává však otázka, zda budeme vždy schopni tento ukazatel použít, tedy zda adresa, na kterou ukazuje, bude pro náš program dostupná. Problém spočívá v izolaci procesů. Dva procesy, byť běží na jednom stroji, nesdílejí stejný paměťový prostor. Každý proces si vyhrazuje vlastní paměťový prostor, ve kterém se pohybuje, a při volání odkazů v této paměti používá logických adres. Logické adresy jsou absolutní v rámci jednoho procesu, ale relativní mezi procesy. Z toho plyne, že shodným logickým adresám ve dvou spuštěných procesech odpovídají rozdílné adresy fyzické. Je tedy zřejmé, že pokud se komponenta nachází jinde než v paměťovém prostoru klienta, nebude přímo dostupná, přestože běží na stejném stroji (v případě, že běží na jiném stroji, je tento problém ještě zjevnější). Na základě tohoto problému tedy rozdělujeme komponenty na servery in-process a out-of-process. Servery in-proces se připojují tak, že se nová instance komponenty instaluje do stejného paměťového prostoru, v němž se nachází klient. Servery out-of-process potom existují mimo paměťový prostor klienta a dělíme je ještě na tzv. lokální a vzdálené servery podle toho, zda běží na stejném nebo na jiném stroji. V případě lokálního serveru out-of-process je potřeba zajistit komunikaci mezi izolovanými procesy. To je možno provést několika způsoby, například tzv. dynamickou výměnou dat (Dynamic Data Exchange, DDE) nebo pomocí sdílené paměti. Technologie COM používá k uvedenému účelu tzv. Local Procedure Call (LPC). Aby bylo

17 zabezpečeno odizolování jak klienta, tak komponenty od přímého volání do jiného procesu, probíhá tato komunikace přes simulanty. V procesu klienta je ve tvaru in-proces DLL zaveden objekt simulující činnost komponenty (tento simulant se nazývá proxy) a naopak v procesu komponenty je stejným způsobem zaveden objekt simulující činnost klienta (nazývá se stub). Simulanti spolu potom komunikují právě pomocí LPC. V případě vzdáleného serveru je situace obdobná, ale ke komunikaci mezi proxy a stub se používají funkce Remote Procedure Call (RPC) určené ke komunikaci mezi různými stroji pomocí síťových prostředků. Tato technologie se také někdy nazývá DCOM (Distributed COM). Je vhodné podotknout, že LPC je možno považovat za zvláštní případ použití RPC, a to pro volání funkcí na jednom stroji. Současně s použitím RPC je ovšem třeba řešit celou řadu otázek spjatých se síťovou komunikací, především otázku bezpečnosti a přístupových práv. Dalšími termíny, které je vhodné zmínit v souvislosti se servery out-of-process, jsou marshalling a unmarshalling. Jsou to názvy pro činnosti nezbytné při předávání parametrů mezi izolovanými procesy tak, aby tyto byly pro obě strany srozumitelné. Převod parametrů volání do standardního formátu pro přenos mezi procesy se nazývá marshalling. Opačná operace, zpětného dekódování parametrů v procesu, který je přijal, se potom nazývá unmarshalling. Protože každé rozhraní má své vlastní metody a parametry, zavádí se standardně pro každé rozhraní jeho vlastní marshaller. Ten obsahuje specifický algoritmus pro zakódování a dekódování parametrů metod daného rozhraní COM a vlákna V souvislosti s multithreadingem, tedy při běhu několika vláken v jednom procesu, může v COM dojít hned ke dvěma problémům. Zaprvé je to situace, kdy je instance komponenty nainstalována v prostředí, kde běží několik vláken najednou. Komponenta neví samozřejmě nic o svých klientech, to znamená, že neví, kdy ji bude kdo volat, a v tomto prostředí potom může docházet ke kolizím, pokud není komponenta sama proti nim nějak zabezpečena. Druhý problém pak nastává v opačném případě: komponenta sama může být naprogramována tak, že v sobě spouští více vláken, a v tom případě může dojít ke kolizím, pokud je takováto komponenta používána klientem, který s více vlákny neumí pracovat. Komponenta totiž může zavolat klienta hned několika vlákny, a pokud tento není zabezpečený proti paralelnímu zpracování, dojde ke kolizi. I v tomto případě však je to komponenta, která jakožto služební objekt (server) nese odpovědnost za bezpečnost své činnosti pro libovolného klienta

18 Uvedené problémy jsou v technologii COM řešeny zavedením dvou základních povolených modelů a to STA (Single-Threaded Apartment Model) a MTA (Multi-Threaded Apartment Model). Rozdíl mezi modely STA a MTA tkví v tom, že v případě modelu STA je synchronizace více vláken realizována samotnou technologií COM, tedy pomocí jejích systémových funkcí, a rozhraní jsou mezi jednotlivými vlákny marshallována. V případě MTA si musí své vnitřní stavy synchronizovat komponenta sama, to znamená, že za správné fungování i v případě volání z více vláken odpovídá programátor, který musí všechny tyto případy nějakým způsobem ošetřit. Dalším rozdílem je pak to, že v MTA nedochází mezi vlákny k marshallingu rozhraní. Nespornou výhodou modelu STA je skutečnost, že se programátor komponenty nemusí zabývat problémy souvisejícími s multithreatingem. Ovšem ruku v ruce s výhodou, že při tvorbě komponenty není potřeba řešit synchronizaci, jde nevýhoda, že tím pádem programátor komponenty nemá synchronizaci nijak pod kontrolou, což také může působit problémy (viz další odstavec). Další nevýhodou je potom to, že v tomto modelu není možné zavést uvnitř komponenty paralelní zpracovávání několika vlákny. Při použití modelu STA stojí před programátorem nesnadný úkol zajistit synchronizaci vláken běhu programu v komponentě, přestože komponenta neví, kdy a kdo ji bude volat. Na druhou stranu je to v některých případech jediná možnost, jak optimalizovat rychlost komponenty, a v některých případech dokonce jediná možnost, jak zajistit její funkcionalitu Windows Registry a COM Registry je systémová databáze Windows. Kromě mnoha dalších funkcí tato databáze podporuje evidenci nezbytnou pro technologii COM. COM používá Registry k uschování důležitých informací o komponentách v systému. Primární informací o komponentě je především její jednoznačný identifikátor (viz 2.3.5) označovaný jako CLSID. K tomuto identifikátoru se pak v databázi asociují další podstatné informace týkající se dané komponenty. Registry má stromovou strukturu a k jeho prohlížení se používá Registry Editor, a to buď REGEDIT.EXE (pod Windows 95) nebo REGEDT32.EXE. Prvky používané v technologii COM, které jsou zapsané v Registry, jsou všechny v jediném kořenu s názvem HKEY_CLASSES_ROOT. Zde je možno nalézt podřízený prvek označený CLSID, v němž se nacházejí veškeré informace o všech třídách libovolné komponenty. Kromě CLSID komponenty je důležitou informací především slovní označení

19 komponenty, které je samozřejmě srozumitelnější a uživatelsky příjemnější než skupiny hexadecimálních znaků. Registrace (resp. odhlášení) serveru EXE se provádí buď přímo jeho spuštěním nebo pomocí příkazů /regserver a /unregserver. V případě serveru DLL a Control komponent se potom používá registrační program REGSVR32.EXE, který má parametr /u pro odregistrování komponenty

20 2.4 Implementace technologie COM v Microsoft Visual Studio Microsoft Visual Studio Microsoft Visual Studio je komplexní produkt určený k vývoji softwaru, který v sobě sdružuje několik různých vývojových prostředí. Každý programovací jazyk má své specifické vlastnosti, díky kterým je vhodný k řešení určitých typů problémů. A právě z toho důvodu, aby programátor měl možnost využít pro daný úkol ten nejvhodnější vývojový prostředek, nabízí je firma Microsoft společně v podobě Visual Studia. Konkrétně Visual Studio 6.0 Enterprise Version nabízí: Visual Basic, Visual C++, Visual FoxPro, Visual InterDev, Visual J++, Visual SourceSafe, MSDN Library. Co se týká konkrétně Visual Basicu, jedná se vyšší programovací jazyk, zaměřený především na tvorbu aplikací fungujících na principech OOP. Jak napovídá už sám název Basic, jedná se o programovací jazyk, který se snaží být pokud možno uživatelsky přívětivý a maximálně zjednodušit programátorům práci. Jeho předností je jednoduché ovládání, kdy vývojové prostředí samo řeší řadu technických problémů. Ve Visual Basicu je možno velmi snadno a rychle vytvářet standardní aplikace. Jeho nevýhodou na druhou stranu je malá flexibilita Vztah jazyka Microsoft Visual Basic a technologie COM Visual Basic 6.0 (stejně jako už i předchozí verze 5.0) je sám vystavěn pomocí technologie COM a v důsledku toho je zavádění komponent v daném jazyce poměrně snadné. Převážnou většinu problémů, o kterých byla řeč v předchozí kapitole, ošetřuje Visual Basic automaticky. Například při tvorbě komponenty ve Visual Basicu se programátor nikde nesetká s takovými pojmy jako rozhraní IUnknown či metody QueryInterface, AddRef a Release. Práci s těmito metodami uschovává Visual Basic za běžné příkazy vyššího programovacího jazyka. Poznámka: Existence uvedených metod je samozřejmě patrná. Jako příklad můžeme uvést porovnávací operátor is. Ten zjišťuje zda dva ukazatele odkazují na tentýž objekt