Object Request Broker

Explore the basics of how the ORB handles communications.

As the animation above illustrates, the ORB is the communications backbone of CORBA. One of the significant advantages of the ORB is that clients and servers may concentrate on making CORBA requests and issuing CORBA replies, while the ORB worries about the communications details, such as finding the server and moving data across the network.
An (ORB) object request broker is a piece of middleware software that allows programmers to make program calls from one computer to another via a network. ORBs promote interoperability of distributed object systems because they enable programmers to build systems by piecing together objects from different ORB vendors so that communication via the ORB can occur. ORBs handle the transformation of in-process data structures to and from the byte sequence, which is transmitted over the network.This is called marshalling or serialization. Certain ORBs, such as CORBA-compliant systems, use an Interface Description Language (IDL) to describe the data that is to be transmitted on remote calls. In addition to marshalling data ORBs expose other features, such as distributed transactions, directory services or real-time scheduling. In OO languages, the ORB takes the form of an object with methods enabling connection to the objects being served. After an object has connected to the ORB, the methods of that object become accessible for remote invocations. The ORB requires definitive means of obtaining the network address of the object that has now become remote.

The Object Request Broker (ORB) communication protocol is a central part of the Common Object Request Broker Architecture (CORBA), which facilitates communication between distributed objects in a heterogeneous network. The ORB acts as a middleware layer that abstracts the details of network communication, enabling objects to interact regardless of their location, programming language, or operating system.
Key Features of the ORB Communication Protocol:

1. Object Transparency
   • The ORB hides the complexities of networking, making remote method calls appear as if they are local.
   • This allows developers to focus on application logic instead of worrying about low-level communication details.
2. Interoperability
   • The protocol enables interaction between objects running on different platforms, written in different programming languages, and residing in different network environments.
   • CORBA achieves this through standardized communication protocols like GIOP (General Inter-ORB Protocol) and its Internet variant IIOP (Internet Inter-ORB Protocol).
3. Standardized Interfaces
   • Interfaces are defined using the Interface Definition Language (IDL), which is programming language-agnostic.
   • The ORB uses the IDL to generate stubs (client-side) and skeletons (server-side) to handle communication between objects.
4. Request Handling
   • When a client makes a request to a remote object, the ORB handles the request as follows:
   1. The client stub converts the method call into a standardized request format (marshaling).
   2. The ORB sends the request over the network to the target object.
   3. The server skeleton receives the request, unmarshals it, and invokes the appropriate method on the target object.
   4. The server's response is sent back to the client via the same mechanism.
5. Language and Platform Independence
   • The ORB facilitates communication between objects written in different programming languages (e.g., Java, C++, Python) and running on different operating systems (e.g., Linux, Windows).

Core Components of the ORB Communication Protocol:

1. Stub and Skeleton
   • The stub acts as a proxy on the client side, converting method calls into a format the ORB can transmit.
   • The skeleton is the server-side counterpart, translating the incoming request back into a method call.
2. Object Adapter
   • Responsible for connecting objects to the ORB and managing object references.
   • The Portable Object Adapter (POA) is a common implementation in CORBA.
3. IDL (Interface Definition Language)
   • Defines the interfaces of distributed objects, enabling communication between systems written in different languages.
4. IIOP (Internet Inter-ORB Protocol)
   • A specific implementation of GIOP that allows ORBs to communicate over the Internet using TCP/IP.

Advantages of the ORB Communication Protocol:

• Decoupling: The client and server are loosely coupled, allowing for better scalability and easier maintenance.
• Flexibility: Supports integration in heterogeneous environments with minimal changes.
• Standardization: CORBA's adherence to standards ensures compatibility and interoperability across systems.

Disadvantages:

• Complexity: The CORBA specification is extensive and can be challenging to implement and maintain.
• Overhead: The abstraction and additional layers introduce performance overhead compared to lightweight alternatives like REST or gRPC.
• Legacy Technology: While still in use in some domains, CORBA has largely been replaced by modern protocols in many industries.

The ORB communication protocol is a foundational element of CORBA, enabling the seamless interaction of distributed objects in diverse and heterogeneous computing environments.

The OMA uses two related models to describe how distributed objects and the interactions between them can be specified in platform-independent ways.

1. The Object Model defines how the interfaces of objects distributed across a heterogeneous environment are described, and
2. the Reference Model characterizes interactions between such objects.

The Object Model defines an object as an encapsulated entity with an immutable distinct identity whose services are accessed only through well-defined interfaces. Clients use an object's services by issuing requests to the object. The implementation details of the object and its location are kept hidden from clients.
The Reference Model provides interface categories that are general groupings for object interfaces. All interface categories are conceptually linked by an Object Request Broker (ORB). Generally, an ORB enables communication between clients and objects, transparently activating those objects that are not running when requests are delivered to them. The ORB also provides an interface that can be used directly by clients as well as objects. Object Services are domain-independent, or horizontally oriented, interfaces used by many distributed object applications. For example, all applications must obtain references to the objects they intend to use. Both the OMG Naming Service and the OMG Trading Service are object services that allow applications to look up and discover object computing infrastructure. Domain Interfaces play roles similar to those in the Object Services category except that domain interfaces are domain-specific, or vertically oriented. For example, there are domain interfaces used in health care applications that are unique to that industry, such as a Person Identification Service. Other interfaces are specific to finance, manufacturing, telecommunications, and other domains.