More action with Struts 2
In a recent review of Struts 2 in Action, JW Blogger Oleg Mikheev notes that Struts 2 is "just a collection of extensions built upon WebWork, which is ultimately the right thing to learn before starting a Struts 2 project." While Struts 2 has some architectural flaws, Oleg calls WebWork well-designed, well-tested, and reliable. What are your experiences using Struts 2 and WebWork?

Also see "Hello World the WebWork way," a JavaWorld excerpt from WebWork in Action, by Patrick Lightbody and Jason Carreira.

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
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

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.

Figure 1. The CORBA object lifecycle

Note the following regarding Figure 1:

  1. The terms creation and destruction apply to objects, while the terms incarnation and etherealization apply to servants.
  2. Once an object is created, it can alternate between many activations and deactivations during its lifetime.
  3. To serve requests, an object must:
    • Be activated if it is not active.
    • Be associated with a servant if it does not already have one. Just because an object is active does not mean that it has an associated servant. As you will see later, you can configure/program the POA to use a new servant upon request.
  4. Once an object is destroyed, it ceases to exist, and no more requests to that object will be served.


A client views a CORBA object as an object reference. The fact that a client has an object reference does not mean that a servant is incarnating the object at that time. In fact, the object reference's existence does not indicate an object's existence. If the object does not exist (that is, it has been destroyed), the client will receive an OBJECT_NOT_EXIST error when it tries to access the object using the object reference. However, as noted above, if the object is in a deactivated condition, it will activate, a process transparent to the client.

Based on their lifetime characteristics, CORBA objects are either persistent or transient.

Persistent objects

A persistent object is a CORBA object that can live beyond the process that creates or activates it. The object reference for a persistent CORBA object has the following information:

  • The name of the POA that created it
  • The object's object ID
  • The host name (address) and port number


The host name and port number may be the server's or an implementation repository's (such as ORBD (Object Request Broker Daemon), which is provided with J2SE 1.4). If the host name and port number belong to the server, then the process of locating the server based on the object reference is called direct binding. J2SE 1.4 does not support direct binding for persistent objects. Although direct binding proves efficient, it has two major drawbacks:

  1. The server must be up and running (and listening for binding requests, which the ORB runtime handles). Therefore, the server consumes system resources, such as CPU time and memory, even if no clients are interested in it. Note: If the server is not up and running, the client will not receive an OBJECT_NOT_EXIST error, but rather a TRANSIENT error, which basically means try back later.
  2. The server must always run on the same host and listen to the same port. Direct binding does not intrinsically support failover and relocation of the CORBA object.


An implementation repository such as ORBD allows:

Resources