Inter-Object Communicatie
COM is ontworpen om clients transparant te laten communiceren met objecten, ongeacht waar deze objecten worden uitgevoerd, in hetzelfde proces, op dezelfde computer of op een andere computer. Dit biedt één programmeermodel voor alle typen objecten en voor zowel objectclients als objectservers.
Vanuit het oogpunt van een client worden alle objecten geopend via interfaceaanwijzers. Er moet een aanwijzer worden verwerkt. In feite bereikt elke aanroep naar een interfacefunctie altijd eerst een stukje in-process code. Als het object in verwerking is, bereikt de aanroep het rechtstreeks, zonder tussenliggende systeeminfrastructuurcode. Als het object niet wordt verwerkt, bereikt de aanroep eerst een 'proxy'-object dat door COM of door het object wordt geleverd (indien de implementor dat wenst). De proxypakketten roepen parameters aan (inclusief interfacepointers) en genereren de juiste externe procedure-aanroep (of een ander communicatiemechanisme in het geval van aangepaste gegenereerde proxy's) naar het andere proces of de andere computer waarop de object-implementatie zich bevindt. Dit proces van verpakkingspunten voor transmissie over procesgrenzen wordt marshalinggenoemd.
Vanuit het oogpunt van een server worden alle aanroepen naar de interfacefuncties van een object uitgevoerd via een aanwijzer naar die interface. Nogmaals, een aanwijzer heeft slechts context in één proces en de aanroeper moet altijd een stukje in-procescode zijn. Als het object wordt verwerkt, is de aanroeper de client zelf. Anders is de aanroeper een stub-object dat door COM of door het object zelf wordt geleverd. De stub ontvangt de aanroep van de externe procedure (of een ander communicatiemechanisme in het geval van aangepaste gegenereerde proxy's) van de 'proxy' in het clientproces, unmarshals de parameters en roept de juiste interface op het serverobject aan. Vanuit het oogpunt van zowel clients als servers communiceren ze altijd rechtstreeks met een andere in-procescode.
COM biedt een implementatie van marshaling, ook wel standaard marshalinggenoemd. Deze implementatie werkt zeer goed voor de meeste objecten en vermindert de programmeervereisten aanzienlijk, waardoor het marshalingproces effectief transparant wordt.
De duidelijke scheiding van de interface van de tenuitvoerlegging van com-procestransparantie kan echter in sommige situaties op de weg komen. Het ontwerp van een interface die zich richt op de functie van de client kan soms leiden tot ontwerpbeslissingen die conflicteren met een efficiënte implementatie van die interface in een netwerk. In dergelijke gevallen is niet alleen pure procestransparantie nodig, maar 'procestransparantie, tenzij u zich zorgen hoeft te maken'. COM biedt deze mogelijkheid door een object implementor toe te staan aangepaste marshaling te ondersteunen (ook wel IMarshal marshaling genoemd). Standaard marshaling is in feite een exemplaar van aangepaste marshaling; dit is de standaard implementatie die wordt gebruikt wanneer een object geen aangepaste marshaling vereist.
U kunt aangepaste marshaling implementeren zodat een object verschillende acties kan ondernemen wanneer het wordt gebruikt vanuit een netwerk dan nodig is onder lokale toegang en het is volledig transparant voor de client. Deze architectuur maakt het mogelijk om client-/objectinterfaces te ontwerpen zonder rekening te houden met netwerkprestatieproblemen en later om netwerkprestaties op te lossen zonder het tot stand gebrachte ontwerp te verstoren.
COM geeft niet op hoe onderdelen zijn gestructureerd; het geeft aan hoe ze communiceren. COM maakt zich zorgen over de interne structuur van een onderdeel voor programmeertalen en ontwikkelomgevingen. Omgekeerd hebben programmeeromgevingen geen standaarden voor het werken met objecten buiten de directe toepassing. Microsoft Visual C++, bijvoorbeeld, werkt zeer goed voor het bewerken van objecten in een toepassing, maar biedt geen ondersteuning voor het werken met objecten buiten de toepassing. Over het algemeen zijn alle andere programmeertalen in dit opzicht hetzelfde. Om netwerkomvattende interoperabiliteit te bieden, wordt COM, via taalonafhankelijke interfaces, opgehaald waar programmeertalen weggaan.
De dubbele indirectie van de vtbl-structuur betekent dat de aanwijzers in de tabel met functiepunten niet rechtstreeks hoeven te verwijzen naar de werkelijke implementatie in het echte object. Dit is het hart van procestransparantie.
Voor in-process servers, waarbij het object rechtstreeks in het clientproces wordt geladen, verwijzen de functiepointers in de tabel rechtstreeks naar de werkelijke implementatie. In dit geval draagt een functieaanroep van de client naar een interfacemethode rechtstreeks uitvoeringsbeheer over naar de methode. Dit kan echter niet werken voor lokale, laat staan externe objecten, omdat aanwijzers naar geheugen niet kunnen worden gedeeld tussen processen. Toch moet de client interfacemethoden kunnen aanroepen alsof deze de daadwerkelijke implementatie aanroept. De client draagt dus de besturing uniform over naar een methode in een bepaald object door de aanroep te maken.
Een client roept interfacemethoden altijd aan in een in-process object. Als het werkelijke object lokaal of extern is, wordt de aanroep uitgevoerd naar een proxyobject, waardoor vervolgens een externe procedure-aanroep naar het werkelijke object wordt gedaan.
Welke methode wordt eigenlijk uitgevoerd? Het antwoord is dat wanneer er een aanroep naar een out-of-process interface is, elke interfacemethode wordt geïmplementeerd door een proxyobject. Het proxyobject is altijd een in-process-object dat namens het object fungeert dat wordt aangeroepen. Dit proxyobject weet dat het werkelijke object wordt uitgevoerd op een lokale of externe server.
Het proxyobject verpakt de functieparameters in sommige gegevenspakketten en genereert een RPC-aanroep naar het lokale of externe object. Dat pakket wordt opgehaald door een stub-object in het proces van de server op de lokale of externe computer, waarmee de parameters worden uitgepakt en de echte implementatie van de methode wordt aangeroepen. Wanneer deze functie wordt geretourneerd, verpakt de stub alle out-parameters en de retourwaarde en stuurt deze terug naar de proxy, die ze uitpakt en retourneert naar de oorspronkelijke client.
Client en server praten dus altijd met elkaar alsof alles in het proces was. Alle aanroepen van de client en alle aanroepen naar de server worden op een bepaald moment verwerkt. Maar omdat de vtbl-structuur sommige agent, zoals COM, alle functieaanroepen en alle retourneert van functies kan die agent deze aanroepen zo nodig omleiden naar een RPC-aanroep. Hoewel in-process-aanroepen sneller zijn dan out-of-process-aanroepen, zijn de procesverschillen volledig transparant voor de client en server.
Zie de volgende onderwerpen voor meer informatie:
Verwante onderwerpen