Comparison of DCOM and CORBA,
What are the Choices

 

 

                        Abstract:

DCOM (Distributed Component Object Model) and CORBA (Common Object Request Broker Architecture) technologies are often pitted against each other as competing component-based software architectures for creating distributed solutions. These two architectures introduced and enhanced over the last decade exhibit strengths and weaknesses based on their ability to meet the challenges of component packaging, cross-language interoperability, interprocess communications and intermachine communications. This paper discusses issues faced by developers considering either architecture.

 

 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
By: Paul Visokey

Email: [email protected]

URL: www.geocities.com/paulvisokey

Position: Vice President of Sales, US and Canada

Nuance Communications

March 27, 2000

 
 
 
 
 
Comparing Distributed Object Architectures

The DCOM (Distributed Component Object Model) and CORBA (Common Object Request Broker Architecture) technologies are often pitted against each other as competing component-based software architectures for creating distributed solutions. This paper will address the complexities of this simple comparison. These two architectures are intended to address the same goal of simplifying client/server application design. The explosive growth of the Web, the increasing popularity of PCs and advances in high-speed network access have brought distributed computing into the main stream with the result being heightened competition between the two main operating systems, Windows and UNIX, and between Microsoft and the consortium of vendors who created CORBA.

 

Microsoft’s Component Object Model

DCOM is a set of Microsoft concepts and program interfaces in which client program objects and server program objects can request services from server program objects on other computers in a network. More specifically, DCOM is a distributed extension to COM (Component Object Model) that builds an object remote procedure call (ORPC) layer on top of the DCE RPC architecture to support remote objects. For example, one can create a page for a Web site that contains a script or program that can be processed (before being sent to a requesting user) on another more specialized server in the network. Using DCOM interfaces, the Web server site program (now acting as a client object) can forward a Remote Procedure Call (RPC) to the specialized server object, which provides the necessary processing and returns the result to the Web server site. The Web server site passes the result to the Web page viewer.

 

Originally Microsoft evolved COM from its Object Linking and Embedding (OLE) technology in order to provide infrastructure for its vision of OLE. COM is an architecture that allows objects to cross language and process boundaries but not machine boundaries. In 1996 Microsoft released DCOM to allow distributed object functionality. Although Microsoft created COM and DCOM, and they come as part of Windows NT 4.0 and Windows 2000 and are available as a free upgrade to Windows 95/98, they are now the responsibility of the Active X Consortium. Full source code is licensable at no charge from The Open Group (formerly OSF and X/Open). Software AG has DCOM running on the Solaris-based operating system today. Even though Microsoft has attempted to distance itself from implications of proprietary control it is hard to minimize the importance of COM in the Microsoft environment. Introduced in 1993, COM underlies a large majority of the new code developed for Windows and Windows NT operating systems, whether created by Microsoft or others. From Microsoft’s promotional information, here are some claims:

COM is the dominant component architecture in use today.

 

The basic COM model allows flexible binary components for adaptability to different configurations and machines. 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. 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.

 

COM supports the following three types of servers for implementing components:

  1. In-process server. An In-process server is implemented as a dynamic linked library (DLL) that executes within the same process space as the application, commonly referred to as an Active X Control.
  2. Local server. A local server executes in a separate process space on the same computer.
  3. Remote server. A remote server executes on a remote computer. DCOM extends COM by providing an RPC-based infrastructure that is used to manage communications between the application and the remote server.

 

 

 

Accessing COM Services

 

 

In the same process

Fast, direct function calls

 

 

 

 

 


On the same machine

Fast, secure IPC                                              

 

 

 

 

 

 

 

 

Across machines

Secure, reliable and

flexible DCE-RPC

based DCOM protocol

 

 

 

 

 

 

 

 

 

 

 

 

Source: The Microsoft COM Component Object Model presentation, by Joe Maloney

 

 

DCOM takes COM a step further and allows software components to communicate directly across networks. DCOM performs remote method calls when a client wants to call an object in another address space. DCOM supports multiple network transports, TCP/IP & UDP/IP, IPX/SPX, HTTP and many others.

 

The trends driving DCOM include growth in the off-the-shelf component marketplace, ubiquitous availability of Windows operating systems, commodity software, cross-platform adoption of COM, richer integrated services, development tools, and the growth of NT and more recently Windows 2000 relative to UNIX.

 

Some features of DCOM include the following:

Ø      Transport neutral: connection oriented or connectionless, multiple protocols.

Ø      Open technology: Windows, Apple, UNIX and some legacy environments, although predominantly Windows.

Ø      Common Web browser and server components: Active X components can be embedded into browser-based applications.

Ø      Security: Internet certificate-based security

Ø      Distributed Computing Environment’s RPC mechanism extension: proposed Internet standard.

 

 

 

 

The Object Management Group’s CORBA

CORBA is a distributed object framework proposed by a consortium of 700+ companies called the Object Management Group (OMG). The specification created by the OMG is the Object Management Architecture (OMA), of which CORBA is a fundamental part. The purpose of CORBA is to provide interoperability between applications in a heterogeneous distributed environment. From the beginning it was designed to solve the problem of inter-machine communications and is therefore a remoting architecture. The CORBA 2.1 specification was adopted in August 1997. CORBA provides cross-language, cross-platform and cross-vendor interoperability and is the dominating remoting architecture in use today.

 

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. 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 common Interface Definition Language (IDL) that interfaces with the Object Adapters makes these translations possible. The interfaces defined in an IDL file serve as a contract between a server and its clients and consist of specific operations and their parameters. There are three categories for interfaces:

 

 

