Komponentní objektový model - Component Object Model

Component Object Model ( COM ) je standard binárního rozhraní pro softwarové komponenty zavedený společností Microsoft v roce 1993. Slouží k umožnění meziprocesového vytváření komunikačních objektů v široké škále programovacích jazyků . COM je základem pro několik dalších technologií a rámců společnosti Microsoft, včetně OLE , OLE Automation , Browser Helper Object , ActiveX , COM+ , DCOM , prostředí Windows , DirectX , UMDF a Windows Runtime . Podstatou COM je jazykově neutrální způsob implementace objektů, které lze použít v prostředí odlišném od prostředí, ve kterém byly vytvořeny, a to i přes hranice strojů. U dobře autorovaných komponent umožňuje COM opětovné použití objektů bez znalosti jejich interní implementace, protože nutí implementátory komponent poskytovat přesně definovaná rozhraní, která jsou od implementace oddělena. Různé alokační sémantiky jazyků jsou přizpůsobeny tím, že objekty jsou zodpovědné za své vlastní vytváření a ničení pomocí počítání referencí . Metoda převodu typu převodu mezi různými rozhraními objektu je dosažena QueryInterface. Upřednostňovanou metodou „dědičnosti“ v rámci COM je vytváření dílčích objektů, na které jsou delegována „volání“ metody.

COM je technologie rozhraní definovaná a implementovaná jako standard pouze v systémech Microsoft Windows a Apple Core Foundation 1.3 a novějších aplikačních programovacích rozhraních (API). Ten druhý implementuje pouze podmnožinu celého rozhraní COM. U některých aplikací byl COM alespoň do určité míry nahrazen rámcem Microsoft .NET a podporou webových služeb prostřednictvím Windows Communication Foundation (WCF). Objekty modelu COM lze však použít se všemi jazyky .NET prostřednictvím .NET COM Interop . Síťový DCOM používá binární proprietární formáty , zatímco WCF doporučuje používání zpráv SOAP na bázi XML . COM je velmi podobný ostatním technologiím rozhraní softwarových komponent , jako jsou CORBA a Enterprise JavaBeans , i když každá má své vlastní silné a slabé stránky. Na rozdíl od C ++ poskytuje COM stabilní binární rozhraní aplikace (ABI), které se mezi verzemi kompilátoru nemění. Díky tomu jsou rozhraní COM atraktivní pro objektově orientované knihovny C ++, které mají používat klienti kompilovaní pomocí různých verzí kompilátoru.

Dějiny

Jednou z prvních metod meziprocesové komunikace ve Windows byla Dynamic Data Exchange (DDE), poprvé zavedená v roce 1987, která umožňovala odesílání a přijímání zpráv v takzvaných „konverzacích“ mezi aplikacemi. Antony Williams , který se podílel na tvorbě architektury COM, později distribuoval dva interní dokumenty v Microsoftu, které přijaly koncept softwarových komponent: Object Architecture: Dealing With the Unknown - or - Type Safety in a Dynamically Extensible Class Library in 1988 and O dědičnosti: Co to znamená a jak to použít v roce 1990. Ty poskytly základ mnoha myšlenek za COM. Object Linking and Embedding (OLE), první objektový framework Microsoftu, byl postaven na DDE a navržen speciálně pro složené dokumenty . Byl zaveden s aplikací Word pro Windows a Excel v roce 1991 a později byl zahrnut do systému Windows, počínaje verzí 3.1 v roce 1992. Příkladem složeného dokumentu je tabulka vložená do dokumentu aplikace Word pro Windows: jak se v tabulce provádějí změny v aplikaci Excel se automaticky zobrazí v dokumentu aplikace Word.

