Komponens objektum modell
A Component Object Model (COM) egy Microsoft platform szoftverkomponensekhez , amelyet 1993 -ban vezettek be . Ez a platform lehetővé teszi a folyamatok közötti kommunikációt és az objektumok dinamikus létrehozását bármely programozási nyelven, amely támogatja ezt a technológiát. A COM kifejezést gyakran használják a szoftverfejlesztés világában az OLE, OLE Automation, ActiveX, COM+ és DCOM technológiák gyűjtőfogalmaként. Bár a COM-t 1993-ban vezették be, a Microsoft csak 1997-ben hangsúlyozta a COM nevet.
A COM lényegében a nyelvsemleges objektumok megvalósításának egyik módja, így azok a létrehozásuktól eltérő környezetben is használhatók, a géphatárokon túl. A jól elkészített komponensek esetében a COM lehetővé teszi az objektumok újrafelhasználását azok belső megvalósításának ismerete nélkül, mert arra kényszeríti az összetevő megvalósítóit, hogy jól definiált interfészeket biztosítsanak, amelyek elkülönülnek a megvalósítástól. A különböző memóriafoglalási szemantikákat úgy alkalmazzák, hogy az objektumokat a referenciaszámláláson keresztül saját létrehozásukért és megsemmisülésükért teszik felelőssé. Az objektum különböző felületei között aQueryInterface() . Az előnyben részesített öröklési módszer a COM-ban olyan alobjektumok létrehozása, amelyekre a metódushívások delegálódnak (az úgynevezett aggregáció).
Bár ezeket a technológiákat számos platformon implementálták, elsősorban Microsoft Windows programmal használják őket . A COM-ot legalább bizonyos mértékig felváltja a Microsoft .NET , és a Web Services támogatása a Windows Communication Foundation (WCF) révén. A hálózati DCOM szabadalmaztatott bináris formátumokat, míg a WCF XML - alapú SOAP -üzeneteket használ . A COM a CORBA -val és a JavaBeans - szel is versenyez, mint szoftverösszetevő rendszer.
Technikai részletek
A COM-programozók szoftvereket készítenek COM-tudatos szoftverkomponensek felhasználásával. A különböző típusú összetevőket típusazonosítók (CLSID) azonosítják, amelyek globálisan egyedi azonosítók vagy GUID-k. Minden COM-komponens egy vagy több interfészen keresztül felfedi működését. Az egyes összetevők által támogatott különböző interfészek interfészazonosítók (IID) segítségével különböztethetők meg egymástól, amelyek egyben GUID-k is.
A COM-interfészek különféle nyelveken vannak implementálva, például C, C++, Visual Basic, és számos, a Windows platformon implementált szkriptnyelven. A komponensekhez való minden hozzáférés az interfészek módszerein keresztül történik. Ez lehetővé teszi az olyan technikákat, mint az inter-processing, akár a számítógépek közötti programozás (utóbbi a DCOM támogatáson keresztül).
Interfészek
Minden COM összetevőnek legalább a szabványos IUnknown interfészt kell megvalósítania , így minden COM interfész az IUnknown -ból származik . Az IUnknown interfész három módszerből áll: AddRef()és Release(), amelyek referenciaszámlálást és interfész életciklus-vezérlést valósítanak meg; és QueryInterface(), amely egy IID megadásával lehetővé teszi a hívás számára, hogy hivatkozásokat kérjen le az összetevő által megvalósított különböző interfészekre. A hatása QueryInterface()hasonló dynamic_cast <>a C++-hoz vagy castinga C#-hoz és a Java-hoz.
A COM komponens interfészei szükségesek a reflexív, szimmetrikus és tranzitív tulajdonságok megjelenítéséhez. A reflektív tulajdonság arra utal, hogy a hívás képes QueryInterface()visszaadni az interfész azonos példányát, ha adott egy interfész azonosítóval. A szimmetrikus tulajdonság arra utal, hogy ha a B interfész lekérhető az A interfészről QueryInterface(), akkor az A interfész is visszakereshető a B interfészről. A tranzitív tulajdonság hasonló a szimmetrikus tulajdonsághoz, de megköveteli, hogy ha a B interfész lekérhető A-ról, és C pedig B-ből, akkor a C interfésznek elérhetőnek kell lennie A-ból.
Az interfész egy virtuális függvénymutatóból áll, amely az interfészben deklarált függvény által megvalósított függvényekre mutató mutatók listáját tartalmazza, abban a sorrendben, ahogyan azok az interfészben deklaráltak. Ez a szerkezeti függvénymutató átadási technika nagyon hasonló ahhoz, amelyet az OLE 1.0 használ a könyvtári rendszerével való kommunikációhoz.
A COM számos más szabványos interfészt határoz meg, amelyek lehetővé teszik az összetevők közötti kommunikációt. Például az egyik az IStream , amely az adatfolyam szemantikával rendelkező összetevők számára készült (a fájlok olvasására és írására használt FileStream komponens). A várt olvasási és írási metódusokkal rendelkezik az adatfolyam olvasásához és írásához. Egy másik szabványos interfész az IOleObject , amely olyan összetevők számára készült, amelyek egy tárolóba vannak kötve vagy beágyazva. Az IOleObject olyan módszereket tartalmaz, amelyek lehetővé teszik az érdekelt felek számára, hogy meghatározzák a téglalap komponens határainak méretét, ha az összetevő támogatja az olyan műveleteket, mint a „Megnyitás” , „Mentés” és így tovább.
Osztályok
A COM-ban egy osztályt coclassnak neveznek , amely a Component Object osztály szerződéses formája . A társosztály a COM módszere egy osztály meghatározására a nyelvtől független, objektumorientált értelemben. A társosztály egy vagy több interfész konkrét megvalósítását biztosítja. A COM-ban az ilyen konkrét implementációk bármilyen COM komponens fejlesztést támogató programozási nyelven írhatók, például C++, Visual Basic stb.
A COM egyik legnagyobb hozzájárulása a Windows fejlesztői világához az interfész és a megvalósítás elválasztásának koncepciójának tudatosítása. Ez a tudatosság kétségtelenül befolyásolta a programozók mai rendszereinek felépítését. Ennek az alapkoncepciónak a kiterjesztése az egy interfész, több megvalósítás koncepciója. Ez azt jelenti, hogy futási időben az alkalmazás választhat egy interfészt a több konkrét megvalósítás egyikéből.
Interfészdefiníciós nyelv és típuskönyvtárak
A típuskönyvtárak olyan metaadatokat tartalmaznak , amelyek a COM-típusokat képviselik. Ezeket a típusokat azonban először le kell írni a Microsoft Interface Definition Language (MIDL) segítségével. Ez bevett gyakorlat egy COM-komponens fejlesztésekor, például amikor az IDL-t használó típusok meghatározásával kezdjük. A COM által biztosított IDL-fájl lehetővé teszi a fejlesztők számára, hogy egymástól függetlenül definiáljanak objektumorientált osztályokat, interfészek, struktúrák, felsorolások és más, felhasználó által definiált típusokat egy nyelven. A COM IDL megjelenésében hasonló a C vagy C++ deklarációkhoz, olyan kulcsszavakkal, mint az "interfész" és a "könyvtár" az interfészek és osztálygyűjtemények meghatározásához. Az IDL megköveteli a zárójeles attribútumok használatát a deklarációk előtt, hogy további információkat nyújtson, például az interfészek GUID-jét, valamint a mezők mutató- és hosszparaméterei közötti kapcsolatot.
Az IDL fájlt a MIDL fordító több módon fordítja le, hogy különböző nyelveken használható legyen. C/C++ esetén a MIDL fordító egy fordítófüggetlen fejlécet hoz létre, amely a virtuális függvényeket az interfész deklarációhoz illő szerkezetdefiníciókat és egy interfészdeklaráció GUID-okat tartalmazó C fájlt tartalmaz. A Proxy modul C++ forráskódja a MIDL fordítóval is előállítható. Ez a proxy csonkmetódusokat tartalmaz a COM-hívások RPC-vé konvertálására, ezt a DCOM lehetővé teszi.
Az IDL fájlt a MIDL fordító is lefordíthatja típuskönyvtárba (.TLB fájl). A könyvtárban található bináris metaadatokat a nyelv fordítói és futási környezetei (VB, Delphi, .NET CLR stb.) dolgozzák fel. Az ilyen TLB feldolgozás végeredménye az, hogy nyelvspecifikus konstrukciók jönnek létre, amelyek a .TLB-ben meghatározott COM osztályt képviselik (és végső soron az IDL forrásfájlban meghatározottat).
Referencia számlálás
Az összes COM interfész közül a legfontosabb, azaz az IUnknown (amelyből minden COM interfésznek származnia kell), két fő koncepciót támogat: a jellemzők (vagy az objektum által megvalósított interfészek) lekérdezését a metóduson keresztül queryInterface(), valamint az objektum életciklusának kezelését a AddRef ()és a Release (). A Referenciaszámlálás és -lekérdezés szolgáltatás objektumokra vonatkozik (nem minden interfészre), ezért központi megvalósítással kell rendelkeznie.
A COM specifikációi megkövetelik a referenciaszámlálásnak nevezett technikát annak biztosítására, hogy a különböző objektumok mindaddig életben maradjanak, amíg vannak olyan kliensek, amelyek hozzáférést szereztek egy vagy több interfészükhöz, és fordítva, hogy ugyanaz az objektum megfelelően selejtezésre kerüljön, amikor az összes kód megtörtént. az objektumot használja, és már nincs szüksége rá. Egy COM objektum felelős a saját memóriájának felszabadításáért, ha a referenciaszámot nullára csökkentik.
A COM-objektum végrehajtásához általában fenntart egy értéket, amelyet referenciaként használnak a számláláshoz. Ha AddRef ()az objektum bármely interfészén keresztül hívják, ez az érték növekszik. Amikor meghívásra kerül Release(), ez az egész szám csökken. AddRef ()és Release ()ez az egyetlen eszköz, amellyel egy COM objektum kliense képes befolyásolni annak életciklusát. A belső érték a COM objektum privát tagja marad, és soha nem lesz közvetlenül elérhető.
Példányosítás
A COM szabványosítja a COM-objektumok példányosításának (vagyis létrehozásának) folyamatát a Factories osztály használatának megkövetelésével . Minden létrehozott COM objektumhoz két társított paraméternek kell léteznie:
- Egy személyazonosító osztály .
- Gyári osztály .
Minden COM-osztályhoz vagy CoClass -hoz egyedi osztályazonosítóhoz ( GUID ) kell rendelni . Azt is hozzá kell rendelni a saját Factory osztályához (amit egy központi nyilvántartás használatával érnek el). A Factory osztály maga is COM objektum. Ez egy olyan objektum, amelynek fel kell fednie az IClassFactory vagy az IClassFactory2 interfészt (ez utóbbi a támogatási licencekkel). Egy ilyen objektum felelőssége más tárgyak létrehozása.
A Factory osztály általában ugyanabban a végrehajtható kódban (vagyis a kódszerverben) található, mint maga a COM objektum. Amikor egy Factory osztályt hívunk meg egy célobjektum létrehozásához, akkor ennek az objektumnak a célja az osztályazonosító, amelyet meg kell adni. A Factory osztály így tudja, hogy az objektum melyik osztályát használja a példány.
Egyetlen Factory objektumosztály egynél több osztály objektumát is létrehozhatja. Vagyis két különböző osztályazonosítójú objektumot hozhat létre ugyanaz a Factory objektumosztály. Ez azonban átlátható a COM-rendszer számára.
Ha egy objektum létrehozásának felelősségét egy külön objektumra ruházzuk át, akkor magasabb szintű absztrakció érhető el, és a fejlesztő nagyobb rugalmasságot biztosít.
Annak érdekében, hogy az ügyfélalkalmazások gyári objektumosztályokat szerezzenek , a COM-kiszolgálóknak megfelelően fel kell őket tenniük. A gyári osztályok a szerverkód természetétől függően eltérően jelennek meg. A DLL-eken alapuló szervernek globális függvényt kell exportálnia DllGetClassObject (). Egy kiszolgáló EXE, amely a Factory osztályon alapul , futás közben a Windows API funkción keresztül CoRegisterClassObject ().
Programozás
A COM egy bináris szabvány, és bármilyen programozási nyelven fejleszthető, amely képes megérteni és megvalósítani a meghatározott bináris adattípusokat és interfészeket.
A futásidejű könyvtárak (extrém helyzetekben a programozók) felelősek a COM-környezetbe való be- és kilépésért, a COM-objektumok példányosításáért és hivatkozási számlálásáért, az objektumok verzióinformációi lekérdezéséért, a kódolás az objektumok fejlett verzióinak kihasználásáért.
Alkalmazások és hálózatok átláthatósága
A COM-objektumok példányosíthatók és hivatkozhatók egy folyamaton belül, a számítógépen belüli folyamathatárokon és a DCOM technológia segítségével hálózaton keresztül . A folyamatból való kilépés és a távoli objektumok szerializálást használhatnak metódushívások küldésére és értékek vissza- és előreküldésére. A szerializálás láthatatlan az objektum és az objektumot használó kód számára.
Kritika
Üzenet pumpálása
Az STA inicializálása során egy rejtett ablakot hoz létre, amelyet a lakások és a folyamatok közötti üzenetek továbbítására használnak. Ennek az ablaknak az üzenetsorát rendszeresen pumpálni kell. Ezt az építményt üzenetbombának nevezik. A Windows korábbi verzióiban ennek elmulasztása rendszerszintű összeomlásokat okozhat. Ez a probléma különösen kellemetlen, mert egyes Windows API -k az alkalmazásuk részeként inicializálják a COM-ot, ami a megvalósítás részleteinek kiszivárgását okozza.
Referencia számlálás
A COM-on belüli hivatkozásszámlálás problémákat okozhat, ha két vagy több objektumra körkörösen hivatkoznak. Az alkalmazástervnek ezt figyelembe kell vennie, hogy az objektumok ne legyenek árvak.
Az objektumok akkor is hagyhatják aktívan a referenciaszámlálást, ha a COM „nyelőház” a használt modell. Mivel az eseményt elindító objektumnak objektumhivatkozásra van szüksége ahhoz, hogy reagáljon az eseményre, az objektumhivatkozások száma soha nem éri el a nullát.
DLL pokol
Mivel az egyes összetevők helyét a rendszer egészére kiterjedő helyen tárolják (a Windows rendszerleíró adatbázisában), előfordulhat, hogy egy adott összetevőnek csak egy verziója van telepítve. Ezért a COM súlyosan szenved a DLL pokoltól , ahol két vagy több alkalmazás ugyanannak az összetevőnek különböző verzióit igényli.
A Windows XP egy új COM-objektum regisztrációs módot vezet be: "COM Free Registration". Ez a szolgáltatás lehetővé teszi, hogy az alkalmazások, amelyeknek COM-objektumokat kell telepíteniük, a COM-regisztrációhoz szükséges összes beállításjegyzék-információt a kérelemkönyvtárban tárolják, nem pedig a globális nyilvántartásban, ahol szigorúan véve csak egyetlen kérést használnak. A DLL pokol, a rendszerleíró adatbázis nélküli COM-mal elkerülhető, az egyetlen korlátozás az, hogy legalább Windows XP vagy újabb Windows-verziót igényel, és nem használható EXE, COM vagy szerverszintű rendszerkomponensekhez, például MDAC , MSXML , DirectX vagy Internet Explorer.
Hivatkozások
- Berger, Dan (2004). « COM: Rövid bevezetés » . Afrikai történelem az About.com oldalon . Letöltve: 2006. február 6 .
- Microsoft Corp. (2006). « Komponens objektummodell » . Archiválva az eredetiből , ekkor: 2006-03-18 . Letöltve: 2006. február 6 .
- Box, Don (1998). Alapvető COM . Addison-Wesley objektumtechnológiai sorozat . ISBN 0-201-63446-5 .
Lásd még
- Elosztott komponens objektummodell (DCOM)
- Dinamikus adatcsere (DDE)
- Microsoft .NET (.NET)
- Objektum összekapcsolás és beágyazás (OLE)
- szoftver komponens
- Komponens alapú szoftverfejlesztés
Külső linkek
- Microsoft COM Technologies .
- Miről szól az OLE valójában – Kraig Brockschmidt. A COM és az OLE áttekintése. (Angolul).
- Komponens alkalmazási csoport a Microsoft Researchnél .
- Mozilla ActiveX Project (angol nyelven).
- Bevezetés a Com-ba .
- INFORMÁCIÓ: Különbség a Microsoft OLE- és ActiveX-vezérlői között.
