Common Object Request proxy (scheduling) program architecture (CORBA)

Common Object Request proxy (scheduling) program architecture (CORBA)

What is CORBA?

Common Object Request Broker Architecture, abbreviated as CORBA, is an Object Management Group) solutions proposed in response to today's rapidly growing demand for software and hardware collaboration capabilities. In short, CORBA allows applications to communicate with other applications, no matter where they are or who they are designed. CORBA 1.1 was released in 1991 by the object management organization. It defines the Interface Definition Language (IDL) and application programming interface (API), so as to activate the interaction between the client and server by implementing the Object Request proxy (ORB. CORBA 2.0 was released in. He defines how to communicate across different orb providers.

Orb is a middleware that establishes a customer-server relationship between objects. With orb, a customer can easily use the Server Object method, regardless of whether the server is accessed on the same machine or through a network. Orb intercepts the call and is responsible for finding an object to implement this request, passing parameters and methods, and finally returning results. The customer does not need to know where the object is, what language is implemented, its operating system, and other things irrelevant to the object interface.

In traditional Client/Server programs, developers use protocols designed by themselves or recognized standards to define devices. The Protocol definition depends on the implementation language, network transmission, and many other factors. Orb simplifies this process. Using orb, the Protocol definition is through the application interface, which is an implementation of the Interface Definition Language (IDL), which is irrelevant to the programming language used. In addition, ORB provides great flexibility. He asked programmers to select the most appropriate operating system, operating environment and design language to build each component in the system. More importantly, it allows integration of existing components.

CORBA is a signal on the path of object-oriented standardization and interoperability. By using CORBA, users do not need to know the hardware and software platforms and where they are in the enterprise network.

Orb Structure

The following is a graphical description:

Send a request through ORB


The preceding figure shows how the client sends a request to an object. The client is the entity that you want to perform operations on an object. Object implementation is a piece of code and data to actually implement the object. Orb is responsible for the following necessary mechanisms: Find the implementation of the Object for this request, so that the implementation of the object is ready to accept the request, and exchange data with the request. The client interface is completely independent of the object location, and its implementation language and other things that do not affect the object interface.

Orb INTERFACE STRUCTURE


The above figure shows an independent Object Request proxy (ORB) structure. The orb interface is a gray rectangle. The arrow shows the call relationship of ORB.

To make a request, the client can use the dynamic call interface (dynamic invocation interface) (independent from the interface of the target object) or an omg idl placeholder program (the specific placeholder program depends on the interface of the target object ). The client can also directly interact with orb in some places.

The object is implemented by calling the framework generated by omg idl or a dynamic skeleton to accept the request. The object implementation may call Orb when processing requests or other requests.

The following two methods can be used to define an object interface. The interface can be used to define static language definitions. This is called OMG's IDL. The language defines the object type according to the operations that can be performed and the parameters of the operation. Alternatively, the interface can be added to the Interface Repository service. This Service describes the components of this interface as an object and allows runtime access to these components. In any orb implementation, IDL and Interface Repository have the same expression capability.

The client uses a placeholder program or dynamically calls an interface.


The client publishes a request by accessing the object reference and understanding the object type and required operations. The customer calls the placeholder program routine to request or dynamically construct the request.

Both the dynamic interface and placeholder interface can be implemented in the same way. The recipient cannot know how the request is published.

Object implementation acceptance request


Orb positions the appropriate code to the object, transmits parameters, and transmits control. All of this is done through the IDL skeleton or dynamic skeleton. The skeleton is different for different interfaces and object adapters. When the request is executed, ORB may use the Object Adapter to obtain certain services. When the request is complete, the control and output values are returned to the customer.

The Object Adapter may be used for object implementation. This determines the Service Based on the implementation requirements of the object.

Interface and implementation Repositories


This section describes how interfaces and implementation information allow access to customers and objects. The interface is defined by omg idl and/or Interface Repository. This definition is used to generate the skeleton of the customer placeholder program and object implementation.

The object implementation information is provided during installation and stored in implementation repository for use during request Publishing.