Inter-Object kommunikáció
A COM-t úgy tervezték, hogy lehetővé tegye az ügyfelek számára, hogy transzparens módon kommunikáljanak az objektumokkal, függetlenül attól, hogy hol futnak ezek az objektumok – ugyanabban a folyamatban, ugyanazon a számítógépen vagy egy másik számítógépen. Ez egyetlen programozási modellt biztosít minden típusú objektumhoz, valamint az objektum-ügyfelekhez és az objektumkiszolgálókhoz is.
Az ügyfél szempontjából az összes objektum felületmutatókon keresztül érhető el. A mutatónak folyamatban kell lennie. Valójában az interfészfüggvények hívása mindig egy folyamaton belüli kódrészletet ér el először. Ha az objektum folyamatban van, a hívás közvetlenül, beavatkozó rendszerinfrastruktúra-kód nélkül éri el. Ha az objektum folyamaton kívüli, a hívás először a COM vagy az objektum által biztosított "proxy" objektumot éri el (ha a megvalósító kívánja). A proxycsomagok meghívják a paramétereket (beleértve az interfészmutatókat is), és létrehozzák a megfelelő távoli eljáráshívást (vagy egyénileg létrehozott proxyk esetén más kommunikációs mechanizmust) a másik folyamatba vagy arra a másik számítógépre, ahol az objektum implementációja található. Ezt a folyamathatárok közötti átvitelre mutató mutatók csomagolásának folyamatát marshalingnevezik.
A kiszolgáló szempontjából az objektum interfészfüggvényeinek összes hívása az adott felületre mutató mutatón keresztül történik. A mutatónak ismét csak egyetlen folyamat környezete van, és a hívónak mindig valamilyen folyamaton belüli kódnak kell lennie. Ha az objektum folyamatban van, a hívó maga az ügyfél. Ellenkező esetben a hívó egy "csonk" objektum, amelyet a COM vagy maga az objektum biztosít. A csonk fogadja a távoli eljáráshívást (vagy egyéni generált proxyk esetén más kommunikációs mechanizmust) az ügyfélfolyamat "proxyjától", feloldja a paramétereket, és meghívja a kiszolgálóobjektum megfelelő felületét. Mind az ügyfelek, mind a kiszolgálók szempontjából mindig közvetlenül kommunikálnak más folyamaton belüli kóddal.
A COM biztosítja a marsallság megvalósítását, más néven szabványos rendőrbírói. Ez az implementáció nagyon jól működik a legtöbb objektum esetében, és jelentősen csökkenti a programozási követelményeket, így a marshaling folyamat hatékonyan átláthatóvá válik.
Az interfész egyértelmű elkülönítése a COM folyamat átláthatóságának megvalósításától azonban bizonyos helyzetekben az utat járhatja. Az ügyfél szempontjából a funkciójára összpontosító interfészek tervezése olykor olyan tervezési döntésekhez vezethet, amelyek ütköznek a hálózati adapter hatékony megvalósításával. Az ilyen esetekben nem a tiszta folyamat átláthatóságára van szükség, hanem a "folyamat átláthatóságára, hacsak nem kell törődnie". A COM ezt a képességet úgy biztosítja, hogy lehetővé teszi egy objektum-implementátor számára, hogy támogassa egyéni marshaling (más néven IMarshal marshaling). A szokásos marsallálás valójában az egyéni marsallálás egy példánya; ez az alapértelmezett implementáció, amelyet akkor használunk, ha egy objektumhoz nincs szükség egyéni marsallálásra.
Egyéni marshaling implementálással lehetővé teheti, hogy egy objektum különböző műveleteket hajtson végre, ha egy hálózaton keresztül használják, mint a helyi hozzáférés alatt, és teljesen transzparens az ügyfél számára. Ez az architektúra lehetővé teszi az ügyfél-/objektum-adapterek tervezését a hálózati teljesítményproblémák, majd később a hálózati teljesítményproblémák megoldása érdekében a meglévő kialakítás megzavarása nélkül.
A COM nem határozza meg az összetevők strukturált felépítését; ez határozza meg az interakció módját. A COM programozási nyelvekre és fejlesztési környezetekre bízza az összetevők belső szerkezetével kapcsolatos aggodalmakat. Ezzel szemben a programozási környezetek nem rendelkeznek beállított szabványokkal az azonnali alkalmazáson kívüli objektumokkal való munkavégzéshez. A Microsoft Visual C++ például rendkívül jól működik az alkalmazásokon belüli objektumok manipulálására, de nem támogatja az alkalmazáson kívüli objektumok használatát. Ebben a tekintetben általában minden más programozási nyelv azonos. Ezért a hálózatszintű interoperabilitás biztosítása érdekében a COM nyelvfüggetlen interfészeken keresztül felveszi a programozási nyelvek elhagyását.
A vtbl-struktúra kettős indirektsége azt jelenti, hogy a függvénymutatók táblázatában lévő mutatóknak nem kell közvetlenül a valós objektum valós implementációjára mutatniuk. Ez a folyamat átláthatóságának lényege.
A folyamaton belüli kiszolgálók esetében, ahol az objektum közvetlenül az ügyfélfolyamatba van betöltve, a függvénymutatók a tábla pontjában közvetlenül a tényleges megvalósításra mutatnak. Ebben az esetben az ügyféltől egy interfészmetódusra irányuló függvényhívás közvetlenül átadja a végrehajtási vezérlőt a metódusnak. Ez azonban nem működik helyi, nem is beszélve távoli objektumokról, mert a memóriamutatók nem oszthatók meg a folyamatok között. Ennek ellenére az ügyfélnek úgy kell tudnia meghívni a felületi metódusokat, mintha a tényleges implementációt hívna meg. Így az ügyfél a hívással egységesen átviszi az irányítást egy objektum egy metódusára.
Az ügyfél mindig meghívja az interfészmetódusokat néhány folyamatban lévő objektumban. Ha a tényleges objektum helyi vagy távoli, a rendszer egy proxyobjektumra hívja meg a hívást, amely távoli eljáráshívást indít a tényleges objektumra.
Tehát melyik metódust hajtják végre valójában? A válasz az, hogy amikor egy folyamaton kívüli felületre irányuló hívás történik, minden felületi metódust proxyobjektum hajt végre. A proxyobjektum mindig egy folyamatban lévő objektum, amely a meghívott objektum nevében jár el. Ez a proxyobjektum tudja, hogy a tényleges objektum helyi vagy távoli kiszolgálón fut.
A proxyobjektum egyes adatcsomagokban csomagolja fel a függvényparamétereket, és RPC-hívást hoz létre a helyi vagy távoli objektumhoz. Ezt a csomagot egy csonkobjektum veszi fel a kiszolgáló folyamatában a helyi vagy távoli számítógépen, amely kicsomagolja a paramétereket, és meghívja a metódus valós megvalósítását. Amikor ez a függvény visszatér, a csonk a kimenő paramétereket és a visszatérési értéket csomagolja, majd visszaküldi a proxynak, amely kicsomagolja és visszaadja azokat az eredeti ügyfélnek.
Így az ügyfél és a kiszolgáló mindig úgy beszélnek egymással, mintha minden folyamatban volna. Az ügyféltől érkező összes hívás és a kiszolgálóra irányuló összes hívás folyamatban van. Mivel azonban a vtbl-struktúra lehetővé teszi, hogy egyes ügynökök( például a COM) elfogják az összes függvényhívást, és az összes függvényből visszatérjenek, az ügynök szükség szerint átirányíthatja ezeket a hívásokat egy RPC-hívásra. Bár a folyamatban lévő hívások gyorsabbak, mint a folyamaton kívüli hívások, a folyamatkülönbségek teljesen transzparensek az ügyfél és a kiszolgáló számára.
További információkért tekintse meg a következő témaköröket:
Kapcsolódó témakörök