V roce 1991 představila společnost Microsoft Visual Basic Extensions (VBX) s Visual Basic 1.0. VBX je zabalené rozšíření ve formě dynamické knihovny (DLL), které umožňuje graficky umístit objekty do formuláře a manipulovat s nimi pomocí vlastností a metod . Ty byly později přizpůsobeny pro použití jinými jazyky, jako je Visual C ++ . V roce 1992, kdy byla vydána verze 3.1 systému Windows, vydala společnost Microsoft OLE 2 s podkladovým objektovým modelem . COM Abi (ABI) byl stejný jako MAPI ABI (vydané v roce 1992), a jako by to bylo na základě MSRPC a nakonec na Open Group je DCE / RPC . Zatímco OLE 1 byl zaměřen na složené dokumenty, COM a OLE 2 byly navrženy tak, aby řešily softwarové komponenty obecně. Ukázalo se, že textové konverzace a zprávy systému Windows nejsou dostatečně flexibilní, aby umožňovaly robustní a rozšiřitelné sdílení funkcí aplikace, takže COM byl vytvořen jako nový základ a OLE se změnil na OLE2. V roce 1994 byly zavedeny vlastní ovládací prvky OLE (OCX) jako nástupce ovládacích prvků VBX. Microsoft zároveň uvedl, že OLE 2 bude jen známý jako „OLE“ a že OLE už není zkratka, ale název pro všechny technologie komponent společnosti. Počátkem roku 1996 společnost Microsoft našla nové využití pro vlastní ovládací prvky OLE, rozšířila možnosti svého webového prohlížeče prezentovat obsah, přejmenovala některé části OLE související s internetem na „ ActiveX “ a postupně přejmenovala všechny technologie OLE na ActiveX, kromě technologie složených dokumentů který byl použit v Microsoft Office . Později téhož roku Microsoft rozšířil COM tak, aby fungoval přes síť s DCOM .

Související technologie

COM byla hlavní platformou pro vývoj softwaru pro Windows a jako taková ovlivnila vývoj řady podpůrných technologií. To bylo také silně ovlivněno dřívějšími technologiemi.

DDE

COM nahradil DDE jako preferovanou formu meziprocesové komunikace.

DCE/RPC a MSRPC

Jako model více jazykových komponent se COM při popisu objektů a přidružených funkcí opírá o jazyk definice rozhraní nebo IDL. COM IDL je silně založen na IDL DCE/RPC bohatém na funkce s objektově orientovanými rozšířeními. Vlastní implementace DCE/RPC od Microsoftu, známá jako MSRPC, je hojně využívána jako primární meziprocesový komunikační mechanismus pro služby Windows NT a interní komponenty, což z ní činí jasnou volbu základů.

DCOM

DCOM ( Distributed COM ) rozšířil dosah COM z pouhé podpory jednoho uživatele se samostatnými aplikacemi komunikujícími na ploše Windows, na aktivaci objektů běžících v různých kontextech zabezpečení a na různých počítačích v síti. S tím byly přidány nezbytné funkce pro konfiguraci, kteří uživatelé mají oprávnění vytvářet, aktivovat a volat objekty, pro identifikaci volajícího uživatele a také pro specifikaci požadovaného šifrování pro zabezpečení hovorů.

COM+

Aby společnost Microsoft mohla poskytovat vývojářům podporu pro distribuované transakce , sdružování zdrojů, odpojené aplikace, publikování událostí a předplatné, lepší správu paměti a procesoru (podprocesu) a také umístění Windows jako alternativy k jiným operačním systémům na podnikové úrovni, Společnost Microsoft představila v systému Windows NT 4. technologii s názvem Microsoft Transaction Server (MTS). V systému Windows 2000 bylo toto významné rozšíření modelu COM začleněno do operačního systému (na rozdíl od řady externích nástrojů poskytovaných MTS ) a přejmenováno na COM+ . Microsoft současně zdůraznil DCOM jako samostatnou entitu. Komponenty, které využívaly služby COM+, byly zpracovány příměji přidanou vrstvou COM+, zejména podporou operačního systému pro zachycení. V prvním vydání MTS bylo řešeno odposlechy - instalace součásti MTS by změnila registr systému Windows tak, aby zavolal software MTS, a nikoli komponentu přímo. Systém Windows 2000 také zrevidoval aplikaci ovládacího panelu Component Services používanou ke konfiguraci komponent COM+.

