• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

EJB Design Suggestions

 
Ranch Hand
Posts: 134
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Folks,

I would appreciate your suggestions and comments on the following
design approach.

In our project we have decided to use Stateless Session EJBs with
Containter Managed Transaction.

In our existing design the Bean Class extends a normal java class which
contains all the business methods.

for example

My architect has been recommending this approach to sepearte business
concerns from the actual ejb class. But i have been recommending not
to adopt this design as we may loose some of the features provided by
the EJB Container like SessionContext handling etc.

It would be great, if all of you could share your thoughts.
Your suggestions would really help us to make a decision.

Regards
[ June 10, 2005: Message edited by: Sujatha Kumar ]
 
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This looks like an odd design. Who knows how the bean will be affected by future changes to its superclass? What's wrong with the bean simply calling the POJOs' business methods.
 
Ranch Hand
Posts: 282
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's not odd design. One reason could be that ServiceImpl code already exists.
 
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There are other better ways of doing unless really it is required. As per my J2EE pattern understanding the business contract should reside in Business delegate. It looks like ServiceImpl have corresponding interface.
To maintain business contract, BusinessDelegate can implement ServiceImpl's interface and BusinessDelegateImpl can have it all business implementation. I am assuming your services/business methods are exposed thru BusinessDelegate to outside world.
 
Sujatha Kumar
Ranch Hand
Posts: 134
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


It's not odd design. One reason could be that ServiceImpl code already exists



ServiceImpl does not exist, we are creating everything from the scratch.


I am assuming your services/business methods are exposed thru BusinessDelegate to outside world.



There is no Business Delegate involved.
 
Ranch Hand
Posts: 190
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What is the rationale behind your architect's recommendation ? Since he's making a recommendation, he must have one.
 
Sujatha Kumar
Ranch Hand
Posts: 134
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My Architect wants to seperate the business methods from the container callback methods.

I was recommending to provide wrapper methods in Session Beans for the
Business Methods.
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I do not understand what your architect is thinking about. The container callbacks are clearly derived from the EJBHome and SessionBean interfaces which you must write, and your stateless session bean must implement the five callbacks. Your business methods are, of course, defined in your component interface and implemented in the bean. You can certainly place the actual business logic in a ServiceImpl POJO, in which case the session bean will invoke the methods of the POJO.
 
Ranch Hand
Posts: 79
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yeah, I think all people who suggested the wrapper approach is better (have your session bean call ServiceImpl POJO). You have to remember one powerful thing that you can do with session bean is making it a remote object by using remote interface and remote home. If you do that, you have to make sure all the SessionBean methods are coarse grained. It is very likely the ServiceImpl is fine grained, and this will suffer from network latency if try to do any remote ejb access. Therefore, explain to your architect that if you have the SessionBean directly extends the ServiceImpl, you better not make this SessionBean a remote.
 
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have different take on this. Am just trying to reason why your architect might have suggested the approach of using the super class. I am not sure how complex your system is or how many methods this Session Bean has but I think the rationale behind his decision is performance and memory consumption. If we have a set of wrapper methods, then the EJb does not own the actual method and the JVM would create a object of the class implementing the methods. However, if the EJB is a sub-class then the implementation is within the EJB and the number of objects at runtime would be lesser.
I did not understand the remote object accession scenario mentioned by Jeremy and can not see how it is related to the question asked. If the client is remote the remote overhead would always be there whether we use wrapped or sun-class approach.
 
Rahul Devgan
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Reflecting further, what he has also suggested is a separation of concerns to a finer level. The bean does not care about how the biz logic will be implemented and is only taking care of life cycle implementation, if any. This keeps the code cleaner and allows the biz logic to be handled by a not so great J2EE pro but a gr8 domain expert. Anyways, as long as the methods get called on the remote stub, it is all transparent to the client and under control of the J2EE server, which is what is desired afterall.
 
Ranch Hand
Posts: 1209
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Rahul Devgan:
Reflecting further, what he has also suggested is a separation of concerns to a finer level. The bean does not care about how the biz logic will be implemented and is only taking care of life cycle implementation, if any.



If the ServiceImpl is at a finer level, then does'nt it become all the more necessary that the session bean hide that level of fine grained access from the clients?
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

I have different take on this. Am just trying to reason why your architect might have suggested the approach of using the super class. I am not sure how complex your system is or how many methods this Session Bean has but I think the rationale behind his decision is performance and memory consumption. If we have a set of wrapper methods, then the EJb does not own the actual method and the JVM would create a object of the class implementing the methods. However, if the EJB is a sub-class then the implementation is within the EJB and the number of objects at runtime would be lesser.


I think you will really struggle to get evidence that creating a POJO object is a performance issue. I can provide you with a list (longer than your arm) of things which harm the performance of J2EE applications, all of which are more damaging than this.
 
Rahul Devgan
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Whether ther ServiceImpl is fine grained or not, I can not presume and it will not be a good idea to presume that. Whatever my views on this were contextual, without considering anything other then what was stated in the original question.
On the performance side, considering the big O of complexity, it is always better to keep the number of objects floating around at runtime to a minimum. Now I am now saying that POJO is a big overhead or not but simply answering again based on the context of the question. Why even one extra object, when the same can be avoided?
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
For me, ease of understanding far outweigh performance considerations in virtually every case. It has to be said that, for most people, it is an unknown what the effect would be of a bean subclassing a POJO. And as it is a struggle for the majority of programmers to get a decent understanding of EJB technology, there is no doubt in my mind that the bean and the POJO should be kept in separate files.
 
reply
    Bookmark Topic Watch Topic
  • New Topic