CORBA 2.1 specifies the following responsibilities for Object Adapters:

 

CORBA 2.2 specifies the following critical elements:

 

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.

 

In both DCOM and CORBA, the interactions between a client process and an object server are implemented as object-oriented RPC-style communications. 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.

 

Traditional CORBA messaging provides three models for message invocation.

 

 

 

COM versus CORBA Assessment

Programming language choice is no longer a primary consideration in developing a distributed application. Both DCOM and CORBA provide a language independent mechanism for describing distributed object interfaces. Distributed objects can be implemented in one language and used by client applications implemented in a different language. Process and machine boundaries are more easily crossed because DCOM and CORBA abstract multi-platform issues so that interprocess communications is as simple as calling a method on an object.

 

The fundamental traits of a distributed object system include:

 

 

 

COM/CORBA Similarities and Differences

Trait

Similarities

Differences

Interfaces

COM and CORBA each use their own interface definition language (DLL) to describe interfaces.

CORBA IDL is simpler and more elegant COM IDL.

COM has better tool support for creating and managing IDL than CORBA.

Data Types

COM and CORBA support a rich set of data types.

COM and CORBA also support constants, enumerated types, structures, and arrays.

COM identifies a subset of data types known as automation types. Automation compatible interfaces are supported in more client environments than non-compatible interfaces. COM interfaces that are not automation-compatible are not guaranteed to work in environments other than C++.

Any CORBA interface can be used from any CORBA client.

Marshalling and unmarshalling

COM and CORBA rely on client stubs and server stubs. Users don not normally need to worry about marshalling.

COM allows automation-compatible interfaces to use type library marshalling, thus eliminating the need for customized stubs.

Proxies, stubs, and skeletons

COM and CORBA relay on client stubs and server stubs to handle remoting issues.

COM and CORBA generate client stubs and server stubs from IDL.

COM calls client stubs proxies and server stubs stubs. CORBA calls client stubs stubs and server stubs skeletons.

COM proxy-stub DLLs are used by all language environments. In CORBA, a separate stub-skeleton must be generated for each ORB/ language combination.

Object handles

COM and CORBA support reference-counted handles on object instances.

COM calls object handles interface pointers. CORBA calls object handles object references.

CORBA supports multiple inheritance in the interface hierarchy. COM supports single inheritance only; however, a COM object supports one or more distinct interfaces.

Object creation

COM and CORBA use factories to create object instances

COM has a standard factory interface called IClassFactory. Corba factories are customized persistent CORBA objects.

Object invocation

COM and CORBA allow for method invocation similar to native environment invocation.

COM’s error handling mechanism is based on HRESULT return values. CORBA supports user-defined exception types in IDL.

Object destruction

COM and CORBA rely on reference counting to determine when an object can be destroyed.

COM supports distributed reference counting and garbage collection. CORBA reference counts are maintained separately in the client and server.

Source: COM and CORBA Side by Side, by Jason Pritchard

 

 

 

One of the greatest differences between COM and CORBA is the competitive nature by which each is driven. Microsoft’s goal is to elevate Windows NT and Windows 2000, to the status of dominant server technology. Microsoft has introduced its Microsoft Component Services suite which contains COM and DCOM  as well as the Microsoft Transaction Server, the Microsoft Internet Information Server, Microsoft Message Queue services and Microsoft Distributed Network Addressing. The platform strategy is vertical in that Microsoft controls the technology from the operating system level all the way up to end-user applications.

 

The Object Management Group (OMG) is an organization whose charter includes the creation of specifications that are aimed at creating interoperable and portable distributed object solutions across many platforms. The CORBA vendors implement products based on those specifications. Because most CORBA vendors do not control a single operating system they generally cover multiple platforms, thus resulting in a fairly horizontal platform strategy.

 

One area where most CORBA vendors are weak is the area of development tools. Microsoft on the other hand has many IDE tools available, such as Visual Basic and Visual C++. CORBA’s greatest strength is its ability to bridge a wide range of operating systems and programming languages when creating a distributed system.

 

To make a decision for either architecture an assessment strategy should be prepared. The assessment should include platform criteria, essential services and intangibles.

 

The following criteria should be considered when selecting programming language and operating system platforms:

Ø      Legacy system support

Ø      Operating system support

Ø      Programming language support

Ø      Availability of development tools

 

There are certain essential services that are difficult to build customized infrastructure for, rather they should be part of the architecture. The following are some of the service-related criteria to be considered:

Ø      Distributed transaction support

Ø      Security and privacy

Ø      Messaging support

Ø      Distributed object management

 

Finally, the least specific criteria to be considered include the following intangibles:

Ø      Vendor perception

Ø      Vendor commitment and viability

Ø      Vendor lock-in

Ø      Availability of product

Ø      Availability of development staff

Ø      Product cost

 

These criteria all must be weighted in relation to what is most important for the implementation at hand. With the information in this paper it should be possible to make an informed decision for a given situation.

 

References

Jason Pritchard, PH.D., COM and CORBA Side by Side, Addison-Wesley Longman, Inc., 1999

Doreen L. Galli, Distributed Operating Systems, Prentice Hall, 2000

Hosted by www.Geocities.ws

1