iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
An Object Request Broker (ORB) is middleware that routes a client’s request to a distributed object and carries the response back. In CORBA, it handles the mechanics of making that invocation; it does not define what the operation means or guarantee that two applications can work together without compatible interfaces and protocols.
How an Object Request Broker works
A client asks an object to perform an operation, usually through an object reference. The ORB locates and routes the invocation to the object’s implementation, then returns the result or response to the client. It manages communication details that would otherwise have to be handled directly by the application. The Object Management Group (OMG) describes the ORB as routing a request from client to object and routing the response back (OMG, “Object Request Broker (ORB) Basics”).
A useful analogy is a telephone exchange: it connects callers, but it cannot ensure they understand one another. Likewise, an ORB can carry an object request without ensuring that the client and server agree on the operation’s meaning or business rules (OMG, PSS 1.0 specification material).
What an ORB is—and what it is not
ORB names a middleware concept: the request-routing mechanism between clients and distributed object implementations. In CORBA, the ORB is a core component of a larger architecture and specification. CORBA also defines interoperability mechanisms and supporting interfaces; it is not another name for the ORB itself (The Open Group, CORBA V2.3; OMG, “CORBA”).
#1 Best Overall
Do not expand ORB as “Object Request Broker Architecture.” The words in that expansion belong to CORBA: Common Object Request Broker Architecture. ORBs are not necessarily CORBA implementations, though CORBA is a well-known ORB architecture.
How interfaces and invocation approaches fit in
The ORB can route an invocation only if the participants have a compatible way to describe and make it. In CORBA, OMG IDL (Interface Definition Language) describes object interfaces—the operations and data types a client can use. Code can be generated from an interface definition to provide the invocation plumbing on both sides.
Rank #2
Generated stubs and skeletons
A common approach uses generated client-side stubs and server-side skeletons. They provide the code that connects an application’s calls and implementations to the ORB. This is suitable when the interface is known when the application is built.
Free tools Windows power users keep installed
One-click scans. No signup required.
Dynamic Invocation Interface
CORBA’s Dynamic Invocation Interface (DII) allows a client to construct an invocation at run time rather than relying on a call compiled in advance. The client must obtain the relevant interface definition and build the invocation, so this approach supports dynamic use cases at the cost of additional run-time work (OMG, “Object Request Broker (ORB) Basics”).
Rank #3
How CORBA supports interoperability
CORBA specifies protocols and mechanisms intended to let ORBs communicate across systems. The CORBA V2.3 standard includes GIOP (General Inter-ORB Protocol) and IIOP (Internet Inter-ORB Protocol); OMG identifies IIOP as a CORBA interoperability mechanism (The Open Group, CORBA V2.3; OMG, “CORBA”).
Protocol compatibility is not the same as shared application semantics. Applications still need compatible interfaces, data expectations, and policies. An ORB does not invent matching operations, translate business rules, or make unrelated systems agree on what a request means. Nor does the routing abstraction make a remote call literally local: the objects remain distributed and depend on network communication.
Rank #4
What services an ORB may provide
CORBA facilities can support object references, access to interface information through the Interface Repository, and server-side object activation patterns. The exact behavior depends on the CORBA mechanisms and the ORB implementation. The CORBA V2.3 standard does not require every implementation to include every optional component: it identifies DCE ESIOP, COM/CORBA interworking, interceptors, and any particular Object Services among components that are not required (The Open Group, CORBA V2.3).
Recommended Free Tools
CORBA version context
OMG’s specification history lists CORBA 3.0 as adopted in June 2002 and includes earlier formal versions, such as CORBA 2.3.1 from October 1999. OMG also lists CORBA 3.3 specification materials. These are specification-history details, not evidence that a particular ORB implements any given revision; check the implementation’s documentation for supported versions (OMG, CORBA 3.0 specification page and history).
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
