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 3

Create enterprise-level apps with the POA

By Tarak Modi, JavaWorld.com, 10/25/02

  • Print
  • Feedback
.

If you are just tuning in, we're in the midst of a four part series on the enterprise CORBA features included in J2SE (Java 2 Platform, Standard Edition) 1.4. Part 1 provided a whirlwind tour of those new features. That article ended with a quick Hello World example to set the stage for Part 2, which detailed the Portable Object Adapter (POA), introduced in CORBA 2.2 to replace the Basic Object Adapter (BOA). I also delved into the mechanics behind Part 1's Hello World example. In this article, I show how to apply the knowledge you've gained about the POA to create an enterprise-level application. In the process, we look at how the POA enables us to create high performance, and highly scalable and available applications.

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



All ORBs (object request brokers) have a default POA called the RootPOA. You obtain a reference to the POA just as you would a reference to an ORB service such as the naming service, that is, via the resolve_initial_reference() method on the ORB instance. As you recall, each POA has an associated set of policies that govern its various characteristics, such as object reference lifetime, object ID uniqueness, and servant management. The POA specification (part of the CORBA specification) specifies a set of policies that all RootPOAs must have. Most large-scale projects typically require POAs with policies that differ from the RootPOA's, which mandates new POA creation. To create a new POA, you need a reference to an existing POA, hence, you will always need to resolve a reference to the root POA, regardless of whether you will create object references with it. And finally, POAs observe a tree relationship similar to XML elements in the DOM (Document Object Model), with the RootPOA as the tree's root element.

An example: The CORBA bank

To put into perspective the various aspects of using a POA to create a more complex application (and to avoid boring you to death with theory), I will discuss a bank application. Using this application, a bank employee must:

  1. Create a new account
  2. Close an existing account
  3. Perform basic operations on existing accounts, such as deposits, withdrawals, and balance checks


Define the IDL

Let's start by defining what our bank example's programming/implementation language-independent IDL (interface definition language) will look like. The IDL will consist of the following elements:

  1. An enumeration that defines the different account types
  2. A structure that defines the search/creation criteria for an account
  3. Exceptions for different situations such as invalid account numbers and invalid account operations
  4. The Account interface definition that contains methods to allow deposits and withdrawals, and an attribute to allow retrieval of an account balance
  5. The Bank interface definition that contains methods to open, close, and find accounts


The complete IDL definition is shown below:

  • Print
  • Feedback

Resources