This week's book giveaway is in the OCMJEA forum.
We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line!
See this thread for details.
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes Question from ejbCertificate Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "Question from ejbCertificate" Watch "Question from ejbCertificate" New topic
Author

Question from ejbCertificate

Goan Balchao
Ranch Hand

Joined: Mar 25, 2002
Posts: 93
Identify how a client can obtain a reference to an existing entity object's remote interface?
One of the answers : Execute a home business method that returns the reference.
Is this a valid scenario. Correct me if I am wrong. I think it is possible for a home business method to call a finder and return the reference. But would this happen ?
From the spec :
A client can get a reference to an existing entity object's remote interface in any of the following ways:
Receive the reference as a parameter in a method call.
By using a finder method defined in the entity bean's remote home interface.
By obtaining the reference from the entity object's handle.
So it technically satisifes the first reason.
Is this what the author implied ?


Hemant Kamat<br />SCJP2<br />SCWCD<br />SCBCD<br />SCEA-I
Reid M. Pinchback
Ranch Hand

Joined: Jan 25, 2002
Posts: 775
Yes, a home business method can return an object reference (spec section 10.6.6, pg 193). However it has to be careful to not expose local object references to remote clients.
From my own digging through the spec, I'm pretty sure that the container doesn't automatically determine if it should hand out local or remote references according to the type of interface the client uses (unlike ejbFind<METHOD>s, which are handled appropriately automatically). That means that if you want to provide the same kind of functionality via a home business method in both local and remote homes, you'll need two different methods.


Reid - SCJP2 (April 2002)
Goan Balchao
Ranch Hand

Joined: Mar 25, 2002
Posts: 93
Thanks Reid.
k space
Ranch Hand

Joined: Jun 25, 2002
Posts: 104
From my own digging through the spec, I'm pretty sure that the container doesn't automatically determine if it should hand out local or remote references according to the type of interface the client uses (unlike ejbFind<METHOD>s, which are handled appropriately automatically). That means that if you want to provide the same kind of functionality via a home business method in both local and remote homes, you'll need two different methods.

Hi Reid,
I do not agree with what you quoted. The idea of local interface was designed for light weight access. If the container does not know, then who knows.
Firstly, you cannnot mix both local and remote methods in one single home. At the time the client does a look up through JNDI, the type of interface (local or remote) is already determined - remember all the home/remote and local-home/local tags in the deployment descriptor.


SCEA | SCBCD | SCWCD | SCJP - The kSpace
Goan Balchao
Ranch Hand

Joined: Mar 25, 2002
Posts: 93
Hi wong,
I think what Reid was referring to was the specific case for "home business methods" in relation to my question. I think you have taken the question out of context.
For the home business methods, since they can have arbitrary return types, a home business method on the remote home could potentially and purely speaking from a technical perspective return a local interface type. What Reid was alluding to was the fact that unlike the finder's where the Container does the conversion and would detect the "error" , the home business method would not - especially if the Container's deployment tools are forgiving.
Thanks,
Hemant.
Reid M. Pinchback
Ranch Hand

Joined: Jan 25, 2002
Posts: 775
Yup, that is what I meant. The spec is repeatedly explicit about not returning references to local object references via a remote interface. It wouldn't make sense to have such a prohibition if the container was expected to do the necessary conversion.
Besides, if you look at the DD information for an ejbSelect, you see that you have to specify via a <result-type-mapping> XML entity that the ejbSelect returns either a local or a remote reference - you can't say "both". Thus by the time a home business method has gotten an entity bean object reference via an ejbSelect, its fate is already determined.
 
Don't get me started about those stupid light bulbs.
 
subject: Question from ejbCertificate