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
.

Page 2 of 5

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:

  1. Server processes to start only when their services (that is, objects within them) are required. Most implementation repositories also have a shutdown time, after which a server process will shut down if it is not being used.
  2. Fault tolerance and server relocation. As long as the implementation repository is running on the same host and port, servers can be relocated at will.


Transient objects

Transient objects are short-lived objects tied to the lifetime of the process, and more specifically the POA, that created the object.

  • Print
  • Feedback

Resources