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 3 of 5

A transient CORBA object's object reference has the same information as a persistent CORBA object's object reference, with the only difference being the POA name contained within it. A POA that creates transient objects, a transient POA, has a name unique in space and time with respect to all POA names. When a POA becomes a transient POA, the ORB prefixes or appends a UUID (universally unique ID) to the original name the POA received during its initial creation. As you will learn later in the discussion on POA creation and policies, a POA can create either persistent or transient references, but not both.

Some salient features about binding with transient objects:

  • Transient objects always use direct binding.
  • If the process that created the reference shuts down, then:
    • A TRANSIENT error returns if no server process is running.
    • An OBJECT_NOT_EXIST error returns if a server process, even the original one, is running. Why? Because, each time a transient POA is created, the ORB creates a new unique name for it. Therefore, the POA name contained in the previously created object reference will not exist, and hence, the object will not exist.


Basic POA programming

Programming with POA is fairly straightforward. In this section, I explain the fundamentals of programming CORBA applications using POA. For examples, I refer to the Hello World application from Part 1.

Obtain the RootPOA

All ORBs have one POA called RootPOA. You obtain a reference to this POA the same way you obtain a reference to any other service managed by the ORB—use the resolve_initial_references() method on an initialized ORB instance and pass RootPOA as the name of the service to resolve. The first few lines of code in the HelloServer class demonstrates how to obtain a RootPOA reference: 

      .
      .
      .
      // Create and initialize the ORB
      //ORB orb = ORB.init(args, null);
      ORB orb = ORB.init(args, System.getProperties());
      // Get reference to RootPOA 
      POA rootPOA = POAHelper.narrow(orb.resolve_initial_references("RootPOA")); 
      .
      .
      .


Create new POAs

Once you have a reference to the RootPOA, you can create any other POAs you desire. POAs form a tree hierarchy with the RootPOA as the tree's root node. Look at Figure 2's POA hierarchy.

Figure 2. A sample POA hierarchy

As expected, the RootPOA is at the top of the hierarchy. POAs A and B have been created directly from the RootPOA, and as a result, are its children. POA C is a direct child of POA A. Here's the code that would create that hierarchy: 

      .
      .
      .
      // rootPOA is a reference to the Root POA
      POA A = rootPOA.create_POA("A",null,null);
      POA B = rootPOA.create_POA("B",null,null);
      POA C = A.create_POA("C",null,null);
      .
      .
      .


The Hello World example did not use a POA hierarchy, but Part 3's Bank example will, albeit a simple hierarchy.

Specify POA policies

One reason you create POA hierarchies is to create POAs that have different policies. In fact, one of the POA architecture's best features is that it allows the object implementer much more control over the object's identity, state, storage, and lifecycle. The POA architecture allows control over the following aspects/characteristics (we explore the details later):

  • Print
  • Feedback

Resources