Výhodou modelu COM+ bylo, že jej lze provozovat v „komponentních farmách“. Instance komponenty, pokud jsou správně kódovány, by mohly být sdruženy a znovu použity novými voláními její inicializační rutiny, aniž by se uvolnily z paměti. Komponenty lze také distribuovat (volat z jiného počítače). COM+ a Microsoft Visual Studio poskytly nástroje, které usnadňují generování proxy na straně klienta, takže ačkoli pro vzdálené volání bylo použito DCOM, bylo to pro vývojáře snadné. COM+ také zavedl mechanismus událostí předplatitele/vydavatele nazvaný Události COM+ a poskytl nový způsob využití MSMQ (technologie, která poskytuje asynchronní zasílání zpráv mezi aplikacemi) s komponenty nazývanými Queued Components . Události COM+ rozšiřují model programování COM+ tak, aby podporoval pozdní (viz Pozdní vazba ) události nebo volání metod mezi vydavatelem nebo předplatitelem a systémem událostí.

.SÍŤ

Microsoft .NET poskytuje prostředky jak pro poskytování technologie komponent, tak pro interakci s COM+ (prostřednictvím COM-interop-assemblies); .NET poskytuje obálky pro většinu běžně používaných ovládacích prvků COM. Microsoft .NET skrývá většinu detailů z vytváření komponent, a proto usnadňuje vývoj. .NET může využívat COM+ prostřednictvím oboru názvů System.EnterpriseServices a několik služeb, které COM+ poskytuje, bylo v nedávných vydáních .NET duplikováno. Například obor názvů System.Transactions v .NET poskytuje třídu TransactionScope, která poskytuje správu transakcí bez použití COM+. Podobně, ve frontě komponenty mohou být nahrazeny systémem Windows Communication Foundation s MSMQ dopravou. (MSMQ je však nativní komponentou COM.) Zpětná kompatibilita má omezenou podporu. Objekt COM lze v .NET použít pomocí implementace Runtime Callable Wrapper (RCW). Objekty NET, které vyhovují určitým omezením rozhraní, lze v objektech COM použít voláním obálky s možností volání COM (CCW). Ze strany COM i .NET se objekty využívající jinou technologii zobrazují jako nativní objekty. Viz COM Interop . WCF (Windows Communication Foundation) usnadňuje řadu výzev pro vzdálené spuštění modelu COM. Například umožňuje snadnější transparentní zařazování objektů podle hodnoty napříč hranicemi procesu nebo stroje.

Windows Runtime

Nový programovací a aplikační model Microsoft Windows Runtime (nebo WinRT, nezaměňovat s Windows RT ) je v podstatě API založené na COM, i když se spoléhá na vylepšený COM. Windows Runtime díky svému základu podobnému modelu COM umožňuje relativně snadné propojení z více jazyků, stejně jako COM, ale v zásadě jde o nespravované nativní rozhraní API. Definice API jsou však uloženy v souborech „.winmd“, které jsou kódovány ve formátu metadat ECMA 335, což je stejný formát metadat CLI, který .NET používá s několika úpravami. Tento společný formát metadat umožňuje výrazně menší režii než P/Invoke při vyvolání WinRT z aplikací .NET a jeho syntaxe je mnohem jednodušší.

Nano-COM (aka XPCOM)

Nano-COM je extrémně malá podmnožina komponentního objektového modelu, který je zaměřen výhradně na aspekty aplikačního binárního rozhraní (ABI) modelu COM, což umožňuje volání funkcí a metod napříč nezávisle kompilovanými moduly/komponentami. Nano-COM lze snadno vyjádřit v jediném hlavičkovém souboru C ++, který je přenosný do všech kompilátorů C ++. Nano-COM rozšiřuje nativní ABI základní architektury instrukcí a OS, aby přidal podporu pro odkazy na zadané objekty (typické ABI se zaměřují pouze na atomové typy, struktury, pole a konvence volání funkcí). Základ Nano-COM použil Mozilla k bootstrapu Firefoxu ( XPCOM ) a v současné době se používá jako základní technologie ABI pro DirectX / Direct3D / DirectML .

Soubor záhlaví Nano-COM definuje nebo pojmenuje alespoň tři typy:

