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.
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
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
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.