Interpretation of COM and CORBA (on) Technical Analysis (Author: Shi Xiaojun compile April 2001 13 Ri 13:53) COM (Common Object Model) is sometimes referred to as a common object model, Microsoft officially is called Component Object Model (Component Object Model. DCOM is used for distributed calculations, which is Microsoft's development design as an extension to COM. CORBA (Common Object Request Broker Architecture) represents a public object requesting agency architecture, which is developed by an object management working group (OMG). Both COM / DCOM and CORBA are the development and application of software components with object-oriented methods. They are two competitors in the customer / server world to develop applications. These architectures support distributed calculations and provide support for interactive operability and limited portability. Distributed computing technology is required when creating an extensible client / server system. Data and business rules are encapsulated due to these distributed objects, they can exist in any part of the system. The heterogeneous system is now more common, which leads to distributed objects to become more popular, and they do do very well when connecting the heterogeneous system. Corba and DCOM are all communications with client / server modes for distributed objects. In both technologies, a customer calls a request, which is implemented by an object of the distance, and the distant object acts as the role of the server. Objects that provide services have an interface (Interface, interface), which is defined by the interface definition language (IDL). Due to the existence of the interface, the implementation process of the object is concealed for the customer. Corba and COM are implemented by RPC and reference to remote objects. In both technologies, support for data types are limited to several data types, which are mapped to multiple programming languages. Origin ● The predecessor of COM / DCOM COM / DCOM (Object Linking and Embedding, Object Links, and Embeddes) is a document for linking in Microsoft's Win 3.1 operating system. Developing COM is to dynamically integrate components in a single address space. CoM is supported by the dynamic use of complex customer binary components in a single application. Component interactions are based on OLE2 interfaces and protocols. Although COM uses the OLE2 interface and protocol, we must also know that COM is not OLE. DCOM is an extension of COM, supporting network-based interactions, allowing process processing over a network. ● The CORBA Public Object Request Agent Architecture is developed by the Object Management Working Group (OMG). OMG is an organization consisting of thousands of companies that are committed to building a standard architecture of distributed objects. CORBA is based on the object management architecture, and the object management architecture is released from OMG in 1991. Corba provides a standard framework for vendors to use different languages, operating systems, and hardware applications, still have portability and interoperability. Technical perspective ● COM / DCOM COM allows the customer to call the service, the service is provided by the COM-compatible component by defining a binary compatibility specification and implementation process. COM Compatibility Components (COM objects) provides a range of interfaces that allow customers to call related objects through these interfaces. COM defines the binary structure between customers and objects, and as the basis of interoperability between components written in different programming languages, as long as the language compiler supports Microsoft's binary structure.
The COM object can have a complex interface, but each class must have its own unique class identifier (CLSID), and its interface must have a global unique identifier (GUID) to avoid name conflicts. Objects and interfaces are defined by using Microsoft's IDL (interface definition language). The COM architecture is not allowed to easily modify the interface, which helps prevent potential versions from incompatibility. COM developers, in order to provide new features to objects, efforts must be made to create new interfaces for objects. The COM object is running in the server, and the server provides three ways to access the COM object. Processing in the server: The client and server are run in the same memory processing process and communicate with each other by using the methods that use function calls. Local Object Proxy: Allows customers to access the server with internal process communication methods, and the server runs in a different process of the same physical machine. This internal process communication method is also called a remote process call. Remote Proxy Object: Allows customers to access remote servers running on a different machine. Customer and server communication uses a distributed computing environment RPC. Remote objects support this method, known as the DCOM server. Two main extensions of COM: MTS and MSMQ are provided by DCOM. The DCOM server object supports multithreading. MTS (Microsoft Transaction Server) is running on Windows NT Server, providing transaction-oriented processes, and is based on DTC (Distributed Transaction Coordinator, distributed transaction coordination). MTS is included as a real-time intermediate environment to provide an asynchronous application operation for MSMQ, as well as synchronous operations for RPC (Remote Procedure Call). The function of remote garbage collection is built in DCOM, making it a robust system. ● CORBA CORBA is designed and architectures to serve in different programming languages, running on different platforms. CORBA is dependent on the server and customers in the ORB middleware. ORB plays an object that is transparently connected to the remote object. Each CORBA object provides an interface and has a series of methods associated with it. ORB is responsible for discovering the corresponding implementation and passes the request to the CORBA server. ORB provides transparency services to customers, customers never need to know the location of the remote object and what language is implemented. CORBA is based on object management architecture (Object Management Architecture, OMA), and OMA defines a wide range of services for building distributed applications. OMA service is divided into three layers, called Corbaservices, Corbafacilities, and ApplicationObjects, respectively. When the application needs to access these services, an ORB communication framework is required. These services are actually defined by different types of objects in OMA, and a wide range of functions are defined in order to support distributed applications. CORBASERVICES (CORBA Service): It is the module necessary for developing distributed applications. These services provide asynchronous event management, transaction, continuous, concurrency, name, relationship, and management of survival cycles. Corbafacilities (CORBA Tools): For development distributed applications, it is not necessary, but in some cases it is useful. These tools provide information management, system management, task management, and user interfaces. ApplicationObjects: It is primarily served for a certain type of application or a specific application.
