HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML
 

CORBA - the Common Object Request Broker Architecture - is an open, vendor-independent standard for software interoperability based on object technology. You've used CORBA even if you haven't heard of it by name:

  • It's the architecture of many of the best-scaling transaction processing systems.
  • Virtually every application server on the market exposes CORBA interfaces.
  • It's the basis of Enterprise JavaBeans interoperability.
  • It's used to program many of the largest consumer e-commerce sites on the Web.
CORBA from Both Sides: Client and Server
Applications' use of CORBA objects follows a number of different patterns, depending on what their objects represent or what they do. In this article we'll concentrate on persistent objects, objects that represent something long-lived in the real world - an account at a bank or brokerage house, or a tank in a military simulation, or the shopping carts in your e-commerce Web site. Once it's created an object instance and holds its object reference (a token that represents the object's address), a CORBA client can assume that the particular object instance continues to exist, maintaining its state all the while, and the reference remains valid until the client (or some authorized agent) explicitly destroys the object. Whenever it wants, the client can make an invocation using the reference and the answer will come winging its way back across the network.

This model is great for the client (and results in an architecture with many advantages): the client's only interface to CORBA is the set of functional operations it invokes on an object; no activation, deactivation or storage operations complicate its life. When it wants to make an invocation, it just goes ahead and does it. When it doesn't...it doesn't.

If it wants, a client can hold onto an object reference for years without invoking it. Then, whenever it wants, it can send an invocation and expect that the object will be there to respond and will be in the same state in which it was left by the client's previous invocation - assuming that the object isn't shared with any other clients and hasn't been destroyed. Destruction of an object is irrevocable - once destroyed, it's totally gone and its object reference will never work again. In this article we'll discuss activation and deactivation, which are very different from creation and destruction. (If you're interested, we'll discuss creation and destruction of objects in a separate article.)

The model appears less efficient on the server side, however: Do we really have to keep all of our CORBA objects active, at least the persistent ones, on the off-chance that a client will send us an invocation at some random time? Suppose we have 10 million customers, each with his or her own shopping cart object, but only 2,000 of them are shopping now. We'd be overjoyed if the other 9 million-plus customers suddenly came back and started to shop all at once. But this is pretty unlikely, and we don't have enough computing power to run all 10 million carts at once anyhow. What can we do?

CORBA and its server-side mechanisms (known to the CORBA literati as the POA) deal with this situation by distinguishing the concept of CORBA object - the client's concept of an object that runs continuously from creation to destruction, maintaining its state all the while - from the concept of servant - a piece of running code that services an invocation. In the CORBA server-side model, object references are mapped to running code dynamically when needed - sometimes only when an invocation comes in, although there are other patterns as well. When an invocation completes, the resources it used can be freed to become available for whatever the server needs to do next. What's true is that an object is always available; what's not true is that it's always running.

This concept is necessary for scalability - the ability of a CORBA server to handle requests from millions of clients, using a reasonable number of computers. However, we've found that this concept is confusing or disconcerting to many when they hear about it for the first time. Here's a short story that illustrates, by analogy, the difference between object and servant, and demonstrates that it's perfectly possible for the client to cling to its concept of "CORBA object running all the time, waiting for me to invoke it" while the server allocates a servant for it only when an invocation needs to be serviced.