• GUID k identifikaci typů rozhraní - to je ve skutečnosti 128bitové číslo
• HRESULT k identifikaci chybových kódů z volání metod - toto je ve skutečnosti standardizované použití 32bitových ints na dobře známé hodnoty (S_OK, E_FAIL, E_OUTOFMEMORY atd.)
• IUnknown jako základní typ pro všechny odkazy na zadané objekty - to jsou ve skutečnosti abstraktní virtuální funkce pro podporu dynamic_cast<T>získávání stylů nových typů rozhraní a počítání ref a lashared_ptr<T>

Mnoho použití Nano-COM také definuje dvě funkce pro adresování vyrovnávacích pamětí přidělených volaným jako výsledky

• <NanoCom> Alloc - voláno implementacemi metod k přidělení surových vyrovnávacích pamětí (nikoli objektů), které jsou vráceny volajícímu
• <NanoCom> Zdarma-volají volající metody k uvolnění vyrovnávacích pamětí přidělených volajícím, jakmile se již nepoužívají

Některé implementace Nano-COM, jako je Direct3D, se vyhýbají funkcím přidělovače a omezují se pouze na používání vyrovnávacích pamětí přidělených volajícím.

Nano-COM nemá pojem o třídách, bytech, zařazování, registraci atd. Odkazy na objekty jsou spíše jednoduše předávány přes hranice funkcí a přidělovány prostřednictvím standardních jazykových konstrukcí (např. Nový operátor C ++).

Bezpečnostní

Komponenty COM a ActiveX jsou spuštěny jako nativní kód na počítači uživatele bez sandboxingu. Existuje tedy několik omezení ohledně toho, co kód dokáže. Předchozí praxe vkládání komponent ActiveX na webové stránky pomocí aplikace Internet Explorer proto vedla k problémům s malwarovou infekcí. Společnost Microsoft rozpoznala problém s ActiveX již v roce 1996, kdy Charles Fitzgerald řekl: „Nikdy jsme netvrdili, že ActiveX je vnitřně bezpečný“. Nedávné verze aplikace Internet Explorer vyzývají uživatele před instalací ovládacích prvků ActiveX, což mu umožní zakázat instalaci ovládacích prvků z webů, kterým uživatel nedůvěřuje. Ovládací prvky ActiveX jsou podepsány s digitálním podpisem , aby byla zaručena jejich pravost. Je také možné zcela deaktivovat ovládací prvky ActiveX nebo povolit pouze několik vybraných. Transparentní podpora mimoprocesových serverů COM stále zvyšuje bezpečnost softwaru z hlediska izolace procesů . To může být užitečné pro oddělení subsystémů velké aplikace do samostatných procesů. Izolace procesů omezuje poškození stavu v jednom procesu z negativního ovlivnění integrity ostatních procesů, protože komunikují pouze prostřednictvím přesně definovaných rozhraní. Aby byl obnoven platný stav, je tedy nutné restartovat pouze dotčený subsystém. To není případ subsystémů v rámci stejného procesu, kde nepoctivý ukazatel v jednom subsystému může náhodně poškodit jiné subsystémy.

Technické údaje

Programátoři COM vytvářejí svůj software pomocí komponent podporujících COM . Různé typy komponent jsou identifikovány pomocí ID tříd (CLSID), což jsou globálně jedinečné identifikátory (GUID). Každá součást modelu COM zpřístupňuje své funkce prostřednictvím jednoho nebo více rozhraní . Různá rozhraní podporovaná komponentou se navzájem odlišují pomocí ID rozhraní (IID), což jsou také GUID. Rozhraní COM mají vazby v několika jazycích, jako je C , C ++ , Visual Basic , Delphi , Python a několik skriptovacích jazyků implementovaných na platformě Windows. Veškerý přístup ke komponentám se provádí pomocí metod rozhraní. To umožňuje techniky, jako je meziprocesové nebo dokonce mezipočítačové programování (druhé využívá podporu DCOM).

Rozhraní

