Make your own free website on


Gopalan Suresh Raj

The COM+ / DNA Tutorial
The Advanced Java / JPE Tutorial
The CORBA Tutorial
Three tier Architecture n-tier Architecture
Security Issues Security issues
Architectural issues Architectural issues
Bridging competing Middleware - DCOM and CORBA Bridging

There are some features that are fundamental to any technology which supports distributed component development. When it comes to component building and assembling, some of the fundamental features are:

Features of DCOM and CORBA... Separation of interface from the implementation
Features of DCOM and CORBA... Transparency of Location
Features of DCOM and CORBA... Uniform Exception Handling mechanism
Features of DCOM and CORBA... Component Object Services

Separation of Interface from the Implementation

Both DCOM and CORBA define an Interface Definition Language (IDL) for use by component developers to specify a component's interface independant of a programming language. A component user only needs the IDL of the interface to invoke a function defined in that component. Component developers have the flexibility to develop the component implementation in any programming language of their choice.

Transparency of Location

Both DCOM and CORBA allow components developed using these technologies to communicate in a distributed heterogenous environment. Given a valid object within a client process, it is the object technology's responsibility to locate the server object in the distributed environment and to control subsequent communication between both distributed objects. Location transparency is guaranteed through the use of the proxy-stub mechanism.

Uniform Exception Handling schema

For any object which runs on a heterogenous distributed environment, a uniform, descriptive, elaborate Exception Handling mechanism is necessary. In DCOM, each method call returns a well-defined "flat" structure whose bit settings encode the return status. In CORBA, exception handling is taken care of by Exception Objects. When a distributed object throws an exception object, the ORB transparently transports this object to the client process. By checking the existence and type of the returned object, the client can determine whether or not an exception occured. Microsoft has however announced that a future version of DCOM would support an exception handling mechanism based on exception objects.

Component Object Services

In addition to transparent invocation of requests both DCOM and CORBA come with a complementary set of fundamental component services. Object querying, Object Persistence, Naming, Trading and transaction management for objects are some of the important ones.

The availability of these and other such features simplify component development and help accelerate the development of robust, self-managing components.

More on this soon...



Go to the Component Engineering Cornucopia page

This site was developed and is maintained by Gopalan Suresh Raj

This page has been visited times since March 13,1998.

Last Updated : Apr 4, '98

If you have any questions, comments, or problems regarding this site, please write to me I would love to hear from you.

Copyright (c) 1997-99, Gopalan Suresh Raj - All rights reserved. Terms of use.

All products and companies mentioned at this site,are trademarks of their respective owners.