DCOM (Distributed Component Object Model) and CORBA (Common Object Request Broker Architecture) are two popular distributed object models. In this paper, we make architectural comparison of DCOM and CORBA at three different layers: basic programming architecture, remoting architecture, and the wire protocol architecture. A step-by-step description of remote object activation and method invocation is provided to demonstrate the similarities and differences of the two frameworks. A primary goal is for people who are already familiar with one model to quickly understand the basic architecture of the other.
1. Introduction
The explosive growth of the Web, the increasing popularity of PCs and the advances in high-speed network access have brought distributed computing into the main stream. To simplify network programming and to realize component-based software architecture, two distributed object models have emerged as standards, namely, DCOM (Distributed Component Object Model) and CORBA (Common Object Request Broker Architecture).
DCOM is the distributed extension to COM (Component Object Model) [COM 95] that builds an object remote procedure call (ORPC) layer on top of DCE RPC [DCE 95] to support remote objects. A COM server can create object instances of multiple object classes. A COM object can support multiple interfaces, each representing a different view or behavior of the object. An interface consists of a set of functionally related methods. A COM client interacts with a COM object by acquiring a pointer to one of the object's interfaces and invoking methods through that pointer, as if the object resides in the client's address space. COM specifies that any interface must follow a standard memory layout, which is the same as the C++ virtual function table [Rogerson 96]. Since the specification is at the binary level, it allows integration of binary components possibly written in different programming languages such as C++, Java and Visual Basic.
CORBA is a distributed object framework proposed by a consortium of 700+ companies called the Object Management Group (OMG) [CORBA 95]. The core of the CORBA architecture is the Object Request Broker (ORB) that acts as the object bus over which objects transparently interact with other objects located locally or remotely [Vinoski 97]. A CORBA object is represented to the outside world by an interface with a set of methods. A particular instance of an object is identified by an object reference. The client of a CORBA object acquires its object reference and uses it as a handle to make method calls, as if the object is located in the client's address space. The ORB is responsible for all the mechanisms required to find the object's implementation, prepare it to receive the request, communicate the request to it, and carry the reply (if any) back to the client. The object implementation interacts with the ORB through either an Object Adapter (OA) or through the ORB interface.
The following terminology will be used to refer to the entities in both frameworks.
- Interface
- A named collection of abstract operations (or methods) that represent one functionality.
- Object class (or class)
- A named concrete implementation of one or more interfaces.
- Object (or object instance)
- An instantiation of some object class.
- Object server
- A process responsible for creating and hosting object instances.
- Client
- A process that invokes a method of an object.
Both DCOM and CORBA frameworks provide client-server type of communications. To request a service, a client invokes a method implemented by a remote object, which acts as the server in the client-server model. The service provided by the server is encapsulated as an object and the interface of an object is described in an Interface Definition Language (IDL). The interfaces defined in an IDL file serve as a contract between a server and its clients. Clients interact with a server by invoking methods described in the IDL. The actual object implementation is hidden from the client. Some object-oriented programming features are present at the IDL level, such as data encapsulation, polymorphism and single inheritance. CORBA also supports multiple inheritance at the IDL level, but DCOM does not. Instead, the notion of an object having multiple interfaces is used to achieve a similar purpose in DCOM. CORBA IDL can also specify exceptions.
In both DCOM and CORBA, the interactions between a client process and an object server are implemented as object-oriented RPC-style communications [Birrell 84]. Figure 1 shows a typical RPC structure. To invoke a remote function, the client makes a call to the client stub. The stub packs the call parameters into a request message, and invokes a wire protocol to ship the message to the server. At the server side, the wire protocol delivers the message to the server stub, which then unpacks the request message and calls the actual function on the object. In DCOM, the client stub is referred to as the proxy and the server stub is referred to as the stub. In contrast, the client stub in CORBA is called the stub and the server stub is called the skeleton. Sometimes, the term "proxy" is also used to refer to a running instance of the stub in CORBA.
The overall architectures of DCOM and CORBA are illustrated in Figure 2 and Figure 3, respectively. In the following sections, we describe a single example implemented in both DCOM and CORBA, and provide a step-by-step description of object activations and method invocations at the three different layers shown in the figures. The top layer is the basic programming architecture, which is visible to the developers of the client and object server programs. The middle layer is the remoting architecture, which transparently makes the interface pointers or object references meaningful across different processes. The bottom layer is the wire protocol architecture, which further extends the remoting architecture to work across different machines.
Throughout this paper, the description about DCOM is based on the COM specification [COM 95] and the DCOM specification [Brown 96]. The CORBA description is based on the CORBA specification [CORBA 95] whenever possible. For information not specified by CORBA, we use Iona Orbix [Iona 95] implementation to complete the description.
2. Sample Application
We use an example called Grid throughout this paper. The Grid server object maintains a two-dimensional grid of integers and supports two groups of methods. The first group consists of two methods: get() and set(), which are invoked to get and set the value at a particular grid point, respectively. The second group has only one method: reset(), which sets the value at every grid point to the supplied value. As a simple demonstration, the Grid client first invokes the get() method to obtain the value at coordinate (0,0), increases the value by one, and then calls reset() to set the entire grid to the new value.
We design the DCOM and CORBA implementations in different ways to demonstrate that DCOM supports objects with multiple interfaces, while CORBA allows an interface to inherit from multiple interfaces. Note that DCOM and CORBA are basically oblivious to the inheritance relationship between the C++ implementation classes.
In CORBA, we define three interfaces: (1) interface grid1 supports get() and set(); (2) interface grid2 supports reset(); (3) interface grid multiply inherits from grid1 and grid2. In contrast, we define two interfaces in DCOM, IGrid1 and IGrid2, for the two groups of methods. The implementation of the Grid object uses multiple inheritance from IGrid1 and IGrid2 to implement an object with the two interfaces. Note that we could have merged all three methods into one interface by using interface single inheritance, which then looks very similar to its CORBA counterpart. But DCOM's support for objects with multiple interfaces allows each distinct feature of an object to have a separate interface.
For each implementation, we list the source code from five files. To simplify presentation, only essential code is shown. The first file, shown in Table 1, is the IDL file that defines the interfaces and its methods. The DCOM IDL file also associates multiple interfaces with an object class, as shown in the coclass block. Running the IDL file through an IDL compiler in both DCOM and CORBA generates the proxy/stub/skeleton code and the interface header file (grid.h or grid.hh) that are used by both the server and the client. Note that, in DCOM, each interface is assigned a globally unique identifier (GUID) called the interface ID (IID). Similarly, each object class is assigned a unique class ID (CLSID). Also, every COM interface must inherit from the IUnknown interface that consists of a QueryInterface() method for navigating between different interfaces of the same object, and two other methods AddRef() and Release() for reference counting. Reference counting provides a lifetime control mechanism that allows a COM object to keep track of its clients and can delete itself when it is no longer needed.
The second file shown in Table 2 is the implementation header file that shows how the server implementation class is derived from the interfaces. The DCOM file includes the definition of a class factory CClassFactory, which is commonly used but not required. As mentioned previously, the implementation class CGrid multiply inherits from the two pure abstract base classes IGrid1 and IGrid2 which are defined in the IDL-generated interface header file grid.h (not shown). In the CGrid class, AddRef() increments the reference count and Release() decrements it. When the reference count drops to zero, the server object deletes itself. Again, this is commonly used but not required. Ultimately, it is the server object itself which controls its own life time.
In the CORBA implementation, the IDL compiler generates from the interface definition the interface class grid in the header file grid.hh(not shown). The application developer writes the implementation class grid_i. There are two ways of associating the implementation class with the interface class - the inheritance approach and the delegation approach. In this example, we chose the inheritance approach. In this approach, the IDL compiler in Orbix also generates a class called gridBOAImpl that is responsible for instantiating the skeleton class. Class gridBOAImpl inherits from the interface class grid, which inherits from class CORBA::Object. The implementation class grid_i inherits from class gridBOAImpl to complete the mapping between the interface class and the implementation class. Note that the type gridBOAImpl is Orbix specific, since current CORBA do not specify what the skeleton class looks like and what the name of the base class is. This makes the server code not portable to other ORB products. To resolve this issue, Portable Object Adaptor (POA) was recently introduced [POA 97]. POA corrects this problem and specifies the name for the base class. In this example, when POA becomes available, the class grid_i would inherit from a base class called POA_grid. More descriptions of POA are given in Section 4.
The third file shown in Table 3 implements the methods of the server class. The DCOM file also implements some methods of the class factory. The fourth file shown in Table 4 is the main program for the server. The DCOM program creates an event and waits on that event which is signaled when all active server objects are deleted and so the server can exit. The actual client requests are handled concurrently by different threads from a thread pool. (Another DCOM threading model handles requests serially using one thread.)
Similarly, the CORBA server program instantiates an instance of class grid_i and then blocks at impl_is_ready() to receive the incoming client requests. If the server does not receive any requests during a default timeout period (which can be set by the programmer), it gracefully closes down. The client requests are handled either serially or by different threads, depending on the activation policy used for the object server. The last file shown in Table 5 is the client code. The readers may observe that DCOM client code tends to be longer than CORBA client code due to the additional IUnknown method calls. This may not be true for DCOM clients written in Java or Visual Basic, where the virtual machine layer takes care of the IUnknown method calls and hides them from the programmers [Chappell 97]. Even in a C++ client, smart interface pointers can be used to hide the reference counting [Rogerson 96].
After compiling and before executing the programs, both DCOM and CORBA require a registration process for the server. In CORBA, the association between the interface name and the path name of the server executable is registered with the implementation repository. In DCOM, the association between the CLSID and the path name of the server executable is registered with the registry. In addition, since a DCOM interface proxy/stub is itself a COM object, its associated server (in the dynamic link library (DLL) form) also needs to be similarly registered.
Due to space limitation, we do not cover dynamic invocation, which does not require static type information at compile time. In DCOM, type information for interface methods is stored in a type library generated by the IDL compiler and assigned a GUID. It can be used through the IDispatch interface to perform dynamic invocation [Rogerson 96]. It can also be used for type library-driven marshaling [Grimes 97]: instead of using a separate proxy/stub DLL that contains information specific to an interface, a generic marshaler can perform marshaling by reading type library information. In CORBA, the IDL compiler generates the type information for each method in an interface and stores it in the Interface Repository (IR). A client can query the interface repository to get run-time information about a particular interface and then use that information to create and invoke a method on the object dynamically through the dynamic invocation interface (DII). Similarly, on the server side, the dynamic skeleton interface (DSI) allows a client to invoke an operation on an object that has no compile time knowledge of the type of object it is implementing [CORBA 95].
Although Table 6 gives a common DCOM invocation sequence, we would
like to point out two things. First, the use of class factories in
COM is optional. A server object can actually call
CoRegisterClassObject() to register any interface pointer,
and clients can invoke another COM API named
CoGetClassObject() to retrieve that pointer.
(A class object is a named singleton object that acts as the
metaclass for a COM object class.)
Second, CoCreateInstance() does not necessarily create a fresh
instance. Inside IClassFactory::CreateInstance(), a server
can choose to always return the same interface pointer so that
different clients can connect to the same object instance with a
particular state.
Another way of binding to a named server object
instance is to use monikers [Box2 97]
and/or the Running Object Table (ROT) [COM
95].
In CORBA, an object can be activated by invoking any method
on an existing object reference. Some vendors provide special method
calls, e.g. _bind() operation in Orbix, to activate a server
object and obtain its object reference. The client may attach to an
existing instance instead of a new instance, if there is any existing
instance matching the requested type. Note that a client can store an
object reference by stringifying it using object_to_string()
and can later use it again by converting it back by
string_to_object().
Another difference to note between DCOM and CORBA at the programming
layer is the way they perform exception handling.
CORBA provides support for standard C++ exceptions and
some CORBA specific exceptions. In addition, user defined exceptions
are also allowed and are declared in the IDL. The IDL compiler maps a
user defined exception to a C++ class.
In contrast, DCOM requires that all methods return a 32-bit error code
called an HRESULT (see Table 3) at this layer.
At the language/tool level, a set of conventions and system provided services
(called the IErrorInfo object) allows failure HRESULTs to be
converted into exceptions in a way natural to the language. For example,
in Microsoft Visual C++ 5.0, client programmers can use standard C++ try/catch
blocks to catch errors from COM method invocations; the compiler generates the
correct code to map the failure HRESULT into a correct usage of
IErrorInfo, effectively translating the failure return code into
an exception.
Similarly, tools can allow programmers to "throw exceptions" instead of
returning failure codes.
The DCOM wire protocol includes a mechanism known as body extensions
[Brown 96]
that allow rich exception information (such as a string explaining the error)
to be carried.
To send data across different address spaces requires a process called
marshaling and unmarshaling.
Marshaling packs
a method call's parameters (at a client's space) or
return values (at a server's space) into a standard format for transmission.
Unmarshaling, the reverse operation,
unpacks the standard format to an appropriate
data presentation in the address space of a receiving process.
Note that the marshaling process described in
this section is called standard marshaling in DCOM terminology.
DCOM also provides a custom marshaling mechanism to bypass the
standard marshaling procedure [Brockschmidt 93]
[COM 95]
[Box1 97].
By implementing an IMarshal interface, a server object declares
that it wants to control how and what data are marshaled and unmarshaled,
and how the client should communicate with the server.
In effect, custom marshaling provides an extensible architecture for
plugging in application-specific communication infrastructure.
It can be useful for client-side data caching, for fault tolerance, etc.
We describe here some of the additional CORBA terms used in Table 7.
As stated in the Introduction, the ORB acts as the object bus.
The Object Adaptor (OA) sits on top of the
ORB, and is responsible for connecting the object implementation to
the ORB. Object Adaptors provide services like generation and
interpretation of object references, method invocation, object
activation and deactivation, mapping object references to
implementations. Different object implementation styles have
different requirements and need to be supported by different object
adapters, e.g. object-oriented database adapter for objects in a
database. The Basic Object Adapter (BOA) defines an object adapter
which can be used for most conventional object implementations. CORBA
specifications do not mandate how the ORB/BOA functionality is to be
implemented. Orbix built the ORB/BOA
functionality into two libraries and a daemon process
(orbixd). The daemon is responsible for location and
activation of objects. The two libraries, a server-side library and a
client-side library, are each linked at compile time with server and
client implementations, respectively, to provide the rest of the
functionality [Orbix 96].
It is important to note that the recently introduced POA will
be a replacement for BOA. The POA specifications
provide portability for CORBA server code and also introduce some new
features in the Object Adapter. The POA specifications have not yet
been incorporated by any ORB vendors into the products.
Thus, our descriptions
are based on the current products which implements the BOA specifications.
However, wherever we discuss BOA specific
details we will point out the approach taken by POA in that context.
The bottom layer specifies the wire protocol for supporting the
client and the server running on different machines. The description
in Table 8 shows how objects on a remote machine
are created and describes the entities involved when a method
invocation is carried out across machines. Figure 8 and Figure
9 illustrate the steps for DCOM and CORBA, respectively. The main
difference between DCOM and CORBA at this layer include how remote
interface pointers or object references are represented to convey the
server endpoint information to the client, and the standard format in
which the data is marshaled for transmission in a heterogeneous
environment. Note that CORBA does not specify a protocol for
communication between a client and an object server running on ORBs
provided by the same vendor. The protocol for inter-ORB communication
between the same vendor ORBs is vendor dependent. However, in order to
support the interoperability of different ORB products, a General
Inter-ORB Protocol (GIOP) is specified. A specific mapping of the
GIOP on TCP/IP connections is defined, and known as the Internet
Inter-ORB Protocol (IIOP). For CORBA, we include the descriptions for
both IIOP and the Orbix implementation.
DCOM wire protocol is mostly based on OSF DCE RPC specification
[DCE 95], with a few extensions.
That includes remote object reference representation, an IRemUnknown
interface for optimizing the performance of remote IUnknown
method calls, and a pinging protocol
[Brown 96].
Pinging allows a server object to garbage-collect remote
object references when a remote client abnormally terminates. When a
client obtains an interface pointer to a remote object for the first
time, the ping client code (see Figure 2) on
the client machine adds the object to a ping set and periodically
sends a ping to the server machine to let it know that the client is
still alive. Missing a predetermined number of consecutive pings
indicates that the client has abnormally terminated and the interface
pointers that it holds can be released. To optimize performance,
pings are sent on a per-machine basis and in an incremental way. They
can also be piggy-backed on normal messages. Whenever necessary, the
ping functionality can also be turned off to reduce network traffic.
The three-layer step-by-step descript
DCOM IDL CORBA IDL
// uuid and definition of IGrid1
[ object,
uuid(3CFDB283-CCC5-11D0-BA0B-00A0C90DF8BC),
helpstring("IGrid1 Interface"),
pointer_default(unique)
]
interface IGrid1 : IUnknown {
import "unknwn.idl";
HRESULT get([in] SHORT n, [in] SHORT m, [out] LONG *value);
HRESULT set([in] SHORT n, [in] SHORT m, [in] LONG value);
};
// uuid and definition of IGrid2
[ object,
uuid(3CFDB284-CCC5-11D0-BA0B-00A0C90DF8BC),
helpstring("IGrid2 Interface"),
pointer_default(unique)
]
interface IGrid2 : IUnknown {
import "unknwn.idl";
HRESULT reset([in] LONG value);
};
// uuid and definition of type library
[ uuid(3CFDB281-CCC5-11D0-BA0B-00A0C90DF8BC),
version(1.0),
helpstring("grid 1.0 Type Library)
]
library GRIDLib
{
importlib("stdole32.tlb");
// uuid and definition of class
[ uuid(3CFDB287-CCC5-11D0-BA0B-00A0C90DF8BC),
helpstring("Grid Class")
]
// multiple interfaces
coclass CGrid
{ [default] interface IGrid1;
interface IGrid2;
};
};
interface grid1
{
long get(in short n, in short m);
void set(in short n, in short m, in long value);
};
interface grid2
{
void reset(in long value);
};
// multiple inheritance of interfaces
interface grid: grid1, grid2
{
};
Table 1: The IDL files.
DCOM server class definition (cgrid.h) CORBA server class definition (grid_i.h)
#include "grid.h" // IDL-generated interface header file
class CClassFactory : public IClassFactory {
public:
// IUnknown
STDMETHODIMP QueryInterface(REFIID riid, void** ppv);
STDMETHODIMP_(ULONG) AddRef(void) { return 1; };
STDMETHODIMP_(ULONG) Release(void) { return 1; }
// IClassFactory
STDMETHODIMP CreateInstance(LPUNKNOWN punkOuter,
REFIID iid, void **ppv);
STDMETHODIMP LockServer(BOOL fLock)
{ return E_FAIL; };
};
class CGrid : public IGrid1, public IGrid2 {
public:
// IUnknown
STDMETHODIMP QueryInterface(REFIID riid, void** ppv);
STDMETHODIMP_(ULONG) AddRef(void)
{ return InterlockedIncrement(&m_cRef); }
STDMETHODIMP_(ULONG) Release(void)
{ if (InterlockedDecrement(&m_cRef) == 0)
{ delete this; return 0; }
return 1; }
// IGrid1
STDMETHODIMP get(IN SHORT n, IN SHORT m,
OUT LONG *value);
STDMETHODIMP set(IN SHORT n, IN SHORT m,
IN LONG value);
// IGrid2
STDMETHODIMP reset(IN LONG value);
CGrid(SHORT h, SHORT w);
~CGrid();
private:
LONG m_cRef, **m_a;
SHORT m_height, m_width;
};
#include "grid.hh" // IDL-generated interface header file
class grid_i : public gridBOAImpl {
public:
virtual CORBA::Long get(CORBA::Short n, CORBA::Short m,
CORBA::Environment &env);
virtual void set(CORBA::Short n, CORBA::Short m,
CORBA::Long value, CORBA::Environment &env);
virtual void reset(CORBA::Long value,
CORBA::Environment &env);
grid_i(CORBA::Short h, CORBA::Short w);
virtual ~grid_i();
private:
CORBA::Long **m_a;
CORBA::Short m_height, m_width;
};
Table 2: The server implementation header files.
DCOM server implementation CORBA server implementation
#include "cgrid.h"
STDMETHODIMP CClassFactory::QueryInterface(REFIID riid, void** ppv) {
if (riid == IID_IClassFactory || riid == IID_IUnknown) {
*ppv = (IClassFactory *) this;
AddRef(); return S_OK;
}
*ppv = NULL;
return E_NOINTERFACE;
}
STDMETHODIMP
CClassFactory::CreateInstance(LPUNKNOWN p, REFIID riid, void** ppv) {
IGrid1* punk = (IGrid1*) new CGrid(100, 100);
HRESULT hr = punk->QueryInterface(riid, ppv);
punk->Release();
return hr;
}
STDMETHODIMP CGrid::QueryInterface(REFIID riid, void** ppv) {
if (riid == IID_IUnknown || riid == IID_IGrid1)
*ppv = (IGrid1*) this;
else if (riid == IID_IGrid2) *ppv = (IGrid2*) this;
else { *ppv = NULL; return E_NOINTERFACE; }
AddRef(); return S_OK;
}
STDMETHODIMP CGrid::get(IN SHORT n, IN SHORT m, OUT LONG* value) {
*value = m_a[n][m];
return S_OK;
}
STDMETHODIMP CGrid::set(IN SHORT n, IN SHORT m, IN LONG value) {
m_a[n][m] = value;
return S_OK;
}
STDMETHODIMP CGrid::reset(IN LONG value) {
SHORT n, m;
for (n=0; n < m_height; n++)
for (m=0; m < m_width; m++)
m_a[n][m] = value;
return S_OK;
}
CGrid::CGrid(SHORT h, SHORT w) {
m_height = h;
m_width= w;
m_a = new LONG*[m_height];
for (int i=0; i < m_height; i++)
m_a[i] = new LONG[m_width];
m_cRef = 1;
}
extern HANDLE hevtDone;
CGrid::~CGrid () {
for (int i=0; i < m_height; i++)
delete[] m_a[i];
delete[] m_a;
SetEvent(hevtDone);
}
#include "grid_i.h"
CORBA::Long grid_i::get(CORBA::Short n, CORBA::Short m,
CORBA::Environment &) {
return m_a[n][m];
}
void grid_i::set(CORBA::Short n, CORBA::Short m,
CORBA::Long value, CORBA::Environment &) {
m_a[n][m] = value;
}
void grid_i::reset(CORBA::Long value, CORBA::Environment &) {
short n, m;
for (n = 0; n < m_height; n++)
for (m = 0; m < m_width; m++)
m_a[n][m]=value;
return;
}
grid_i::grid_i(CORBA::Short h, CORBA::Short w) {
m_height=h; // set up height
m_width=w; // set up width
m_a = new CORBA::Long* [h];
for (int i = 0; i < h; i++ )
m_a[i] = new CORBA::Long[w];
}
grid_i::~grid_i () {
for (int i = 0; i < m_height; i++)
delete[] m_a[i];
delete[] m_a;
}
Table 3: The server implementation files.
DCOM server main program CORBA server main program
HANDLE hevtDone;
void main()
{
// Event used to signal this main thread
hevtDone = CreateEvent(NULL, FALSE, FALSE, NULL);
hr = CoInitializeEx(NULL, COINIT_MULTITHREADED);
CClassFactory* pcf = new CClassFactory;
hr = CoRegisterClassObject(CLSID_CGrid, pcf,
CLSCTX_SERVER, REGCLS_MULTIPLEUSE , &dwRegister);
// Wait until the event is set by CGrid::~CGrid()
WaitForSingleObject(hevtDone, INFINITE);
CloseHandle(hevtDone);
CoUninitialize();
}
int main()
{
// create a grid object using the implementation class grid_i
grid_i ourGrid(100,100);
try {
// tell Orbix that we have completed the server's initialization:
CORBA::Orbix.impl_is_ready("grid");
} catch (...) {
cout << "Unexpected exception" << endl;
exit(1);
}
}
Table 4: The server main programs.
DCOM Client code CORBA Client code
#include "grid.h"
void main(int argc, char**argv)
{
IGrid1 *pIGrid1;
IGrid2 *pIGrid2;
LONG value;
CoInitialize(NULL); // initialize COM
CoCreateInstance(CLSID_CGrid, NULL, CLSCTX_SERVER,
IID_IGrid1, (void**) &pIGrid1);
pIGrid1->get(0, 0, &value);
pIGrid1->QueryInterface(IID_IGrid2, (void**) &pIGrid2);
pIGrid1->Release();
pIGrid2->reset(value+1);
pIGrid2->Release();
CoUninitialize();
}
#include "grid.hh"
void main (int argc, char **argv)
{
grid_var gridVar;
CORBA::Long value;
// bind to "grid" object; Orbix-specific
gridVar = grid::_bind(":grid");
value = gridVar->get(0, 0);
gridVar->reset(value+1);
}
Table 5: The client main programs.
3. Top Layer: Basic Programming Architecture
At the top layer, we show the programmers' view of DCOM and CORBA.
More specifically, we describe how a client requests an object and
invokes its methods, and how a server creates an object instance and
makes it available to the client. Exactly how the client is connected
to the server is totally hidden from the programmers. The client and
the server programs interact as if they reside in the same address
space on the same machine. The main differences between DCOM and
CORBA at this layer include how a client specifies an interface
and COM's class factories and the IUnknown methods.
A step-by-step description is given in Table 6
and illustrated in Figure 4 and
Figure 5 for DCOM and CORBA, respectively.
(Numbers in parenthesis are for object activation steps; those in square
brackets are for method invocation steps.)
DCOM CORBA Object activation
Method invocation
Table 6: The top layer description.
Footnote 1:
For performance reason, Release() calls for individual
interfaces may not be actually forwarded to the server side until all interface
pointers that a client holds to the same object are all released. This allows
caching interface pointers that may be requested again by the client, and
allows lower layers to bundle multiple Release() calls in a single
remote call.
4. Middle Layer: Remoting Architecture
The middle layer consists of the infrastructure necessary for
providing the client and the server with the illusion that they are in
the same address space. The description in Table 7
shows how the infrastructure locates and starts the requested
server, and the entities involved when a method invocation takes place
across different processes.
The corresponding illustrations for DCOM and CORBA are shown in
Figure 6 and Figure 7,
respectively.
The main differences between DCOM and
CORBA at this layer include how server objects are registered and
when proxy/stub/skeleton instances are created.
DCOM CORBA Object activation
Method Invocation:
Table 7: The middle layer description.
Footnote 2: The stub actually checks its
proxy object table
first to see if it already has an object reference for grid.
The proxy object table maintains a run-time table of all valid
object references on the client side.
5. Bottom Layer: Wire Protocol Architecture
DCOM CORBA Object activation
Method invocation
Table 8: The bottom layer description.
Footnote 4:
There is one OXID object per object exporter. Each OXID object
supports an IRemUnknown interface consisting of three methods:
RemQueryInterface(), RemAddRef(), and RemRelease().
These methods allow multiple remote IUnknown method calls destined for
the same object exporter to be bundled to improve performance. All such calls
are first handled by the OXID object, and then forwarded to the target
interface. Note that these and other bottom-layer APIs are essentially
implementation details. Application programmers will not encounter them.
6. Summary