Learning DCOM

Object Reference

We have already talked about the object reference (OBJREF) in Chapter 5, but we must review it to stress its importance here. Besides, the OBJREF is the magic that allows us to pass pointers to many places in the architecture that we’re about to build.

Let’s assume that you need to get an interface pointer from a server to a client component. When an interface pointer is passed from a server to a client, COM creates a stub and marshals the interface pointer into an OBJREF on the server side. In standard marshaling, the OBJREF contains all necessary information (e.g., OXID, OID, IPID, OXID Resolver Address, etc.) to uniquely locate an interface pointer in cyberspace. When a client receives the OBJREF, COM unmarshals it into an interface pointer that points to a local proxy on the client side. Any method invocation on the interface pointer in the client component will go through the local proxy, from the local proxy to the associated remote stub, and from the stub to the target object on the server side.

In our simple distributed chat system, a method call from the ChatClient should go back to the ChatServer that has registered its interface pointer against the ChatBroker. This is obvious—or is it?

As a developer, you don’t have to worry about this because it should just work as expected. The Distributed COM infrastructure should worry about this, which it does through a process known as OXID resolution. Specifically, an OXID Resolver is the agent that resolves OXID ...