The Story
My younger son (who plays the role of the CORBA client in this story) believes in Santa Claus. Santa Claus is a fat and jolly old man who wears a red coat and pants trimmed with white fur, and travels in a sleigh pulled by eight or nine reindeer (depending on the weather), delivering toys to children around the world by jumping down chimneys and putting the toys into stockings hanging from the mantle. For a few days after Christmas, Santa recovers from this effort by soaking his feet in a hot bathtub and drinking hot chocolate. He spends the rest of the year making lists and collecting toys for the next Christmas. (This is the North American view of Santa Claus and the one we'll use in this story; if you're reading this article in another country with another view, please adopt our version for the sake of the analogy. We know that in Finland, for example, Father Christmas walks through the front door and hands presents directly to the children. If Father Christmas is also a CORBA object, his encapsulation boundary is very different from the one we're about to describe for Santa Claus!)

The Santa Claus CORBA object that my son believes in supports a single interface with a single, well-defined operation, GetPresents.

Here's the invocation:

  • Wait until December 24, in the evening. Otherwise the invocation fails and returns the WrongNight exception.
  • Find a stocking, preferably a very large one with your name on it, and hang it from the mantle above the fireplace.
  • Fill a glass with milk, and set it on the hearth beneath the stocking.
  • Cover a small plate with cookies and set it next to the glass of milk.
  • Optionally, put a note requesting specific toys next to the milk and cookies. (The milk, cookies and note are input parameters.)
  • Go upstairs to bed, and go to sleep.
Going to sleep is very important since it defines the encapsulation boundary, one of the key concepts in object orientation. Clients are not allowed to peek beyond this boundary: an object's interface is defined on it, and once the invocation has been delivered to it the invocation is in the realm of the implementation. In object orientation one reason for encapsulation is to enable substitutable implementations. Fortunately, encapsulation also enables scalability, as we'll see shortly. For the Santa Claus object, encapsulation is the only thing that allows the invocation to work at all.

But this invocation isn't going to work if we rely on the client's concept of CORBA Santa to fulfill it. Instead, we'll use the POA concept of servant - that is, some resource that gets activated and configured when needed, services a single invocation and is then released. Parents around the world will appreciate this next concept: in this story my wife and I play the role of servants. (Okay, at least in the POA sense!)

Here's how the Santa invocation executes at our house:

  • After son completes invocation, including going upstairs to bed, Mom and Dad stay up and wrap various non-Santa presents until we are sure that encapsulation requirements have been met.
  • Mom fetches bag with various small gifts, and stashes them in stocking. New England tradition requires an orange in the toe, and family tradition requires a stuffed animal reaching out from the top (even though Dad thinks son is much too old for this).
  • Dad takes the glass of milk, pours it back into the bottle, fills the glass up with eggnog and rum, grates fresh nutmeg onto the top and drinks it down.
  • While drinking the eggnog, Dad and Mom may eat a cookie or two. (Mom doesn't like eggnog.) Most of the cookies get put back into the box. Part of one gets crumbled onto the plate, which remains on the hearth.
  • Dad rinses the glass with milk to cover up the smell of the eggnog and rum, and places it back on the hearth next to the plate of cookie crumbs.
  • Dad helps Mom put the last of the toys into the stocking and hang it back up on the mantle.
  • Dad and Mom clean up the mess left over from present wrapping and all, and go to sleep.
In the morning son awakens and runs downstairs. Seeing the stocking full of toys and the empty glass and plate, he exclaims "Wow - look at all the toys. Santa Claus must be real - he left all these toys, and drank the milk and ate the cookies!" And from his point of view this is true: CORBA Santa accepted the input parameters (milk, cookies, optional note) and delivered the expected return value (toys). Son's point of view is undisturbed in spite of its conflicts with the reality of the implementation hidden beneath the encapsulation layer.

What Have We Learned?
Let's go over the CORBA lessons from this story.

  1. Client and server can have totally different viewpoints of the object implementation, but as long as invocations get serviced according to the agreed-upon definition of the interface syntax and semantics, this inconsistency doesn't matter.

    In the story, son thinks that Santa is real and always exists, as we described at the start. In reality, the Santa Claus servant comes into being for only a few minutes a year - on Christmas Eve, when it's needed.

    In CORBA the client holds an object reference and acts as if the object always exists, making an invocation anytime it wants and assuming that the object will maintain its state from one invocation to the next regardless of the time that elapses between invocations. In reality, in POA-based systems, computing resources may not be allocated for an object until an invocation comes in and may be freed as soon as the invocation has completed. State is maintained on persistent storage between invocations, loaded on activation and stored again with any changes on completion.

  2. There's a lesson here on scalability as well: the story about the jolly fat guy in the red suit may be charming, but as an implementation architecture it just doesn't scale. Too many kids need presents on the same night for any one person to distribute them all, especially a fat old guy who obviously doesn't keep in shape during his off-season, and the year between Christmases is too long for such a resource (even out of shape) to sit around unused. The POA-based implementation, however, doesn't have either of these problems: every household (well, almost) has a resource that can play the role of Santa Servant on one night a year, so there's no problem scaling to any number of households. And the resource is flexible enough to play other servant roles during the rest of the year, whenever the household POA requires it.
The object-oriented principle that enables this is encapsulation: the implementation is encapsulated beneath a boundary that the client is not allowed to penetrate.

It's been common to suggest that implementation details such as algorithm and coding reside on the far side of this boundary and may change unbeknownst to the client. With the POA, CORBA now allows a resource allocation infrastructure - which may be massive, supporting a huge enterprise application or a worldwide e-commerce shopping site - to lurk beneath this boundary.

The CORBA Component Model, the newest piece of CORBA 3, defines a standard server-side architecture based on the POA with an easier-to-program environment that's integrated with Enterprise JavaBeans. It has all of the architectural advantages we described in the foregoing short story.

Where to Learn More
The CORBA standard is written and maintained by the members of the nonprofit Object Management Group (OMG); all of the group's standards are available from OMG's Web site (www.omg.org) free of charge. Products implementing the standard are available from more than 70 sources ranging from most of the best-known companies in the computer industry to small independents, R&D labs and academic institutions. For more information visit the Web site at the URL above, pick up a copy of my book, CORBA 3 Fundamentals and Programming, or send an e-mail to info@omg.org.

Author Bio
Jon Siegel, Object Management Group's director of technology transfer, presents tutorials, seminars and company briefings around the world. He has extensive experience in distributed computing, OO software development and geophysical computing. Jon holds a Ph.D. in theoretical physical chemistry from Boston University.
He can be reached at: siegel@omg.org

 

All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: info@sys-con.com

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.