COMVSCORBA

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.

Two major extensions to COM: MTS and MSMQ are provided by DCOM. DCOM Server Objects provide support for multiple threads. MTS (Microsoft Transaction Server) runs on Windows NT Server and provides transaction oriented processing and is based on the DTC (Distributed Transaction Coordinator). MTS is included in DCOM as a runtime middle-ware environment that provides asynchronous application operation with MSMQ and synchronous operation with RPC (Remote Procedure Call). DCOM also has remote garbage collection functionality built into it, which makes it a robust system.

• CORBA:

CORBA is designed and structured to allow integration of multiple object systems written in different languages and running on different platforms. CORBA relies on ORB middle-ware for communication between the server and the client. ORB acts as an object that connects remote objects transparently. Each CORBA object exposes an interface that has a set of methods attached to it. ORB is responsible for finding the object implementation for the request and to format and communicate request to the CORBA server. ORB provides transparency to the client, and the client never needs to know about the location of the remote object and what language was used to implement it.

CORBA is based on Object Management Architecture (OMA), and OMA defines a broad range of services for building distributed applications. OMA services are divided into three layers named CORBAServices, CORBAFacilities, and ApplicationObjects. ORB communication infrastructure is required for applications to access these services. These services are actually definition of different categories of objects in OMA and define a broad range of functionality needed to support distributed applications.

1. CORBAServices: are the necessary building blocks for developing distributed applications. These services provide asynchronous event management, transactions, persistence, concurrency, naming, relationships, and lifecycle management.
2. CORBAFacilities: are not necessary for developing distributed applications but can be useful in some cases. These facilities provide information management, system management, task management, and user interface.
3. ApplicationObjects: are dedicated to providing service to a class of application or a specific application. These are either basic services, support common facilities or application-specific services.

CORBA interfaces and data types are defined using OMG Interface Definition Language. Each interface抯 methods are also defined using OBG IDL. IDL is the key part of CORBA architecture that provides mapping of data types between CORBA and programming languages. IDL also allows f

补充：软件开发 , Delphi ,

上一个：多线程与COM（Multi-ThreadingAndCOM---ForDelphi）
下一个：COMDCOM对象中通过Variant传递数组