This week's book giveaway is in the Performance forum.
We're giving away four copies of The Java Performance Companion and have Charlie Hunt, Monica Beckwith, Poonam Parhar, & Bengt Rutisson on-line!
See this thread for details.
Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

help

 
Jingyi Wang
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
On P291, the problem #3,

Which are ways in which a client can get reference to an existing entity object's local component interface?
One option is:
D. Receive the reference as a parameter in a method call.
which is one of the correct answer. I don't even understand what's meaning of this statement. Anybody can explain to me?
Thanks
 
alzamabar
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jingyi Wang:
On P291, the problem #3,

Which are ways in which a client can get reference to an existing entity object's local component interface?
One option is:
D. Receive the reference as a parameter in a method call.
which is one of the correct answer. I don't even understand what's meaning of this statement. Anybody can explain to me?
Thanks



You use beans through the home and component interfaces. There are several reasons for that, reasons that I'm not going to list here. The concept it that EJB are reusable components that find a reason to be in a distributed environment (the client/server thing). As you may recall from RMI (which I remember to you is the underlying technology for EJB) a client that wants to invoke methods on a server (and as a server we're talking here of a remote component, doesn't matter if it's on the same machine) cannot simply get a reference to the server object. A client invokes methods on a remote object (server) via a stub to it (the rmic thing - Stubs and Skeletons, remember?). This is to hide the complexity of managing the details of low-lever networking communication. The client has got an object reference to the remote server, thus thinking of having a reference to the remote object. It's the stub that knows how to communicate with the 'thing that represents the server on the server side' (the skeleton thing, or whatever implementation does the skeletonish thing). Now, let's suppose that a local client has got a reference to an EJBLocalObject stub (which means it can invoke methods on what she thinks is the bean). The client can pass this reference to another client, which can use it to use exactly the same bean...functionalities (here we should distinguish between stateful and stateless session beans and entity beans). The only limit that the EJB specs put when passing argument or receiving return types are that the types must be serializable, reference to other resources, references to the bean's special JNDI environment OR...BEAN'S HOME OR COMPONENT INTERFACES (Local or Remote). Bottom line...A reference to a bean's EJBObject or EJBLocalObject can be passed as argument. This will save clients the duty to start all over from getting the bean's home interface stub and from there to obtain an EJBObject (or local) reference stub.

Hope this helps,

Marco
 
Lionel Orellana
Ranch Hand
Posts: 87
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
D. Receive the reference as a parameter in a method call.
which is one of the correct answer. I don't even understand what's meaning of this statement


It only means you can have a method in your bean where one of the parameters is the component interface of another bean.

public void methodInMyBean(SomeOtherBean sob){
...
sob.doSomeWorkForMeThankYou();
...
}
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic