Inter-Object kommunikation
COM är utformat för att tillåta klienter att kommunicera transparent med objekt, oavsett var objekten körs – i samma process, på samma dator eller på en annan dator. Detta ger en enda programmeringsmodell för alla typer av objekt och för både objektklienter och objektservrar.
Från en klients synvinkel nås alla objekt via gränssnittspekare. En pekare måste vara i processen. Faktum är att alla anrop till en gränssnittsfunktion alltid når någon del av den processbaserade koden först. Om objektet håller på att bearbetas når anropet det direkt, utan mellanliggande kod för systeminfrastruktur. Om objektet inte är bearbetat når anropet först det som kallas ett proxyobjekt som tillhandahålls antingen av COM eller av objektet (om implementorn vill). Proxypaketen anropar parametrar (inklusive eventuella gränssnittspekare) och genererar lämpligt fjärrproceduranrop (eller annan kommunikationsmekanism för anpassade genererade proxyservrar) till den andra processen eller den andra datorn där objektimplementeringen finns. Den här processen med paketeringspekare för överföring över processgränser kallas .
Från en servers synvinkel görs alla anrop till ett objekts gränssnittsfunktioner via en pekare till det gränssnittet. Återigen har en pekare bara kontext i en enda process, och anroparen måste alltid vara en del av den processbaserade koden. Om objektet håller på att bearbetas är anroparen själva klienten. Annars är anroparen ett "stub"-objekt som tillhandahålls antingen av COM eller av själva objektet. Stub tar emot fjärrproceduranropet (eller annan kommunikationsmekanism vid anpassade genererade proxyservrar) från "proxyn" i klientprocessen, avmarshalerar parametrarna och anropar lämpligt gränssnitt på serverobjektet. Från både klienters och servrars synvinkel kommunicerar de alltid direkt med någon annan processkod.
COM tillhandahåller en implementering av marskalkning, som kallas standardmarskalkning. Den här implementeringen fungerar mycket bra för de flesta objekt och minskar programmeringskraven avsevärt, vilket gör marskalkeringsprocessen effektivt transparent.
Den tydliga uppdelningen av gränssnittet från implementeringen av COM:s processtransparens kan dock komma i vägen i vissa situationer. Utformningen av ett gränssnitt som fokuserar på dess funktion från klientens synvinkel kan ibland leda till designbeslut som står i konflikt med effektiv implementering av gränssnittet i ett nätverk. I fall som detta är det som behövs inte ren processtransparens utan "processtransparens, om du inte behöver bry dig". COM tillhandahåller den här funktionen genom att tillåta att en objekt-implementor stöder anpassad (kallas även IMarshal marshaling). Standardmarskalkning är i själva verket en instans av anpassad marskalkering; det är standardimplementeringen som används när ett objekt inte kräver anpassad marshaling.
Du kan implementera anpassad marshaling för att tillåta att ett objekt vidtar olika åtgärder när det används från ett nätverk än det tar under lokal åtkomst och det är helt transparent för klienten. Den här arkitekturen gör det möjligt att utforma klient-/objektgränssnitt utan hänsyn till problem med nätverksprestanda och sedan senare åtgärda problem med nätverksprestanda utan att störa den etablerade designen.
COM anger inte hur komponenterna är strukturerade. den anger hur de interagerar. COM lämnar oron för den interna strukturen för en komponent för programmeringsspråk och utvecklingsmiljöer. Däremot har programmeringsmiljöer inga angivna standarder för att arbeta med objekt utanför det omedelbara programmet. Microsoft Visual C++, till exempel, fungerar mycket bra för att manipulera objekt i ett program men har inget stöd för att arbeta med objekt utanför programmet. I allmänhet är alla andra programmeringsspråk desamma i det här avseendet. För att tillhandahålla nätverksomfattande samverkan tar COM därför, via språkoberoende gränssnitt, upp där programmeringsspråken slutar fungera.
Den dubbla indirektionen av vtbl-strukturen innebär att pekarna i tabellen med funktionspekare inte behöver peka direkt på den verkliga implementeringen i det verkliga objektet. Detta är kärnan i processtransparensen.
För processerver, där objektet läses in direkt i klientprocessen, pekar funktionspekarna i tabellen direkt på den faktiska implementeringen. I det här fallet överför ett funktionsanrop från klienten till en gränssnittsmetod direkt körningskontrollen till metoden. Detta kan dock inte fungera för lokala, för att inte tala om fjärrobjekt, eftersom pekare till minne inte kan delas mellan processer. Klienten måste dock kunna anropa gränssnittsmetoder som om den anropade den faktiska implementeringen. Klienten överför därför kontrollen enhetligt till en metod i ett objekt genom att göra anropet.
En klient anropar alltid gränssnittsmetoder i vissa processobjekt. Om det faktiska objektet är lokalt eller fjärranslutet görs anropet till ett proxyobjekt, som sedan gör ett fjärrproceduranrop till det faktiska objektet.
Så vilken metod körs egentligen? Svaret är att varje gränssnittsmetod implementeras av ett proxyobjekt när det finns ett anrop till ett out-of-process-gränssnitt. Proxyobjektet är alltid ett processobjekt som fungerar för objektet som anropas. Det här proxyobjektet vet att det faktiska objektet körs på en lokal server eller fjärrserver.
Proxyobjektet paketar upp funktionsparametrarna i vissa datapaket och genererar ett RPC-anrop till det lokala objektet eller fjärrobjektet. Paketet hämtas av ett stub-objekt i serverns process på den lokala datorn eller en fjärrdator, som packar upp parametrarna och gör anropet till den verkliga implementeringen av metoden. När funktionen returneras paketerar stub-filen eventuella utparametrar och returvärdet och skickar tillbaka den till proxyn, som packar upp dem och returnerar dem till den ursprungliga klienten.
Därför pratar klient och server alltid med varandra som om allt var i processen. Alla anrop från klienten och alla anrop till servern pågår någon gång. Men eftersom vtbl-strukturen gör att vissa agenter, till exempel COM, kan avlyssna alla funktionsanrop och alla returer från funktioner, kan agenten omdirigera dessa anrop till ett RPC-anrop efter behov. Även om in-process-anrop är snabbare än out-of-process-anrop är processskillnaderna helt transparenta för klienten och servern.
Mer information finns i följande avsnitt:
Relaterade ämnen