Although we feel that the most
significant difference between DCE and CORBA is in the style of
programming each is intended to support, there are inevitable differences between the individual
capabilities they provide. For example:
DCE
supports several useful datatypes that CORBA does not support:
A
varying array in DCE is an array of fixed size, of which only part is passed between client and server;
however, the entire array is allocated at the server, which may return more array elements than were
passed to it. CORBA has no equivalent datatype; however, equivalent behavior may be obtained using
a CORBA sequence.
DCE
pipes permit very large parameter values to be passed in a series of smaller blocks so that data
transmission and processing may be pipelined.
CORBA
supports no corresponding mechanism for dealing with very large parameter values; the
programmer can implement pipelining only by breaking up what might be a single operation
conceptually into a series of operations.
DCE
supports contexts, which are a mechanism for maintaining server state during a series of logically
related requests from a single client. (For example, the client might be issuing a series of RPCs to
retrieve
a set of records from a database one at a time.) The server state is passed to the client as an opaque
context structure; the client includes the context in subsequent RPCs, and the server uses and modifies
the state information in the context, as appropriate. DCE provides support for contexts directly in
client
and server stubs. CORBA has no corresponding mechanism; the programmer is responsible for
managing contextual information explicitly. (It should be noted that DCE contexts have no relationship
to CORBA contexts, which are used to carry user preferences along with a request to an object.)
DCE
fully supports the use of pointers as, and within, operation parameters. An operation that is
defined in DCE IDL may take a pointer as a parameter. Of course, such a parameter is not actually
passed beween a DCE client and server as an address, which is generally not meaningful in a distributed
environment. The DCE run-time system packages up the value the address points to as part of the
process of marshalling the request in preparation for transmission to the server. Furthermore, if a
parameter is a complex structure that contains pointers, the DCE run-time system will package up all
of
the values addressed by those pointers during marshalling, transmit them to the server, and reconstitute
the complex parameter with pointers in the server.
CORBA
does not support the use of pointers as, or within, operation parameters. The set of CORBA
IDL basic datatypes and constructs for building complex datatypes do not include pointers (although
they may be implemented using pointers). This means that a programmer may pass complex structures
that contain pointers as operation parameters in two ways. The programmer may write additional code
to
marshall the actual values addressed by pointers into pointer-free datatypes in the client and then
reconstitute the complex parameter with pointers in the server. Alternatively, the programmer may
redefine the complex data structure as a collection of one or more objects, since CORBA does support
complex structures composed of objects.
CORBA
supports an „any data type that DCE does not support. This permits a value of an arbitrary
type to be passed between a client and server. The value carries with it a code that indicates its type.
DCE
IDL does not support interface inheritance and defines a flat namespace. CORBA IDL supports
multiple inheritance and defines a hierarchical namespace.
CORBA
defines an Interface Repository that contains information equivalent to that in IDL files and can
be queried at runtime. DCE defines no such repository.
In
addition to a static (stub) interface, CORBA defines a dynamic invocation interface that can be used
by a client to invoke an arbitrary operation on an arbitrary object type at runtime (supporting the
late
binding of operation invocations to function calls). DCE defines no such invocation mechanism - the
appropriate RPC stubs must be linked into a DCE client.
DCE servers must be brought up
by means external to DCE. CORBA also supports automatic server
activation (in other words, an ORB will bring up a server if it is not up when a request is directed
to it). The
services that DCE provides to an application are rather limited compared to the components of the CORBA
architecture, which covers a much broader spectrum of application support services and provides the
developer with a much richer set of capabilities on which to build.