Všechny komponenty COM implementují rozhraní IUnknown ( vlastní ), které zpřístupňuje metody pro počítání referencí a převod typů (přetypování). Zvyk IUnknown rozhraní se skládá z ukazatel na virtuální metody tabulky , která obsahuje seznam ukazatelů na funkce, které implementují funkce deklarované v rozhraní, ve stejném pořadí, v jakém jsou deklarovány v rozhraní. Režie vyvolání během procesu je tedy srovnatelná s voláním virtuální metody v C ++ . Kromě vlastních rozhraní podporuje COM také rozhraní pro odesílání dědící z IDispatch . Rozhraní odesílání podporují pozdní vazbu pro automatizaci OLE . To umožňuje nativní přístup k rozhraním dispečinku z širší škály programovacích jazyků než z vlastních rozhraní.

Třídy

Třída COM („coclass“) je konkrétní implementací jednoho nebo více rozhraní a velmi se podobá třídám v objektově orientovaných programovacích jazycích. Třídy jsou vytvářeny na základě jejich ID třídy ( CLSID ) nebo na základě řetězce jejich programového identifikátoru ( ProgID ). Jako mnoho objektově orientovaných jazyků poskytuje COM oddělení rozhraní od implementace. Toto rozlišení je obzvláště silné v modelu COM, kde k objektům nelze přistupovat přímo, ale pouze prostřednictvím jejich rozhraní. COM má také podporu pro více implementací stejného rozhraní, takže klienti za běhu si mohou vybrat, jakou implementaci rozhraní mají vytvořit instanci.

Definice rozhraní Knihovny jazyků a typů

Knihovny typů obsahují metadata, která představují typy COM. Tyto typy jsou popsány pomocí Microsoft Interface Definition Language (MSIDL/IDL). Soubory IDL definují objektově orientované třídy, rozhraní, struktury, výčty a další uživatelsky definované typy způsobem nezávislým na jazyce. IDL má podobný vzhled jako deklarace C ++ s některými dalšími klíčovými slovy, jako jsou „rozhraní“ a „knihovna“ pro definování rozhraní a sbírek tříd. IDL také podporuje použití závorkových atributů před deklaracemi k poskytnutí dalších informací, jako jsou GUID rozhraní a vztahy mezi parametry ukazatele a délkovými poli. Soubory IDL jsou kompilovány překladačem MIDL . Pro C/C ++ kompilátor MIDL generuje hlavičkový soubor nezávislý na kompilátoru, který obsahuje definice struktur tak, aby odpovídaly vtbls deklarovaných rozhraní a soubor C obsahující deklarace GUID rozhraní . Zdrojový kód C ++ pro modul proxy lze také generovat kompilátorem MIDL. Tento proxy server obsahuje pahýly metod pro převod volání COM na vzdálená volání procedur, aby se DCOM umožnil komunikaci mimo proces. Soubory IDL lze také kompilovat překladačem MIDL do knihovny typů (TLB). Soubory TLB obsahují binární metadata, která mohou být zpracována různými jazykovými kompilátory a běhovými prostředími (např. VB, Delphi, .NET atd.) Pro generování jazykově specifických konstrukcí reprezentujících typy COM definované v TLB. V případě C ++ se tím TLB převede zpět na jeho reprezentaci IDL.

Objektový rámec

Protože COM je runtime framework, typy musí být za běhu individuálně identifikovatelné a specifikovatelné. K dosažení tohoto cíle se používají globálně jedinečné identifikátory (GUID). Každý typ COM je označen svým vlastním GUID pro identifikaci za běhu. Aby byly informace o typech COM přístupné jak v době kompilace, tak za běhu, COM používá knihovny typů. Díky efektivnímu využívání knihoven typů dosahuje COM svých schopností jako dynamického rámce pro interakci objektů.

Zvažte následující příklad definice coclass v IDL:

coclass SomeClass {
  [default] interface ISomeInterface;
};

Výše uvedený fragment kódu deklaruje třídu COM s názvem, SomeClasskterá implementuje rozhraní s názvem ISomeInterface.

To je koncepčně ekvivalentní definování následující třídy C ++: This is conceptually equivalent to defining the following C ++ class:

class SomeClass : public ISomeInterface {
  ...
  ...
};

