why EJB's narrowed using PortableRemoteObject

why EJB's narrowed in the following mannor:

InitialContext ctx = new InitialContext();
Object obj = ctx.lookup(SomeObject);
SpecificObject so = (SpecificObject) PortableRemoteObject.narrow(obj, SpecificObject.class);
LVL 20
chaitu chaituAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Because EJB must also support CORBA reference objects that cannot be cast by Java native casting.
chaitu chaituAuthor Commented:
i didnt getu;

can u explain in detail
EJB obejcts can be transported by using RMI over IIOP protocol (RMI/IIOP). The RMI is used to transport Java object where Interent Inter-ORB Protocol is used to transport CORBA objects. IIOP is a generic protocol and does not have the concept of casting as it is in Java. Therefoer you will need to cast the references you receive over IIOP somehow. That's why you use the PortableRemoteObject.narror() method. For more information you might want to take a look here: http://www.jguru.com/faq/view.jsp?EID=734137
Cloud Class® Course: Microsoft Windows 7 Basic

This introductory course to Windows 7 environment will teach you about working with the Windows operating system. You will learn about basic functions including start menu; the desktop; managing files, folders, and libraries.


we can either do a context.lookup or a PortableRemoteObject.narrow.
In which situations would u use one over the other.  Which is the best solution to use?

Let's start to clarify understanding EJB.

We can access EJB in two ways. One is by local interface and another is by remote interface. The different between local and remote interface is listed below

The benefit of remote interface is that it allow you to invoke a method on EJB over the network by using RMI(Remote Method Invocation). Sometime the invoked EJB is deployed on the same machine with the invoking EJB. So it does not make sense to call it over RMI which will have overhead in calling. To optimize this, Local interface allow us to access to an EJB by bypassing RMI. But we should keep in mind that local interface only work when EJB is located in the same application so it disallows load-balancing and failover feather.

Ok. back to your question.
We use PortableRemoteObject.narrow() when we write a client program(java application or another ejb) to access local objects(local interface is a subinterface of EJBLocalObject)

Here is an example for local interface.

HelloWorldLocalHome home =
HelloWorldLocal hello = home.create();

And Here is an example for remote interface.

HelloWorldHome home =
  (HelloWorldHome)PortableRemoteObject.narrow(ctx.lookup("HelloWorld"), HelloWorldHome.class);
HelloWorld hello = home.create();

you will have clear idea...

> We use PortableRemoteObject.narrow() when we write a client program(java
> application or another ejb) to access local objects(local interface is
> a subinterface of EJBLocalObject)

You mean *remote* objects I guess.
After looking up our remote object, we do a very strange operation: javax.rmi.PortableRemote Object.narrow(). This is a static method on an RMI-IIOP class called PortableRemoteObject. This method casts the generic object that we looked up via JNDI to our RMI-IIOP interface type. This narrow() operation is required whenever you lookup an RMI-IIOP object via JNDI. Why do we need it, and why don’t we just cast it using a regular Java cast? The short answer is CORBA interoperability.

When you receive an object using Java RMI, you can simply cast it into the desired object using a Java cast. This is possible because RMI
automatically downloads the appropriate stub for the object you’re dealing with. CORBA, however, does not have a mechanism for  automatic stub downloading.

When using RMI-IIOP, you cannot simply cast an object you receive over the network, because the stub class file may not exist on the
client machine. RMI-IIOP does not allow downloadable class files because CORBA does not mandate support for this feature. Thus, you must perform a safe cast by explicitly calling the javax.rmi.PortableRemoteObject.narrow() method. This static method converts an object into the desired remote interface type for you. You pass narrow() the object you desire to cast, and the class to which you wish to cast it. The narrow() method returns the resultant object or throws an exception if the narrow is not possible, perhaps because the class does not exist.

In the end, a compromise was reached. J2EE server vendors are allowed to use other protocols besides IIOP. However, they need to support IIOP in case interoperability is required with CORBA systems. That is the irony of the phrase RMI-IIOP —it does not necessarily mean usage of the IIOP protocol. Rather, it means standardizing on the PortableRemoteObject.narrow() method.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Java EE

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.