PortableRemoteObject.narrow() must die

9 PM April 3, 2003

Today, while peacefully coding EJBs, I found myself writing code using the dreaded PortableRemoteObject.narrow() again. Charles "Fischkopf" Miller went into some detail about how painful this is in one of his recent blog entries. But in case you haven't experienced the exquisite clunkiness of PortableRemoteObject.narrow(), here is a code sample:

  // Get a bunch of things

  Collection collection = 


  Iterator iter = collection.iterator();

  // Take the first one

  PolicyOptionGroup policyOptionGroup =

      (PolicyOptionGroup) PortableRemoteObject.narrow(



The call to PortableRemoteObject.narrow() is required because the objects in the collection returned by the finder do not actually implement PolicyOptionGroup interface. Which is surprising, if you think about it. If they did implement the PolicyOptionGroup interface, we could write the more idiomatic:

  PolicyOptionGroup policyOptionGroup = 

      (PolicyOptionGroup) iter.next();

(Which is quite long-winded enough in itself, but that is the subject of another blog entry.)

Based on the comments to Charles' blog entry by Thomas Roka-Aardal and Bob Lee, there is a good reason for this verbosity. It goes like this: EJBs use RMI, RMI is transported by IIOP - the CORBA protocol - and the existing CORBA libraries cannot possibly be wrapped or modified for the convenience of EJB programmers.

In other words, this ugliness is caused by exposing an implementation choice that is at least two steps removed from my EJB code. And the benefits? The only two offered are:

  1. RMI IIOP allows CORBA applications to call RMI applications. So what? Can CORBA clients call EJB servers or vice versa? Who has done that in a "real" application? (These are not rhetorical questions - if you know the answer, please comment!) Even CORBA - EJB calls are possible and are used, how much benefit is it developers overall?
  2. Exposing the CORBA like this allows them to be reused. Fine. Good argument. I'm all for reuse. But please, let's wrap the ugly details.

Surprisingly, Bob Lee - in his comment on Charles' blog arguing the case for PortableRemoteObject.narrow() - pointed out that it was possible to hide the call to PortableRemoteObject.narrow() from EJB client code. Excellent. Let's do it and knock out "2 lines" of code (plus method declarations) per finder per EJB client.

By alang | # | Comments (1)
(Posted to Software Development)


At 05:59, 24 Sep 2004 venkatesh wrote:

When you execute a lookup to get the home interface of your bean, you normally use the lookup() method of the javax.naming.Context interface.
This method will return you an Object that needs to be casted to the home interface you've asked for. Unfortunately, this cannot be done using the normal/explicit casting [MyHome myHome = (MyHome)returnedObject].
As you have already found out, the reason is connected to CORBA. Why?
For EJB, the communication between the server and the client is based on RMI (both remote and local interfaces, in fact, do implements the java.rmi.Remote interface).
The underlying protocol that it is used for the communication is IIOP (I think 1.2), that is part of CORBA standards. It is normally used to describe this communication system using the Java RMI over IIOP.

IIOP has not been designed for Java, but for generic languages, and this means that there are some limitations. Some languages, in fact, do not have the concept of casting.
Java RMI-IIOP provides a mechanism to narrow the the Object you have received from from your lookup, to the appropriate type. This is done through the javax.rmi.PortableRemoteObject class and, more specifically, using the narrow() method.

Just a note: when you are using the new EJB 2.0 Local Client API, you should be able to do a direct/explicit cast from the looked up Object, to the interface you need.


Add Comment

(Not displayed)

(Leave blank line between paragraphs. URLs converted to links. HTML stripped. Indented source code will be formatted with <pre> tags.)

© 2003-2006 Alan Green