Entering ORB-it - object request broker; Object Management Group's Common Object Request Broker Architecture - includes related article on Corba-compliant ORBs - Technology Information

Software Magazine, Jan, 1997 by Julie Bort

Distributed object management may finally get off the ground thanks to Corba 2.0 and a suporitng cast of object request brokers

Object-oriented programming is a natural fit for distributed environments. But when it comes to managing distributed objects, some major issues arise. What happens if an object is created in one part of the network but is useful in dozens of systems all over the enterprise? Do you replicate it? Do you rewrite it, and therefore defeat its purpose as a reuse vehicle? How can you make sure that multiple object management systems will work with one another?

Today, many of these issues are addressed by the object request broker (ORB), a piece of middleware that tracks the access and use of objects in a distributed environment. ORBs have been a labor of love for the Object Management Group (OMG), Framingham, Mass., a standards body created in 1989 to promote object-oriented computing. The group, which now comprises 500 members, has arguably contributed the crown jewel of distributed computing -- the Common Object Request Broker Architecture (Corba) -- to its broader Object Management Architecture (OMA) standard.

According to Katarzyna Keahey, professor of computer science at Indiana University in Bloomington, Ind., the OMA consists of four components, which can be divided into system-oriented components (object request brokers and object services), and application-oriented components (application objects and common facilities). Of these parts, the ORB is the one that constitutes the foundation of OMA and manages all communication between its components. It allows objects to interact in a heterogeneous, distributed environment, independent of the platforms on which these objects reside and techniques used to implement them.

According to some industry observers, Corba 2.0 -- the latest version of the OMG's ORB specification -- at last defines a solid mass of services that may help object-oriented development deliver on its promise. "Corba is a very well-defined suite of 16 to 20 services such as security, transactions, events and database integration. It includes a very good description of what needs to be done," says Rick Berzle, vice president of marketing at Expersoft Corp., a San Diego-based ORB vendor. Better yet, this spec means that interoperability between ORBs used in the same enterprise becomes feasible.

"There are many different ORB products currently available," says Keahey of Indiana University. "This diversity is very wholesome since it allows the vendors to gear their products towards the specific needs of their operational environment. It also creates the need for different ORBs to interoperate. "This is why Corba 2.0 introduces the higher-level concept of a domain, which roughly denotes a set of objects that for some reason, be it implementational or administrative, are separated from some or all other objects," she says.

The significance of Corba, say end users, is that it's a standardized middleware development platform. This is not the case with some competing middleware technologies, such as messaging, in which vendors offer proprietary technology and different services. "In a world where everyone has their own proprietary APIs, a standard means something. That's why we look favorably at ORBs," says Steve Belmont, product manager of integrated SIMM systems for Motorola in Tempe, Ariz., and a user of messaging technology. The company is currently evaluating a move to ORBs, says Belmont, in part because of this standardization. With standards in place, he explains, "it's a lot easier to find best-of-class [products]."

Not surprisingly, vendors have been working hard to offer ORBs based on Corba 2.0. Among the products that have entered the marketplace in the last couple of years are PowerBroker from Expersoft Corp.; ObjectBroker from Digital Equipment Corp., Maynard, Mass.; Orbix from Iona Technologies Inc., Cambridge, Mass.; SmalltalkBroker from DNS Technologies Inc., San Francisco; the Chorus/Cool ORB from Chorus Systems Inc., Campbell, Calif.; and VisiBroker from Visigenic Software Inc., San Mateo, Calif.

Still, a standard and a bunch of vendors do not a commodity make. For one thing, no one is conducting compliance testing to ensure that vendors are complying with the services in Corba or that they are implementing them correctly. "When the vendor says that ORBs are Corba-compliant, are they? Not necessarily," says John Strand, director of technology planning and integration for Sprint in Overland Park, Kansas. "They are all different services competing against each other. Some have pretty good adherence to the specification, but that's hard to tell," Strand says. Currently, Sprint uses ORBs for a custom-developed hardware management application that oversees the telecom's disparate hardware systems.

The OMG is working to address the lack of compliance testing for Corba-supported products with a compliance testing program targeted for Q3/97, says Cheryl Rocheleau, senior marketing specialist for the group. However, this means that for the next twelve months or so, the situation remains 'buyer beware.'