kde ISomeInterface je čistá virtuální třída C ++ (někdy se jí říká abstraktní základní třída).

Soubory IDL obsahující rozhraní a třídy COM jsou kompilovány do souborů knihoven typů (TLB), které mohou být později analyzovány klienty za běhu, aby určily, která rozhraní objekt podporuje, a vyvolat metody rozhraní objektu.

V C ++ jsou objekty COM vytvořeny pomocí CoCreateInstancefunkce, která bere jako argumenty ID třídy (CLSID) a ID rozhraní (IID). Instanci instance SomeClasslze implementovat následovně:

ISomeInterface* interface_ptr = NULL;
HRESULT hr = CoCreateInstance(CLSID_SomeClass, NULL, CLSCTX_ALL,
                              IID_ISomeInterface, (void**)&interface_ptr);

V tomto příkladu se subsystém COM používá k získání ukazatele na objekt, který implementuje ISomeInterfacerozhraní, a je vyžadována konkrétní implementace tohoto rozhraní CLCID_SomeClass.

Počítání referencí

Všechny objekty COM využívají počítání referencí ke správě životnosti objektů. Počty referencí jsou řízeny klienty prostřednictvím metod AddRef a Release v povinném rozhraní IUnknown, které implementují všechny objekty COM. Objekty COM jsou pak zodpovědné za uvolnění vlastní paměti, když počet odkazů klesne na nulu. Některé jazyky (např. Visual Basic ) zajišťují automatické počítání referencí, takže vývojáři objektů COM nemusí ve svých zdrojových kódech explicitně udržovat žádný interní čítač referencí. V C ++ může kodér buď provádět explicitní počítání referencí, nebo pomocí inteligentních ukazatelů automaticky spravovat počty referencí.

Níže jsou uvedeny pokyny pro volání AddRef a Release na objektech COM:

• Funkce a metody, které vracejí odkazy na rozhraní (prostřednictvím návratové hodnoty nebo pomocí parametru „out“), zvýší počet odkazů vráceného objektu před návratem.
• Uvolnění musí být vyvoláno na ukazateli rozhraní, než bude ukazatel přepsán nebo přejde mimo rozsah.
• Pokud je vytvořena kopie na ukazateli referenčního rozhraní, AddRef by měl být volán na tomto ukazateli.
• AddRef a Release musí být voláno na konkrétním rozhraní, na které se odkazuje, protože objekt může implementovat počet odkazů na rozhraní, aby bylo možné přidělit interní zdroje pouze pro rozhraní, na která se odkazuje.

Ne všechna volání počtu odkazů jsou odesílána do vzdálených objektů po drátu; proxy uchovává pouze jednu referenci na vzdáleném objektu a udržuje si vlastní počet místních odkazů. Pro zjednodušení vývoje modelu COM představila společnost Microsoft pro vývojáře C ++ ATL (Active Template Library) . ATL poskytuje paradigma vývoje COM vyšší úrovně. Také chrání vývojáře klientských aplikací COM před potřebou přímo udržovat počítání referencí tím, že poskytuje objekty inteligentních ukazatelů . Mezi další knihovny a jazyky, které znají COM, patří Microsoft Foundation Classes , VC Compiler COM Support, VBScript , Visual Basic , ECMAScript ( JavaScript ) a Borland Delphi .

Programování

COM je binární standard agnostického jazyka, který lze vyvinout v jakémkoli programovacím jazyce schopném porozumět a implementovat jeho binárně definované datové typy a rozhraní. Implementace COM jsou zodpovědné za vstup a výstup z prostředí COM, vytváření instancí a počítání referenčních objektů COM, dotazování objektů na podporovaná rozhraní a také za zpracování chyb. Kompilátor Microsoft Visual C ++ podporuje rozšíření jazyka C ++ označovaného jako atributy C ++ . Tato rozšíření jsou navržena tak, aby zjednodušila vývoj modelu COM a odstranila velkou část standardního kódu potřebného k implementaci serverů COM v jazyce C ++.

Využití registru

