What is an Object Request Broker?

An Object Request Broker (ORB) is middleware that establishes a client / server relationship between objects. Using ORB, clients can transparently call methods on a service object, which can be local or on other machines connected via the network. The ORB intercepts this call and is also responsible for finding the object implementing the service and passing parameters to it, calling the method, and returning the final result. The client does not know where the service object is located, what its programming language and operating system are, or what other parts of the system are not part of the object interface. In this way, ORB provides interoperability for applications on different machines in a heterogeneous distributed environment, and seamlessly integrates multiple object systems.

Object Request Broker is an interface for users to communicate with objects in other distributed network environments. It is the main type of middleware. It is at the core of the Common Object Request Broker Architecture (CORBA) specification. , Defines the basic mechanism of objects transparently sending requests and receiving responses in a heterogeneous environment. It is a middleware that establishes the client / server relationship between objects. Its role is to provide a communication framework to transparently pass object requests in a heterogeneous distributed computing environment. The CORBA specification includes all standard interfaces of the ORB. The Object Request Broker structure does not need to be implemented separately as a component, it is defined by an interface. Any ORB implementation that provides the correct interface is acceptable.

Chinese name: Object Request Broker
Foreign name: Object Request Broker

Types of: Telecommunication
Related nouns: Middleware
Applied discipline: Communication

Object Request Broker Definition

Object request processing is a kind of middleware that establishes client / server contact between objects.

Object Request Broker Middleware Overview

Middleware is an independent system software or service program, and distributed application software uses this software to share resources between different technologies.

Middleware sits on the client / server operating system and manages computing resources and network communications. Software that connects two independent applications or independent systems. Connected systems, even if they have different interfaces, can still exchange information with each other through middleware. A key way to implement middleware is information transfer. Through middleware, applications can work in multiple platforms or OS environments, can meet the needs of a large number of applications, run on multiple hardware and OS platforms, support distributed computing, and provide transparent application or service interaction across networks, hardware, and OS platforms Standard protocol support Standard interface.

Object Request Broker Function

The Object Request Broker (ORB) is an object bus. It is at the core of the CORBA specification. It defines the basic mechanism for objects to transparently send requests and receive responses in a heterogeneous environment. It is a middleware that establishes the client / server relationship between objects. The ORB enables objects to transparently make requests to or accept responses from other objects, which can be located locally or on remote machines. The ORB intercepts the request call and is responsible for finding the object that can fulfill the request, passing parameters, calling the corresponding method, returning the result, and so on. The client object does not know the mechanism for communicating with the server object, activating or storing the server object, nor does it need to know where the server object is located, in which language it is implemented, what operating system is used, or other system components that are not part of the object interface.

Object Request Broker

Its role is to provide a communication framework to transparently pass object requests in a heterogeneous distributed computing environment. The CORBA specification includes all standard interfaces of the ORB. CORBA 1.1, introduced in 1991, defines the interface description language OMG IDL and an API that supports Client / Server objects to interoperate on specific ORBs. The CORBA 2.0 specification describes interoperability between ORBs provided by different vendors. It is worth pointing out that the client and server roles are only used to coordinate the interaction between objects. According to the corresponding occasions, the objects on the ORB can be client, server, or even both. When an object makes a request, it is in the client role; when it receives a request, it is in the server role. Most objects play both the client and server roles. In addition, because the ORB is responsible for the transmission of object requests and the management of the server, the client and server are not directly connected. Therefore, compared with the simple Client / Server structure supported by RPC, the ORB can support more complex structures.

Object Request Broker Request Broker Architecture

The Common Object Request Broker Architecture (Common Object Request Broker Architecture) is a standard object-oriented application system specification formulated by the OMG organization. In other words, the CORBA architecture is a solution proposed by the Object Management Organization (OMG) to solve the interconnection of hardware and software systems in a distributed processing environment (DCE). The OMG organization is an international non-profit organization. The responsibility is to provide a public framework for application development, formulate industrial guidelines and object management specifications, and accelerate the development of object technology.

The OMG (Object Management Architecture, Object Management Architecture) reference model was formulated shortly after the establishment of the OMG organization, which describes the conceptualized basic structure followed by the OMG specification. OMA is composed of object request broker ORB, object service, public facilities, domain interface and application interface. The core part is object request broker ORB (Object Request Broker). Object services are a set of basic services provided for using and implementing objects; public facilities are a set of shared service interfaces provided to end-user applications; domain interfaces are interfaces provided for application domain services; application interfaces are provided by developers The products used for their interfaces are not part of the OMG standard. ORB provides a mechanism through which objects can transparently send requests and receive responses. Distributed, interoperable objects can use ORBs to construct interoperable applications.

