Object Request Broker

By Kurt Wallnau, SEI
John Foreman, SEI

We recommend Middleware, as prerequisite reading for this technology description.

Purpose and Origin

An object request broker (ORB) is a middleware technology that manages communication and data exchange between objects. ORBs promote interoperability of distributed object systems because they enable users to build systems by piecing together objects- from different vendors- that communicate with each other via the ORB. The implementation details of the ORB are generally not important to developers building distributed systems. The developers are only concerned with the object interface details. This form of information hiding enhances system maintainability since the object communication details are hidden from the developers and isolated in the ORB.

Technical Detail

ORB technology promotes the goal of object communication across machine, software, and vendor boundaries. The relevant functions of an ORB technology are

• interface definition
• location and possible activation of remote objects
• communication between clients and object

An object request broker acts as a kind of telephone exchange. It provides a directory of services and helps establish connections between clients and these services. Figure 1 illustrates some of the key ideas.

Figure 1: Object Request Broker

The ORB must support many functions in order to operate consistently and effectively, but many of these functions are hidden from the user of the ORB. It is the responsibility of the ORB to provide the illusion of locality, in other words, to make it appear as if the object is local to the client, while in reality it may reside in a different process or machine. Thus the ORB provides a framework for cross-system communication between objects. This is the first technical step toward interoperability of object systems.

The next technical step toward object system interoperability is the communication of objects across platforms. An ORB allows objects to hide their implementation details from clients. This can include programming language, operating system, host hardware, and object location. Each of these can be thought of as a "transparency," and different ORB technologies may choose to support different transparencies, thus extending the benefits of object orientation across platforms and communication channels.

There are many ways of implementing the basic ORB concept; for example, ORB functions can be compiled into clients, can be separate processes, or can be part of an operating system kernel. These basic design decisions might be fixed in a single product; or there might be a range of choices left to the ORB implementer.

There are two major ORB technologies:

• The Object Management Group's (OMG) Common Object Request Broker Architecture (CORBA) specification
• Microsoft's Component Object Model (see Component Object Model (COM), DCOM, and Related Capabilities)

A high-level comparison of ORB technologies is available in Table 1. Details are available in the referenced technology descriptions.

Usage Considerations

Successful adoption of ORB technology requires a careful analysis of the current and future software architectural needs of the target application and analysis of how a particular ORB will satisfy those needs. Among the many things to consider are platform availability, support for various programming languages, as well as implementation choices and product performance parameters. After performing this analysis, developers can make informed decisions in choosing the ORB best suited for their application's needs.

Table 1: Comparison of ORB Technologies

ORB	Platform Availability	Applicable to	Mechanism	Implementations
COM/ DCOM	originally PC platforms, but becoming available on other platforms	"PC-centric" distributed systems architecture	APIs to proprietary system 2	one 3
CORBA	platform- independent and interoperability among platforms	general distributed system architecture	specification of distributed object technology	many4
Java/ RMI	wherever Java virtual machine (VM) executes	general distributed system architecture and Web-based Intranets	implementation of distributed object technology	various5

Maturity

As shown in Table 1, there are a number of commercial ORB products available. ORB products that are not compliant with either CORBA or OLE also exist; however, these tend to be vendor-unique solutions that may affect system interoperability, portability, and maintainability.

Major developments in commercial ORB products are occurring, with life cycles seemingly lasting only four to six months. In addition, new ORB technology (Java/RMI) is emerging, and there are signs of potential "mergers" involving two of the major technologies. The continued trend toward Intranet- and Internet-based applications is another stimulant in the situation. Whether these commercial directions are fully technically viable and will be accepted by the market is unknown.

Given the current situation and technical uncertainty, potential users of ORB technologies need to determine

• what new features ORB technologies add beyond technologies currently in use in their organizations
• the potential benefits from using these new features
• the key risks involved in adopting the technology as a whole
• how much risk is acceptable to them

One possible path would be to undertake a disciplined and "situated" technology evaluation. Such an evaluation, as described by Brown and Wallnau, focuses on evaluating so-called "innovative" technologies and can provide technical information for adoption that is relative to the current/existing approaches in use by an organization. Such a technology evaluation could include pilot projects focusing on model problems pertinent to the individual organization.

Costs and Limitations

The license costs of the ORB products from the vendors listed above are dependent on the required operating systems and the types of platform. ORB products are available for all major computing platforms and operating systems.

¹ transparency: making something invisible to the client

² COM/DCOM specifications have been turned over to the Open Group, but the outcome of this standardization activity remains unclear.

³ Microsoft maintains the only implementation of PC platforms, and is working closely with selected vendors to migrate technology to alternate platforms.

⁴ Examples include ORBIX by IONA Technology, NEO by SunSoft, VisiBroker by VisiGenic, PowerBroker by Expersoft, SmallTalkBroker by DNS Technologies, Object Director by Fujitsu, DSOM by IBM, DAIS by ICL, SORBET by Siemens Nixdorf, and NonStop DOM by Tandem.

⁵ Implementations of the Java VM have been ported to various platforms.