V systému Windows jsou třídy COM, rozhraní a knihovny typů uvedeny podle identifikátorů GUID v registru pod položkami HKEY_CLASSES_ROOT \ CLSID pro třídy a HKEY_CLASSES_ROOT \ Interface pro rozhraní. Knihovny COM používají registr k vyhledání správných místních knihoven pro každý objekt COM nebo síťového umístění pro vzdálenou službu.

COM bez registrace

Registrace zdarma COM (RegFree COM) je technologie zavedena s Windows XP , který umožňuje Component Object Model (COM) komponenty k aktivaci úložiště metadat a CLSID ( Class ID) pro složky bez použití registru . Místo toho jsou metadata a CLSID tříd implementovaných v komponentě deklarovány v manifestu sestavení (popsaném pomocí XML ), uloženém buď jako prostředek ve spustitelném souboru, nebo jako samostatný soubor nainstalovaný s komponentou. To umožňuje instalaci více verzí stejné komponenty do různých adresářů, popsaných jejich vlastními manifesty, stejně jako nasazení XCOPY . Tato technika má omezenou podporu pro servery EXE COM a nelze ji použít pro součásti celého systému, jako jsou MDAC , MSXML , DirectX nebo Internet Explorer .

Během načítání aplikace vyhledávač Windows vyhledá manifest. Pokud je k dispozici, zavaděč z něj přidá informace do kontextu aktivace. Když se továrna třídy COM pokusí vytvořit instanci třídy, nejprve se zkontroluje aktivační kontext, aby se zjistilo, zda lze najít implementaci pro CLSID. Pouze pokud vyhledávání selže, je registr zkontrolován.

Ruční vytváření instancí objektů COM

Objekty COM lze také vytvářet ručně, vzhledem k cestě k souboru DLL a GUID objektu. To nevyžaduje, aby byla knihovna DLL nebo GUID zaregistrována v systémovém registru, a nepoužívá soubory manifestu. COM DLL exportuje funkci s názvem DllGetClassObject. Volání DllGetClassObject s požadovaným GUID a IID_IClassFactory poskytuje instanci továrního objektu . Objekt Factory má metodu CreateInstance, která může vytvářet instance objektu s identifikátorem GUID rozhraní. Jedná se o stejný proces, který se interně používá při vytváření instancí registrovaných komponent COM.

Pokud vytvořený objekt COM vytvoří instanci jiného objektu COM pomocí obecného rozhraní CoCreateInstance API, pokusí se to provést obvyklým obecným způsobem pomocí souborů registru nebo manifestu. Může však vytvářet interní objekty (které nemusí být vůbec registrovány) a rozdávat jim odkazy na rozhraní pomocí vlastních soukromých znalostí.

Průhlednost procesů a sítě

Objekty COM lze transparentně vytvářet instance a odkazovat na ně v rámci stejného procesu (v procesu), přes hranice procesu (mimo proces) nebo vzdáleně přes síť (DCOM). Objekty mimo proces a vzdálené objekty používají zařazování k serializaci volání metod a vrácení hodnot přes hranice procesu nebo sítě. Toto zařazování je neviditelné pro klienta, který přistupuje k objektu, jako by to byl místní zpracovávaný objekt.

Navlékání

V COM je vlákno řešeno prostřednictvím konceptu známého jako byty . Jednotlivé objekty modelu COM žijí přesně v jednom bytě, který může být buď s jedním vláknem, nebo s více vlákny. V COM jsou tři typy apartmánů: Single-Threaded Apartment (STA) , Multi-Threaded Apartment (MTA) , and Thread Neutral Apartment (NA). Každý byt představuje jeden mechanismus, pomocí kterého lze vnitřní stav objektu synchronizovat mezi více vlákny. Proces se může skládat z více objektů COM, z nichž některé mohou používat STA a jiné MTA. Všechna vlákna přistupující k objektům COM podobně žijí v jednom bytě. Volba typu apartment pro objekty COM a vlákna jsou určena za běhu a nelze je změnit.

Vlákna a objekty, které patří do stejného bytu, dodržují stejná pravidla přístupu k vláknu. Volání metod, která se provádějí uvnitř stejného bytu, se proto provádějí přímo bez jakékoli pomoci COM. Volání metod napříč byty probíhá prostřednictvím seřaďování. To vyžaduje použití proxy a stubů.

