aspose file tools*
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes few questions on entity beans Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of JavaScript Promises Essentials this week in the JavaScript forum!
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "few questions on entity beans" Watch "few questions on entity beans" New topic
Author

few questions on entity beans

manish ahuja
Ranch Hand

Joined: Oct 23, 2003
Posts: 312
Hi
I would like to know whenever ppl talk about entity beans they talk in relation with local interfaces and not in terms of remote interfaces
why so. Is it convenience or is there a downside using entity beans with remote interfaces
like in case of cmr , we cant use cmr with remote entity beans & can onli be used with local entity beans
What i am saying is not invoking entity bean directly by the client but a Session bean on 1 app server invoking an entity bean on anohter app server

Rgrds
Manish
Kathy Sierra
Cowgirl and Author
Ranch Hand

Joined: Oct 10, 2002
Posts: 1572
Howdy Manish,
good questions...
There are a couple of reasons why local interfaces are perhaps more important with entity beans:
1) For one entity bean to have a CMR relationship with another bean, the entity must use the LOCAL interface of the bean for which it has a CMR field.
2) If you allow direct Remote client access to a bean, and the client is not itself another bean, then the client cannot *scope* the transaction. This means that for each method the client calls on the entity bean, there is potentially a complete cycle of starting a new transaction, ejbActivate, and ejbLoad, and THEN the method, followed by the reverse -- ejbStore and ejbPassivate. Let's say the client wants to call three business methods on the bean, and each method has a Requires tx attribute. Those 3 method calls result in:
ejbActivate
ejbLoad
BizMethodOne
ejbStore
ejbPassivate
ejbActivate
ejbLoad
BizMethodTwo
ejbStore
ejbPassivate
ejbActivate
ejbLoad
BizMethodThree
ejbStore
ejbPassivate
All that for just three method calls from the client!!
So, if the client is, say, a Session bean, then the Session bean can start the tx and make the three calls as follows:
ejbActivate
ejbLoad
BizMethodOne
BizMethodTwo
BizMethodThree
ejbStore
ejbPassivate
A huge improvement.
Now, this client tx scoping really has nothing to do with whether the client is using the local or Remote interface of the bean. But if a client *is* a session bean, then the client has the option for using the local interface of the bean, depending on your design.
The main reason, and often the *only* good reason to use local interfaces, though, is for entity bean relationships. Even in the scenario I described with a Session bean accessing the Entity bean (rather than letting the client go directly to the entity bean), there are compelling reasons to make the entity bean Remote to the Session bean -- mainly that the beans can be deployed anywhere, at any time. The session bean can be placed on another network node without causing things to break. Once you make the decision to keep beans local to one another, you're more or less stuck that way. (although there are some design hoops you can go through to try to still give yourself some location "transparency", by having a bean that uses both local and Remote interfaces and doing a bunch of stuff to make it work either way, but this is often kludgey).
Local interfaces were introduced into the spec to support CMR. Period. But because people had complained about having unnecessary overhead with RMI even when beans were in the same JVM, the spec developers decided to (under pressure) extend the local capability (but at your own design and maintenance risk) for other purposes as well, including session beans.
cheers,
Kathy
Reid M. Pinchback
Ranch Hand

Joined: Jan 25, 2002
Posts: 775
Originally posted by Kathy Sierra:
2) If you allow direct Remote client access to a bean, and the client is not itself another bean, then the client cannot *scope* the transaction. This means that for each method the client calls on the entity bean, there is potentially a complete cycle of starting a new transaction, ejbActivate, and ejbLoad, and THEN the method, followed by the reverse -- ejbStore and ejbPassivate.

For exam purposes this is correct. The J2EE blueprints actually leave open the possibility of client-side non-bean transactions, although normally transaction scoping would be achieved by creating a bean method to represent the desired transaction:

8.5 Transactions in Applets and Application Clients
The J2EE platform does not require transaction support in applets and application clients, though like distributed transactions, a J2EE product might choose to provide this capability for added value. So, whether applets and application clients can directly access a UserTransaction object depends on the capabilities provided by the container. To ensure portability, applets and application clients should delegate transactional work to enterprise beans.


Reid - SCJP2 (April 2002)
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: few questions on entity beans