This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I saw a situation where I used to work where the invocation of EJBhome was without PortableRemoteObject. Something like:
it was exactly like this (with the comment included). I was browsing to this code when I saw this and remembered that when using local interfaces you don't need to do narrow (correct me if I'm wrong). But this wasn't anything related to local interfaces, it was all remote, so it should (must) use PortableRemoteObject. The funny thing is that the comment was exactly like that. The code works and they gave me the explanation of why they didn't use it. Before posting the answer, I'd like to know your opinions of why it worked, or why PortableRemoteObject couldn't be use (if that was the case ).
I'm not going to be a Rock Star. I'm going to be a LEGEND! --Freddie Mercury
May i read out from the section 6.10 of EJB 2.0 spec. "Programs using the cast operator for narrowing the remote and home interfaces are likely to fail if the container implementation uses RMI-IIOP as the underlying communication transport" The code would have worked because the server implemented a protocol which understood java casting but the code might not be portable to another container.
Hi Andres, If the underlying implementation of EJB by a particular vendor is based on RMI and not RMI/IIOP then there is no need to use PortableRemoteObject. This method is used only when the protocol is RMI/IIOP for interoperability .So i guess in the code which you are talking off it could be pure RMI protocol based implementation of EJB Rishi SCJP,SCWCD, IBM OOAD
Originally posted by Sivasundaram Umapathy: The code would have worked because the server implemented a protocol which understood java casting but the code might not be portable to another container.
Hmmm, not happy with that explanation. Casting is when you don't use PortableRemoteObject.narrow(Object, Class). So this would be the example of casting for Andres' code:
And that would work if you are using RMI-JRMP as the underlying protocol for your remote connectivity. Now I don't know if Andres' code is faulty or not, but this is not what he had. Andres is showing two parameters (the Object and the Class) as though it was within a call to PortableRemoteObject.narrow(). So this just looks wrong.
Originally posted by Andres Gonzalez: The code works and they gave me the explanation of why they didn't use it. Before posting the answer, I'd like to know your opinions of why it worked, or why PortableRemoteObject couldn't be use (if that was the case ).
Well you have my opinion on why my code above would work, but not why your code would work. Care to comment on whether your code is really correct (in which case I suspect you are hiding something from us (can't trust these Queenslanders )) If my code is correct, then you should be able to use PortableRemoteObject.narrow(). Furthermore you should use PortableRemoteObject.narrow(), since as Sivasundaram pointed out, what they are using is prone to breaking if the underlying protocol changes. Regards, Andrew [ October 31, 2003: Message edited by: Andrew Monkhouse ]
Now I don't know if Andres' code is faulty or not, but this is not what he had. Andres is showing two parameters (the Object and the Class) as though it was within a call to PortableRemoteObject.narrow(). So this just looks wrong. Well you have my opinion on why my code above would work, but not why your code would work. Care to comment on whether your code is really correct (in which case I suspect you are hiding something from us (can't trust these Queenslanders )) [ October 31, 2003: Message edited by: Andrew Monkhouse ]
. Yes, you are right, my code is *not* correct. Apologies for that. I just put up an example from what I could remember, and copied that line from the EJB spec . I think the correct code is something like this:
Howdy all, As far as the exam is concerned, you must ALWAYS use PortableRemoteObject.narrow() before casting a Remote interface, for which the declared return type is not the component interface type. So, that means the result of a JNDI lookup on the Home, or a call to getEJBObject from a Handle. You don't have to narrow anything else. An you must NEVER use PortableRemoteObject.narrow() on a local interface. Now, does this mean that it will always fail if you do NOT narrow the result of a Remote home lookup? No, for the reasons you already mentioned... the container may be using plain old Java RMI stubs (as opposed to Corba stubs). But remember, the exam is NOT concerned with what *might* work, but only with what is *guaranteed* to work. So you are to assume that you must always do something, if it is mandated in the spec, even if a particular Container implementation might work differently. Always go by the spec, and NEVER by a vendor-specific implementation difference, and you'll be fine on the exam. cheers, Kathy
Joined: Nov 27, 2001
Originally posted by Anselm Paulinus: Andres: Enough of the hide and seek game. What was the reason for not using portableRemoteObject.narrow()
ok, ok...Well, the answer they gave me is that they were using jdk 1.1, so they couldn't use PortableRemoteObject. I've been trying to find documentation on when this class was added, but can't find the @since tag.. If anyone knows please let me know; I'm still not satisfied with their response...
Joined: Sep 05, 2003
Hi all: Does anybody know if portableRemoteObject was in EJB 1.0 ? I really doubt, I think it was introduced in EJB 1.1.
some more info-- EJB 2.0 and 1.1 define an enterprise bean's remote interfaces in terms of Java RMI-IIOP which enforces complince with CORBA In Java RMI-IIOP the narrow() method is used only when a remote ref to an EJB home or EJB obj is returned WITHOUT A SPECIFIC Remote interface type. 1--jindicontext.lookup(); 2--when a Remote EJB obj ref is obtained from a Collection or Enumeration returned by a remote home interface finder method. 3--when a EJB obj ref is obtained using getEJBObject() ----Handle 4--getEJBHome()----HomeHandle 5-EJBMetaData.getEJBHome(); 6--when a wide remote EJB obj type is returned from any business method.
This method(narrow) is not required when remote type is SPECFIED in the method signature for example create and find methods in the remote interfaces that return a single bean. findByPrimaryKey(); //does not require narrow()
<i>Dare to dream - everything that exists today,was once a figment of someone's imagination, nobody says tomorrow can't be a figment of your today.</i>