Newsletter sign-up
View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

JavaWorld.com > Java Standard Edition >

J2SE 1.4 breathes new life into the CORBA community, Part 2

Gain code portability with the Portable Object Adapter

By Tarak Modi, JavaWorld.com, 09/27/02

  • Print
  • Feedback
.

An object adapter is the primary interface that an implementation uses to access ORB (object request broker) functions. It serves as the glue between the server applications (objects) and the ORB. An object adapter:

  • Generates and interprets object references
  • Authenticates the principal making the call
  • Activates and deactivates the implementation
  • Activates and deactivates individual objects
  • Invokes methods through skeletons


Until CORBA 2.2, all ORB implementations supported a Basic Object Adapter (BOA) defined by the CORBA specification. However, the BOA suffers from one major weakness: it is vaguely defined. As a result, each vendor implemented their BOAs differently with specific value-added services, thus producing code and implementation incompatibilities. Note that these incompatibilities are not the same as inter-ORB incompatibilities produced during runtime. The IIOP (Internet Inter-Orb Protocol) specification and the mandate that all CORBA 2.0-compliant ORBs support IIOP address most inter-ORB compatibility issues. The incompatibilities created by varying BOA implementations are either compile errors or the more subtle (and worse) errors caused by the application's behavioral differences; for example, corruption can result from improper thread synchronization when one vendor's BOA is thread safe while another vendor's BOA is not. Other examples include performance problems, scalability issues, and even race conditions due to varying thread management algorithms in different BOAs.

The OMG (Object Management Group) introduced the Portable Object Adapter (POA) to replace BOA in CORBA 2.2. The POA specification details the precise POA architecture and operation characteristics; its tone proves more mandatory than suggestive. The bottom line: An object adapter implementation should result in code (and, probably more important, skill) portability across ORBs. In fact, the CORBA specification lists that aspect as one of the top success factors in the POA design.

As part of this four-part series on enterprise CORBA development, in this article, I begin exploring J2SE (Java 2 Platform, Standard Edition) 1.4's POA support.

Read the whole series, "J2SE 1.4 Breathes New Life into the CORBA Community:"



The CORBA object lifecycle within the POA context

To start, let's go over the differences between a CORBA object, an object reference, and a servant.

The object concept is probably one of the most overloaded, overused, and yet vague concepts in software engineering. In the CORBA world, an object is a programming entity with an identity, an IDL (interface definition language)-defined interface, and an implementation. An object is an abstract concept and cannot serve client requests. To do so, an object must be incarnated or given bodily form—that is, its implementation must be activated. The servant gives the CORBA object its implementation. At any moment, only one servant incarnates a given object, but over an object's lifetime, many (different) servants can incarnate the object at different points in time. Examine Figure 1 to get a better feel for these concepts.

  • Print
  • Feedback

Resources