Kritika

Vzhledem k tomu, že COM má poměrně složitou implementaci, mohou být programátoři rozptýleni některými "instalatérskými" problémy.

Čerpání zpráv

Při inicializaci STA vytvoří skryté okno, které se používá pro směrování zpráv mezi byty a mezi procesy. Toto okno musí mít svoji frontu zpráv pravidelně „pumpovanou“. Tato konstrukce je známá jako „ pumpa zpráv “. V dřívějších verzích systému Windows by jejich selhání mohlo způsobit zablokování celého systému. Tento problém komplikují některá rozhraní Windows API, která inicializují COM jako součást jejich implementace, což způsobuje „únik“ podrobností implementace.

Počítání referencí

Počítání odkazů v COM může způsobit problémy, pokud jsou dva nebo více objektů cyklicky odkazováno . Návrh aplikace to musí vzít v úvahu, aby objekty nezůstaly osiřelé. Objektům může také zůstat aktivní počet referencí, pokud je použit model COM „událost jímky“. Protože objekt, který událost spustí, potřebuje odkaz na objekt reagující na událost, jeho počet odkazů nikdy nedosáhne nuly. Referenční cykly jsou obvykle přerušeny pomocí ukončení mimo pásmo nebo rozdělených identit. V technice ukončení pásma mimo objekt objekt odhaluje metodu, která jej při volání nutí upustit jeho odkazy na jiné objekty, čímž se cyklus prolomí. V technice dělené identity odhaluje jedna implementace dva samostatné objekty COM (známé také jako identity). To vytváří slabou referenci mezi objekty COM a brání referenčnímu cyklu.

DLL peklo

Protože komponenty COM v procesu jsou implementovány do souborů DLL a registrace umožňuje pouze jednu verzi pro CLSID, mohou v některých situacích podléhat efektu „ DLL Hell “. Možnost COM bez registrace eliminuje tento problém u komponent v procesu; COM bez registrace není k dispozici pro servery mimo proces.

Viz také

• Přenosná objektová (výpočetní) multiplatformní definice modelu modelu platformy
• Distributed Component Object Model (DCOM), rozšíření umožňující COM pracovat v sítích
• Aktuální jazyková infrastruktura aktuální .NET cross language cross platform Object Model
• Windows Runtime , aplikační model, vyvinutá verze COM zaměřená na Windows 8
• CORBA Common Object Request Broker Architecture, otevřený multiplatformní objektový model pro více jazyků
• Otevřený křížový jazykový multiplatformní objektový model D-Bus
• Rámec komponent KParts KDE
• SOM Systémový objektový model IBM, alternativa ke COM, bohatá na funkce
• XPCOM Aplikace Mozilla napříč platformovým komponentním objektovým modelem
• Enterprise JavaBeans
• Vyvolání vzdálené metody Java
• Internetový komunikační stroj
• Jazyková vazba
• Rozhraní cizích funkcí
• Konvence volání
• Mangling jména
• Rozhraní pro programování aplikací - API
• Aplikační binární rozhraní - ABI
• Generátor vazeb automatických rozhraní SWIG opensource z mnoha jazyků do jiných jazyků

Poznámky

Reference

• „COM: Stručný úvod (powerpoint)“ . Získaný 7. března 2006 .
• Box, Don (1998). Základní COM . Addison-Wesley. ISBN 978-0-201-63446-4.
• Chappell, David (1996). Pochopení ActiveX a OLE . Microsoft Press. ISBN 978-1-57231-216-6.
• „Integrace a migrace služeb COM+ na WCF“ . Citováno 15. dubna 2010 .

externí odkazy

• Komponentní objektový model na MSDN
• Interview with Tony Williams, Co-Inventor of COM (Video Webcast, August 2006)
• Informace: Rozdíl mezi ovládacími prvky OLE a ovládacími prvky ActiveX od společnosti Microsoft
• Specifikace formátu dat TypeLib (neoficiální) s obslužným programem sklápěče s otevřeným zdrojovým kódem.
• Glosář COM / DCOM