The CORBA standard is established and controlled by the Object Management Group (OMG). CORBA has agreed on a series of APIs, communication protocols, and object / service information models to enable heterogeneous applications to interoperate. These applications use different programming languages Write and run on different platforms. CORBA therefore provides platform and location transparency for well-defined objects that are the basis of distributed computing platforms.

Generally speaking, CORBA packages program code developed in other languages and information about the capabilities of the program code and how to call the program code into a package. Packaged objects can be used by other programs on the network ( Or CORBA object). In this sense, CORBA can be viewed as a machine-readable file format, similar to a header file, but with a lot of information.

CORBA uses an interface definition language to describe the interface that objects will present. CORBA also specifies the mapping from IDL to a specific programming language, such as C ++ or Java. This mapping accurately describes how CORBA data types are implemented by the client and server. The standard mappings are Ada, C, C ++, Smalltalk, Java, and Python. There are also some non-standard mappings. The mappings for Perl and Tcl are implemented by ORBs written in these languages.

The Object Request Broker structure does not need to be implemented separately as a component, it is defined by an interface. Any ORB implementation that provides the correct interface is acceptable. Interfaces can be divided into the following categories:

1. Implement the same interface for all ORBs;

2. Operations specific to a specific object type;

3. A specific form of operation specified by the object;

Different ORBs can use different implementation strategies, plus IDL compilers, libraries, and different object adapters, all of which provide a series of services to customers and implementation of objects with different attributes. There can be multiple ORB implementations. They have different names and different implementation methods and invocation methods. For customers, customers can access objects managed by different ORB implementations at the same time. When several ORBs work together, they must be able to distinguish Their respective object names (that is, object references) can be used by customers regardless of differences. The ORB kernel is part of the ORB, and it provides basic naming and request communication mechanisms for objects. CORBA is designed to support different object mechanisms. It does this by building an ORB on the ORB kernel.

The client of an object can access this object reference and manipulate the object. The client does not know the internal structure of the object, it only knows the interface of the object and the resources such as time and space required to perform the operation. Although we can think of a client as a process that calls an object, we also don't forget that an object can also call a service of another object. The ORB interface that customers see is similar to the interface in people's concepts, which helps programming. Customers do not need to make changes to the code to implement functions through the ORB. The object adapter can only be called by the ORB or the object implementation.

Object implementations provide representations of objects. Usually the implementation is provided by another object or by the corresponding software, of course, it can also be implemented by itself. In some cases, the primary function of an object is to make a contribution to non-object entities. Different implementations of objects can be supported in CORBA. Generally, the object implementation does not depend on the ORB or client request. The object implementation can choose the interface by selecting the object adapter selection and ORB-related services.

The object reference is the information that needs to be specified in the ORB. The client and object implementations have a transparent definition of the object reference corresponding to the language mapping. This isolates the implementation representation from the reference. The two ORB implementations may be different when choosing an object reference representation. All ORBs must provide a consistent language mapping relative to the object reference, which enables programs to access the object reference independently of the ORB.

Object Request Broker Overview

When developing traditional Client / Server applications, developers use their own design or a recognized standard to define protocols for communication between devices. The definition of the protocol depends on the implementation language, network transmission, and many other factors, and the advent of ORB has simplified this process. When using ORB, the protocol is defined using Interface Definition Language (IDL, InterfaceDefinitionLanguage), and IDL is language independent. And ORB provides great flexibility, it enables programmers to choose the most suitable operating system, execution environment, and even the various components of the system can be implemented in different programming languages. More importantly, it allows integration of existing components. In an ORB-based solution, developers can use the same IDL as new objects and model legacy systems. They create "wrapper" code to pass information between a standardized software bus and the legacy system interface.

ORB Object Request Broker ORB Structure

Figure 1 shows a client sending a request to an ObjectImplementation. The client is an entity that operates on the object, and the object entity is the code and data that implement the object. The ORB is responsible for locating an object based on a request, and arranging the object implementation to prepare to accept the request and communicate with the requested data. The client's interface has nothing to do with the location of the object, the language in which it is implemented, and other aspects that are not reflected in the object's interface.

The client uses a dynamic invocation interface (DynamicInvocationInterface) or an interface stub (OMGIDLStub) to make a request. For some reason, the client can also contact the ORB directly. The object implementation accepts the request by using a framework file (Skeleton) generated by performing interface language mapping on the interface or a dynamic framework Skeleton. Object implementations can also call ObjectAdapters and ORBs.

There are two ways to define an object interface. The first method is to define the interface using the Object Description Language (OMGInterfaceDefinitionLanguage). The language defines object types based on the operations that can be performed on objects and the parameters used by those operations. The second method is to put the interface into the interface library service (InterfaceRepositoryService); this service describes the elements in the interface as an object. In any software that can implement ORB, the interface description language (which may change according to the content of the document) and the interface library have the same role. For a client to use an ObjectReference to complete a request, it must know the type of the object and the specific operation.

