Component Object Model
A Component Object Model (COM), mely ActiveX-ként is ismert, a Microsoft által kifejlesztett technológia a komponens alapú fejlesztés támogatására, mely a szoftverek közti kommunikációt teszi lehetővé. Bár több platformon is megvalósították, elsősorban a Microsoft Windows operációs rendszerében használják. Az elődje az object linking and embedding (OLE) technológia volt, ma a COM szerepét a Microsoft .NET rendszer veszi át.
A COM architektúra fejlesztésében részt vevő egyik legjelentősebb gondolkodó Anthony Williams volt, aki a szoftver komponensek elméletének jelentőségét az Object Architecture: Dealing With the Unknown – or – Type Safety in a Dynamically Extensible Class (1988) és az On Inheritance: What It Means and How To Use It (1990) műveiben publikálta.
Történelem[szerkesztés]
A Microsoft korábbi objektum-alapú, beágyazott dokumentumok kezelésére tervezett technológiája az Object Linking and Embedding (OLE) 1.0 volt, mely a dynamic data exchange-en (DDE) alapult. A beágyazott dokumentumokra egy példa a Microsoft Wordbe beágyazott táblázat. A táblázat tartalmát az Excelben megváltoztatva a tartalom megváltozik a Wordben is, illetve Wordben is változtatható a táblázat tartalma. 1991-ben mutatták be a Microsoft Word for Windows és Excel alkalmazásokkal, és később hozzáadták a Windows alapfunkcióihoz 1992-ben, a 3.1-es verziótól kezdve. 1991-ben a Microsoft bemutatta a Visual Basic-vezérlőket (VBX) a Visual Basic 1.0-s verziójával.
1993-ban a Microsoft kiadta az OLE 2-t, valamint megalkotta a COM-ot az OLE 2 alatt működő objektummodellként. Míg az OLE 1 beágyazott dokumentumok kezelésére szolgált, addig a COM és az OLE 2 szoftverkomponensek kezelését célozta meg. 1994-ben bemutatták az OLE vezérlőket (OCX) a VBX vezérlők utódaként. Ezzel egy időben a Microsoft bejelentette, hogy az OLE 2-t csak „OLE”-nek kell hívni, az OLE többé nem betűszó, hanem a vállalat komponenstechnológiájának összefoglaló neve.
1996 elején a Microsoft elnevezte az OLE internettel kapcsolatos részét ActiveX-nek, aztán minden OLE technológiát ActiveX-nek kezdett hívni, kivéve a Microsoft Office-ban használt beágyazott dokumentumtechnológiát. Később ugyanebben az évben bemutatták a DCOM-ot válaszként a CORBA technológiára.
Bár a COM technológia 1993 óta használatban van, a Microsoft 1997 óta használja a COM megnevezést.
COM+[szerkesztés]
A Windows 2000 megjelenésével a COM is jelentősen továbbfejlődött, melynek neve COM+ lett. Ezzel egy időben a Microsoft nem tekintette a DCOM-ot külön entitásnak.
A COM+ egyik előnye a "komponens farmok" támogatása, valamint az automatikus tranzakciókezelés a Microsoft Transaction Server (MTS) segítségével. Egy megfelelően kódolt komponens újrafelhasználható az új hívásokkal, nem kell törölni a memóriából. A komponensek elosztottak is lehetnek (másik gépről hívhatóak), ami korábban csak a DCOM használatával volt elérhető.
DCOM[szerkesztés]
Áttérés COM-ról .NET-re[szerkesztés]
A Microsoft .NET Keretrendszer nagy részben feleslegessé teszi a COM platformot. Bár a COM használható technológia marad (és a Microsoft nem is tervezi a megszüntetését), a vállalat a marketing tevékenységét a .NET platformra fókuszálja.
A .NET rendelkezik korlátozott COM kompatibilitással, ami lehetővé teszi a COM használatát egy runtime callable wrapper (RCW, futtató környezet által meghívható burkoló osztály) megvalósításával, valamint a COM képes használni a .NET osztályokat a COM callable wrapper (CCW, COM által meghívható burkoló osztály) megvalósításával. Ráadásul a legtöbb COM+ szolgáltatás (mint a tranzakció-kezelés) még mindig fontos szerepet tölt be az enterprise .NET (nagyvállalati környezetbe szánt) alkalmazások létrehozása során.
ActiveX és az internetes biztonság[szerkesztés]
Az ActiveX vezérlők beágyazása az Internet Explorerbe olyan lehetőségeket is nyitott, melyek a számítógépes vírusok, trójai programok és kémprogramok elterjedéséhez vezettek. Ezen támadások jelentős részének terjedése nagyban függ az ActiveX-től. A Microsoft 1996-ban nyilvánította ki, hogy problémák vannak az ActiveX-szel, amikor Charles Fitzgerald, a Microsoft Java csapatának programmenedzsere a következőket mondta: "Ha biztonságban akarsz lenni a Neten, húzd ki a géped. […] Sosem állítottuk, hogy az ActiveX biztonságos." [1]
Technikai részletek[szerkesztés]
A COM programozók a szoftvereiket a COM feltételeinek megfelelő komponensekből építik fel. A különböző komponens típusok osztályazonosítókkal (class ID, CLSID) azonosíthatóak, melyek globálisan egyéni azonosítók, avagy GUID-ok. Minden COM komponens egy vagy több interfészen keresztül szolgáltat funkciókat. A különböző, komponens által támogatott interfészek interfész azonosítókkal különböztethetőek meg egymástól (interface ID, IID), melyek szintén GUID-ok.
A COM interfészeknek több programozási nyelvhez van kötése , például C, C++, D, Visual Basic, valamint több Windows platformon implementált script nyelvhez. Minden hozzáférés a komponensekhez az interfészek metódusain keresztül történik. Ez olyan lehetőségeket kínál, mint a folyamatközi illetve számítógépközi programozás (az utóbbi DCOM segítségével valósul meg).
Minden komponensnek meg kell valósítania (legalább) a szabványos IUnknown interfészt. Tulajdonképpen minden COM interfész az IUnknown interfészből származik. Az IUnknown interfész három metódusból áll: az AddRef() és Release() függvények az interfészek referencia számlálását és élettartamát valósítják meg; valamint a QueryInterface(), ami egy IID, ami mutatókat ad vissza a különböző komponensek által megvalósított interfészekre. A QueryInterface() hatása hasonló a dynamic_cast<>-hoz a C++ -ban, illetve a cast-hoz a D, Java vagy C# nyelvben.
A COM több egyéb szabványos interfészt is definiál, melyek komponens-közi kommunikációt tesznek lehetővé. Például az egyik ilyen interfész az IStream, melyet adatfolyam szemantikát alkalmazó komponensek valósítanak meg (például a FileStream komponens, ami fájlokat ír és olvas). A Read és Write metódusokkal rendelkezik folyam olvasásra és írásra. Másik szabványos interfész az IOleObject, melyet olyan komponensek valósítanak meg, melyek valószínűleg konténerbe lesznek beágyazva vagy belinkelve. Az IOleObject olyan metódusokkal rendelkezik, melyek lehetővé teszik a komponens térigényét; a komponens támogatja-e az olyan műveleteket, mint a megnyitás, mentés stb.
Egy komponens futó példányát úgy lehet létrehozni, hogy a COM futtató könyvtártól kérünk egy class factoryt ("osztálygyár" minta), és megadjuk a CLSID-jét a kívánt komponensnek. Ezután utasítjuk a class factoryt a kívánt komponens egy példányának létrehozására, megadva egy IID-t egy bizonyos a komponens által megvalósított interfész kinyerésére. A kliens ezután meghívja az interfész metódusait, végül elengedi az interfészt a Release() metódus meghívásával.
A komponensek COM típuskönyvtárakkal (COM Type Library) tudják önmagukat leírni. A típuskönyvtár olyan információkat tartalmaz, mint a komponens CLSID-je, a komponens által megvalósított interfészek IID-ja, valamint ezen interfészek metódusainak leírása. A típuskönyvtárakat jellemzően RAD környezetek használják, mint a Visual Basic vagy Visual Studio, hogy segítsék a fejlesztőt a komponensek létrehozása során.
A COM programozók felelősek a COM környezetbe való belépésért és az onnan való kilépésért, a COM objektumok inicializálásáért és referenciaszámlálásáért, az objektumok verzióinformációjának lekérdezéséért, a fejlettebb objektum verziók lehetőségeit kihasználó kódért és a visszalépésért az újabb verzió hiányában. A COM osztályokat Globálisan egyedi azonosítók (GUID) azonosítják. A COM osztályokat regisztrálni kell a Regisztrációs adatbázisban. COM objektumokra folyamaton belül, folyamatok között és hálózaton keresztül lehet hivatkozni. A COM objektum figyeli a saját referenciaszámlálóját, és felszabadítja önmagát, ha a számláló értéke nulla.
