In the world of distributed systems, CORBA (Common Object Request Broker Architecture) and DCOM (Distributed Component Object Model) are two significant technologies designed to enable communication between objects in different locations, be it across networks or within different systems. Both have been instrumental in solving interoperability issues in large systems, but they come with distinct features, advantages, and challenges. This article will explore the key differences between CORBA and DCOM, making it easier for developers to decide which technology might suit their particular needs.
What is Common Object Request Broker Architecture (CORBA)?
The Common Object Request Broker Architecture is a detailed specification for the distributed objects. It was introduced by the OMG (Object Management Group). The architecture describes a language with a platform-independent object bus named as ORB (Object Request Broker). These advance the objects to make the request and receive a response from the remote objects transparently. This also supports handling
Advantages of CORBA:
- Platform and Language Independence: CORBA is language-agnostic, supporting multiple programming languages like C++, Java, Python, and more. It can operate across diverse platforms.
- Scalability: CORBA was designed with scalability in mind, making it suitable for large, enterprise-level applications.
- High Level of Abstraction: CORBA allows communication between systems at a high level of abstraction, making it easier for developers to work on distributed systems.
Disadvantages of CORBA:
- Complexity: The initial setup and learning curve of CORBA can be quite steep, especially for developers unfamiliar with distributed computing.
- Overhead: CORBA can introduce significant overhead, particularly in terms of performance, due to its comprehensive feature set.
- Security Concerns: While security standards exist for CORBA, its older versions have been criticized for weak or insufficient security measures concurrency and handling exceptions.
What is Distributed Component Object Model (DCOM) ?
The distributed component object model was introduced by Microsoft with its Window NT as a bundle package. DCOM was used with Internet Explorer present inside Windows and it was expected to attract the developers for using what they have rather than buying. DCOM is also an object bus that helps the specification of object interfaces and invoking dynamic object exports that supports distributed environment. This supports sharing if code and requires the shared code to be declared using an object interface.
Advantages of DCOM:
- Tight Integration with Windows: As a Microsoft technology, DCOM integrates seamlessly with Windows-based systems, making it a solid choice for applications built in the Windows ecosystem.
- Ease of Use: Developers familiar with COM and the Microsoft ecosystem will find DCOM relatively straightforward to implement.
- Support for Multiple Languages: Although tightly integrated with Microsoft, DCOM supports multiple programming languages such as Visual Basic, C++, and Java.
Disadvantages of DCOM:
- Platform Dependency: DCOM is heavily tied to the Windows platform, making it less suitable for systems requiring cross-platform compatibility.
- Security Overhead: DCOMâs security model is complex, which can add significant overhead when configuring and maintaining distributed applications.
- Network Performance: DCOM may experience slower performance on large-scale distributed networks, especially compared to more modern technologies.
Differences between CORBA and DCOM :
| Basis of | CORBA | DCOM |
|---|---|---|
| Introduced by | It was introduced by Object Management Group | It was introduced by Microsoft |
| Focuses on | This focus on Enterprise first and then Desktop | This focus on Desktop first and then Enterprise |
| Platforms | It is available on Unix, Windows and Macintosh. | It is available with Windows NT and Full support with all versions of Windows, Unix and Macintosh |
| Object Implementation | Various languages are supported as long as IDL can mapped to this language | Many languages are supported as Java, COBOL, C++, and Delphi but specification is done with binary language |
| Client/Server Interface | Interface at Client side is stub and Server side is skeleton | Interface at Client side is proxy and Server side is stub |
| Object Activation and Location | Here Object Adapter is used for activation and ORB is used for location | Here SCM (Service Control Manager) is used for activation and location |
| Inheritance | Supports inheritance with interface level when every interface is inherited from CORBA object. | Supports multiple inheritance when object implements IUnknown interface. |
| Garbage Collection | It does not provide general purpose Distributed Garbage Collection | It provides general purpose Distributed Garbage Collection through pinging the wire. |
| Exception Handling | The care is taken by Exception objects | Exception are thrown out to HRESULT and for other exceptions ISupportErrorInfo interface has to be implemented |
| Availability | It is available by multiple vendors | It is available via single vendor |
Conclusion
In summary, both CORBA and DCOM are powerful technologies designed to facilitate communication between distributed objects, but they cater to different environments and use cases. CORBA offers platform and language independence, making it ideal for heterogeneous systems, while DCOM provides tighter integration with Windows, suitable for developers working within the Microsoft ecosystem. The decision to use CORBA or DCOM depends on factors such as platform requirements, the complexity of the system, and the developer's familiarity with the respective technology.
