COM VS CORBA

Thursday, March 15, 2001

By Ish Singh

Introduction:

COM is sometimes referenced as Common Object Model but Microsoft officially calls it Component Object Model. Microsoft also developed DCOM as an extension of COM. DCOM was designed with distributed computing in perspective. CORBA stands for Common Object Request Broker Architecture and developed by Object Management Group (OMG). COM/DCOM and CORBA among others are object-oriented approaches for the use and development of software components. They are the competing architectures for application development in the client/server world. These architectures support distributed computing and provide support for interoperability and limited portability. Distributed computing technologies are necessary for creating flexible client/server systems. These distributed objects can exist anywhere on the system as they encapsulate the data and business logic within themselves. As heterogeneous systems are getting more and more popular, distributed objects are also getting popular, as they are really good at connecting these heterogeneous systems.

CORBA and DCOM are both designed for client/server style communication among distributed objects. In both technologies, a client invokes a method that is implemented by a remote object that acts as a server. The interface for such an object providing the service is defined in an Interface Definition Language (IDL). This keeps the object implementations hidden from the client. Both CORBA and COM communications are implemented like RPC and methods of remote objects are invoked on reference. The support for data types in both these technologies is limited to a few data types that can be mapped to multiple programming languages.

Origin:

• COM/DCOM:

Its predecessor OLE (Object Linking and Embedding) was originally used for linking documents on Microsoft Win 3.1 OS. COM was developed to integrate components dynamically within a single address space. COM was designed to provide support of dynamic use of multiple vendor binary components in one single application. Component interactions are based on OLE2 interfaces and protocols. Although COM uses OLE2 interfaces and protocols, it is worthy to know that COM is not OLE. DCOM was developed as an extension of COM to allow network based interactions and allows processes to be spread across a network.

• CORBA:

Common Object Request Broker Architecture was developed by Object Management Group (OMG). OBG is a consortium of hundreds of companies that are working to the adapt a standard architecture for distributed object computing. CORBA is based on Object Management Architecture, which was published in 1991 by the OMG. CORBA was developed to provide vendors with a standard architecture that allows them to develop applications using different languages, operating systems, and hardware and still provide the portability and interoperability.

Technical View:

• COM/DCOM:

COM allows clients to invoke services provided by COM-compliant components by defining a binary compatibility specification and implementation. COM compliant components (COM Objects) provide a set of interfaces that allow a client to contact the Object using those interfaces only.

COM defines the binary structure between the client and the Objects and is the basis for interoperability between components written in multiple programming languages as long as the language compiler supports Microsoft抯 COM binary structure.

COM objects can have multiple interfaces but each class must have its own unique class ID (CLSID) and its interface must have Globally Unique Identifier (GUID) to avoid name collisions. Objects and interfaces are defined using Microsoft抯 IDL (Interface Definition Language). COM architecture does not allow for easy modification of the interfaces and their methods to help prevent potential version incompatibilities. COM developers are rather encouraged to build new interfaces to the objects to provide additional functionality. COM objects run inside of a server, and the server provides three ways for the clients to access COM Objects.

1. In-process server: Client and Server run in the same memory process and communicate among each other using function calls.
2. Local Object Proxy: This allows clients using an inter-process communication mechanism to access server running in a different process but on the same physical machine. This inter-process mechanism is also known as lightweight remote procedure call.
3. Remote Proxy Object: This allows clients to access remote servers running on another machine. Clients and servers communicate using distributed computing environment RPC. Remote objects supporting this mechanism are called DCOM Servers.

   标签：

   版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
   特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有