Figure 1 Passing the request through the ORB

Requests made using stubs and dynamic invocation interfaces have the same semantics, and the receiver of the information cannot tell which method was used to pass the request. The ORB determines the appropriate implementation code, passes parameters, and passes control to the object implementation through the interface framework or dynamic framework, as shown in Figure 2. Each interface and object adapter uses a different framework file. To complete the request, the object implementation may use services from the ORB through the object adapter. When the request is completed, control and output results are returned to the client.

Figure 2 Client access object implementation process

CORBA Object Request Broker Public Object Request Broker Architecture (CORBA)

In order to solve the problems of interconnection of different hardware devices and software systems in a distributed computing environment (DCE, Distributed Computing Environment), enhance the interoperability of software between networks, and solve the problems in the traditional distributed computing model, the Object Management Organization (OMG) proposed Common Object Request Broker Architecture (CORBA) to enhance the interoperability between software systems and make it possible to construct flexible distributed application systems.

The CORBA specification makes object-oriented software reusable, portable, and interoperable in a distributed, heterogeneous environment. It mainly includes the following features.

(1) CORBA adopts an object-oriented software development method to achieve a complete encapsulation of the internal details of the application object, retaining the external interface definition of the object method. CORBA uses OMGIDL to define interfaces and can be mapped to a variety of programming languages, including C, C ++, Java, python, and SmallTalk. An interface corresponds to a class that supports inheritance. The methods of a class only need to be declared in the interface, and there is no need to specify the interface implementation method. Taking WiMAX as an example, the description of OMGIDL is as follows. The required interfaces include antenna control, scrambling, channel coding, interleaving, digital modulation, OFDM, OFDM demodulation, digital demodulation, channel decoding, and descrambling.

moduleWiMAX

{

interfaceAntennaControl

{

booleansetRxAntenna (inANTENNAant);

booleansetTxAntenna (inANTENNAant);

};

interfacerandomization

{

...

}

...

};

(2) CORBA uses middleware as a transaction proxy to handle object access requests from clients to the server in distributed applications. Middleware is the ORB in CORBA, which is equivalent to the soft bus in CORBA. Its structure is shown in Figure 3.

Figure 3 ORB soft bus

The client is completely separated from the service object. The client does not need to know the implementation process and specific location of the service object. It only needs to pass parameters to call the server program through the ORB and obtain the server return value through the ORB.

CORBA Role of Object Request Agent CORBA in Software Defined Radio System

Software radio requires not only hardware modularity, but also software modularity. Due to the lack of a standard application-level software-to-software application programming interface (API), the lack of quantification of memory, cache space, and processing resources, low software reuse, high cost, and long development cycles, the software needs to be divided into modules by function The functions and interfaces of each module are clearly defined. The software radio forum distinguishes each module according to the API, and uses CORBA to build the entire system. CORBA technology can seamlessly share application data, and it provides a soft bus. Using the interface definition language (Java language is a subset), each software package is provided with an information transmission interface to the ORB, and the object uses the CORBA interface to implement plug-in.

What are the benefits of using CORBA in software radio? This is an interesting topic. In fact, there are many ways to build a software radio architecture, but this does not mean that the research on how to build a software radio architecture is well-established. On the contrary, none of these methods or theories gives a general way to build a software-defined radio system. For example, some companies have developed software radio receivers, but it is difficult or almost impossible for people to move the system they build to another software radio system (even if it is easiest to develop a corresponding software transmitter). ), Because system building is more based on processing. The introduction of CORBA is an attempt to solve this problem. It was not put forward to solve a specific problem, but was given the mission of building an abstract software radio system in the general sense from the beginning. The research believes that CORBA can fulfill such a mission. First, CORBA is an open, vendor-independent, underlying structure for computer applications on the network. CORBA-based applications from any manufacturer, computer, operating system, programming language, and network environment use the IIOP standard protocol, so any CORBA-based application can work together. Second, using CORBA in a small client / server mode application system can provide the system with a reliable and standard underlying structure. CORBA can be used to build, run on different platforms, and implement clients and programmers implemented in different programming languages. Server-side application. In addition, due to the existence of CORBA's fault tolerance mechanism, when using CORBA to make server-side application systems based on the object model, each object runs on two or more servers at the same time. When one of them fails, the system automatically Switch to another server. This will not only ensure that the server will have high stability, but also achieve system load balancing. Considering the current load and the load situation that may be reached in the future, you can choose ORB, which can achieve load balancing among multiple servers. It is based on the OMG removable object adapter. When the system is under heavy load (such as running a web-based application), it can make fuller use of the system's hardware resources.