aspose file tools*
The moose likes Object Relational Mapping and the fly likes Entity Bean to JPA migration.... handling Entity bean home interface responsibility? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Databases » Object Relational Mapping
Bookmark "Entity Bean to JPA migration.... handling Entity bean home interface responsibility?" Watch "Entity Bean to JPA migration.... handling Entity bean home interface responsibility?" New topic
Author

Entity Bean to JPA migration.... handling Entity bean home interface responsibility?

Chandrasekhar Elindram
Greenhorn

Joined: Jul 16, 2007
Posts: 15
Hi,

It is a debate between I and a colleague of mine. I have got an EJB 2.1 application, in which I'm suppose to migrate the Entity Beans to JPA entities. This application also has Course grained Session facades to access the Entity beans.
I thought it would be a better idea to have plain java classes which talks to JPA entities using Entity Manager API to perform all the operations that an Entity bean home does. Doing this I just have to do little changes in my existing Session facades, like instead of doing a lookup for Entity bean I will get instance of the corresponding Java helper class which acts like Entity Bean home interface.
But my colleague says I should write one Session bean per JPA Entity to replicate the behaviour of Entiy Bean home interface. Is it not going to make the application heavier? Is it required at all?
My point is, as I already have Session facades, calls that I will make to my java helpers which will act like Entity bean home interface, will come under the existing Session facades transaction context. Then why is the need for having Session beans there? Am I right?
Even if I have to support distributed deployment in future, we are ok with deploying the module that has Entity beans (or Entities) and the module that has Session facades on the same node.
Please share your thought!!!

Best regards,
Chandra.

[ June 05, 2008: Message edited by: Chandrasekhar Elindram ]
[ June 05, 2008: Message edited by: Chandrasekhar Elindram ]

SCJP, SCBCD
Paul Sturrock
Bartender

Joined: Apr 14, 2004
Posts: 10336

A SessionFacade sounds like it should be enough. I'm not sure what you gain by having another session bean ape the behaviour of the entity beans yuor are replacing. The SessionFacade will supply all the container provided services you are liable to need, so unless your architecture is way more complex than the usual EJB apps I can see the need for extra EJBs. Does your colleague say why they think you need to replace the Entity Bean home interfaces in this way?


JavaRanch FAQ HowToAskQuestionsOnJavaRanch
Chandrasekhar Elindram
Greenhorn

Joined: Jul 16, 2007
Posts: 15
Thanks for your reply Paul.
I totally agree with you, and my application doesnot really have a very complex architecture. It is like any other mid to large sized EJB application.
All that my colleague says is using Session beans to perform Entity bean home job, is a good practice... and I'm not accepting that.... thanks for supporting my argument
Prashant Tejura
Greenhorn

Joined: Feb 11, 2006
Posts: 26
Before such discussions tend to go nowhere, getting the basics right will help everyone understand your colleague�s point of view.

What you are suggesting is that while migrating Entity Beans (EJB 2.x) to JPA Entities (EJB 3.x), you will create helper classes to ape Entity Bean�s Home interface which you think will leave you & the application with incredible performance gains as against following the best practice of encapsulating Entity Home interface functionality within Stateless Session Beans (SLSB).

To that, I can only say - let me be the last one to remind you that Session Beans in EJB 3.0 are light-weight POJOs. As light as POJOs but only smarter! Hence I don�t buy your argument that usage of SLSB 3.x will make your application �heavy�.
To quantify my argument, have a look at this myth-shattering performance benchmark comparison between EJB 3x. Vs POJO(non EJB):-
http://www.adam-bien.com/roller/abien/entry/is_it_worth_using_pojos

By the way if performance is the only criteria, I am still wondering why do you want to create one helper class each for every Entity Bean Home Interface when you could easily avoid this memory baggage by having your application code rewritten to work directly with the entity manager API?
But ofcourse, now the trade-offs between loose-coupling Vs performance will strike you!

Additionally on the issue of memory overhead, you need to be reminded that App Servers are smart in maintaining a pool & don�t create one separate SLSB instance for every client but in the case of helper class you are on your own to guzzle.
Not that you should care less, but I feel focusing on how to save little memory footprint is certainly not of any interest to the clients who have already spent huge sums for license of App Server & related infra coz after all we are talking about memory which costs hardly $20 for 1GB on amazon.com

Coming back to core issue, I hope your colleague must have mentioned about this free tool to automate the conversion of Entity Beans 2.x to JPA Entities thereby saving substantial efforts & cost so that you can enjoy a vacation to Hawaii or Chennai (as the case maybe). Have a look:-
http://www.oracle.com/technology/pub/articles/vohra_ejb.html

Finally, some goodies of putting up SLSB as Entity Home Interface is that it can be looked up from JNDI just as the entity home was previously and can use a similar interface in order to minimize application code changes. Also, @PersistenceContext injection doesn�t work in dumb helper classes besides having no support for declarative transactions, security & other container services available to EJBs. Even from Testability point of view, with SLSBs doubling up as Home for JPA entities, you will be able to break entity service completely away from the application code and unit test it (including distributed & clustered env). It will also be possible to inject stubs or mocks at appropriate places and do limited integration testing.

Chill !
[ June 08, 2008: Message edited by: Prashant Tejura ]

PMP, SCJP 1.4 , SCWCD 1.4 , SCBCD 1.3, IBM SOA Associate(Exam# 664)
Chandrasekhar Elindram
Greenhorn

Joined: Jul 16, 2007
Posts: 15
Thanks for the detailed explanation and for your concern on my trip to Hawai or Chennai
I'm exploring further based on the POJO vs EJB3 performance related link that you have provided. I'm not very sure whether time and client commitments allow me to change my proposed implementation from POJOs to Session beans.

Thanks for your support!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Entity Bean to JPA migration.... handling Entity bean home interface responsibility?