komunikace Inter-Object
Com je navržený tak, aby klientům umožňoval transparentně komunikovat s objekty bez ohledu na to, kde jsou tyto objekty spuštěné – ve stejném procesu, na stejném počítači nebo na jiném počítači. Poskytuje jeden programovací model pro všechny typy objektů a pro klienty objektů i objektové servery.
Z pohledu klienta jsou všechny objekty přístupné prostřednictvím ukazatelů rozhraní. Ukazatel musí být v procesu. Jakékoli volání funkce rozhraní ve skutečnosti vždy nejprve dosáhne určité části kódu v procesu. Pokud je objekt v procesu, volání dorazí přímo, bez intervenování kódu systémové infrastruktury. Pokud je objekt mimo proces, volání nejprve dosáhne toho, co se nazývá "proxy" objekt poskytovaný objektem COM nebo objektem (pokud si implementátor přeje). Proxy balíčky volají parametry (včetně všech ukazatelů rozhraní) a vygenerují odpovídající vzdálené volání procedur (nebo jiný komunikační mechanismus v případě vlastních generovaných proxy serverů) do jiného procesu nebo jiného počítače, kde se nachází implementace objektu. Tento proces balení ukazatelů pro přenos přes hranice procesu se nazývá zařazování.
Z pohledu serveru jsou všechna volání funkcí rozhraní objektu provedena ukazatelem na toto rozhraní. Opět platí, že ukazatel má kontext pouze v jednom procesu a volající musí být vždy část kódu v procesu. Pokud je objekt v procesu, volající je sám klient. V opačném případě je volající "zástupný" objekt poskytnutý objektem COM nebo samotným objektem. Zástupný procedura přijímá vzdálené volání procedur (nebo jiný komunikační mechanismus v případě vlastních vygenerovaných proxy serverů) z "proxy" v procesu klienta, odhaluje parametry a volá příslušné rozhraní na objektu serveru. Z pohledu klientů i serverů vždy komunikují přímo s nějakým jiným kódem v procesu.
COM poskytuje provádění zařazování, označované jako standardní zařazování. Tato implementace funguje velmi dobře pro většinu objektů a výrazně snižuje požadavky na programování a efektivně zprůhledňuje proces zařazování.
Jasné oddělení rozhraní od implementace transparentnosti procesů modelu COM však může v některých situacích nastat. Návrh rozhraní, které se zaměřuje na jeho funkci z pohledu klienta, může někdy vést k rozhodnutí o návrhu, která jsou v konfliktu s efektivní implementací tohoto rozhraní v síti. V takových případech, co je potřeba, není čistá transparentnost procesů, ale "transparentnost procesů, pokud nepotřebujete péči." Com poskytuje tuto funkci tím, že implementátor objektů umožňuje podporovat vlastní zařazování (označované také jako IMarshal zařazování). Standardní zařazování je ve skutečnosti instancí vlastního zařazování; jedná se o výchozí implementaci použitou v případech, kdy objekt nevyžaduje vlastní zařazování.
Můžete implementovat vlastní zařazování, které objektu umožní provádět různé akce při použití z celé sítě, než provádí v rámci místního přístupu, a je zcela transparentní pro klienta. Tato architektura umožňuje navrhovat klientská/objektová rozhraní bez ohledu na problémy s výkonem sítě a poté později řešit problémy s výkonem sítě bez narušení zavedeného návrhu.
COM neuvádí, jak jsou součásti strukturovány; určuje způsob interakce. Com opouští obavy o vnitřní strukturu komponenty programovacím jazykům a vývojovým prostředím. Naopak programovací prostředí nemají žádné nastavené standardy pro práci s objekty mimo okamžitou aplikaci. Například Microsoft Visual C++, funguje velmi dobře pro manipulaci s objekty uvnitř aplikace, ale nemá žádnou podporu pro práci s objekty mimo aplikaci. Obecně platí, že všechny ostatní programovací jazyky jsou v tomto ohledu stejné. Z toho důvodu, aby se zajistila interoperabilita modelu COM pro celou síť prostřednictvím jazykově nezávislých rozhraní, převezme, kde programovací jazyky opustí.
Dvojitá nepřímí struktura vtbl znamená, že ukazatele v tabulce ukazatelů funkce nemusí odkazovat přímo na skutečnou implementaci v reálném objektu. Toto je jádro transparentnosti procesů.
U procesových serverů, kde je objekt načten přímo do procesu klienta, ukazatele funkce v tabulce přímo na skutečnou implementaci. V tomto případě volání funkce z klienta do metody rozhraní přímo přenese řízení provádění do metody. To však nemůže fungovat pro místní objekty, ale i pro vzdálené objekty, protože ukazatele na paměť nelze sdílet mezi procesy. Klient však musí být schopen volat metody rozhraní, jako by volal skutečnou implementaci. Klient tedy jednotně přenese řízení na metodu v určitém objektu voláním.
Klient vždy volá metody rozhraní v některém objektu v procesu. Pokud je skutečný objekt místní nebo vzdálený, volání se provede na objekt proxy, který pak provede vzdálené volání procedury skutečného objektu.
Jaká metoda je tedy skutečně spuštěna? Odpovědí je, že pokaždé, když je volání rozhraní mimo proces, každá metoda rozhraní je implementována objektem proxy. Proxy objekt je vždy objekt v procesu, který funguje jménem volaného objektu. Tento proxy objekt ví, že skutečný objekt běží na místním nebo vzdáleném serveru.
Proxy objekt zabalí parametry funkce v některých datových paketech a vygeneruje volání RPC místnímu nebo vzdálenému objektu. Tento paket je vyzvednut objektem zástupných procedur v procesu serveru v místním nebo vzdáleném počítači, který rozbalí parametry a provede volání skutečné implementace metody. Když tato funkce vrátí, zabalí zástupný procedura všechny výstupní parametry a návratovou hodnotu a odešle ji zpět do proxy serveru, který je rozbalí a vrátí je původnímu klientovi.
Klient a server si tedy vždy vzájemně komunikují, jako by vše proběhlo v procesu. Všechna volání z klienta a všechna volání na server jsou v určitém okamžiku v procesu. Vzhledem k tomu, že struktura vtbl umožňuje některým agentům, jako je com, zachytit všechna volání funkcí a všechny návraty z funkcí, může agent podle potřeby přesměrovat tato volání na volání RPC. I když jsou volání v procesu rychlejší než volání mimo proces, rozdíly mezi procesy jsou pro klienta a server zcela transparentní.
Další informace najdete v následujících tématech:
Související témata