• 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 Decision

 
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
 
Ranch Hand
Posts: 425
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sujatha,

I could not understand your Architects concern about seperating business class from the session bean. Infact session bean themselves are developed to write some business logic. and designing in the way your architect says will increase one more class.

But yeah one benifit if he is looking forward to may be modularity and again hiding business methods by one more layer. I think He can achieve that with this.

Cheers,
Rahul
 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
if you extend you session bean from a class the code of other class will run in same context. so it really doesn't have any disadvantage to put your business logic in a seperate java class. with this you will achive modularity. so, i think the solution your architect is suggesting is not wrong.
 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Adding another layer of abstraction seems quite unnecessary. After all session bean IS supposed to contain business logic and is already a result of required abstraction.
 
Ranch Hand
Posts: 223
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
However, if you need to migrate away from EJBs (for what reason ever) you will be happy to have business logic in simple Java classes that can be used in, say, a plain servlet-based app.

D.
 
S Sudhindra
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You are right. In that scenario it may be helpful. I think I will change my opinion on this. It may after all be a good idea. Thanks.
 
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
But the extra layer of wrapping would impact the performance.
And application will be less performant as compare to directly place the bussiness logic in SLSB.

Regards,
 
David Follow
Ranch Hand
Posts: 223
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Siyaram,

considering what is going on under the hood of a EJB Container, the tiny overhead of having business code defined in a separate class outside the EJB won't impact the performance at all.

D.
[ July 06, 2005: Message edited by: David Follow ]
 
Ranch Hand
Posts: 79
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, Sujatha Kumar

I will avoid the approach if I can. The most important reason is because I rely on tools to generate deployment descriptors. The tool I used is EjbGen. How that works is that it allows me to specify tags in front of each business method of the session bean, and then I can run the tools. It will generate the deployment descriptors according to the tags I specified. Therefore, if used the approach suggested by your architect, I will have to place this stuff in a plain java class. First, it will be really weird because some people might not understand why you put them there because they simply do not know about the tool. Second, I guess your architect will just supply you the class, and therefore, to use that, you will have to ask him to put those tags in the source file, and run the tools. This will be a very hideous deployment process.


Also, why you use session bean I think is probably you want to expose this service methods remotely. Therefore, you can have a web server talking to an application server for scalability reason.

If that is the case, a lot of methods are required to be tweeked so that you get the most of the data transported in 1 network calls. That involves how you define the parameters that you use to set and get data. If you directly implements the ServiceImpl, which I assume contains very fine grained methods, it will really slows down the performance when you trying to use session bean remotely.

Furthermore, I just thought about it is that when you program using a plain java class, you are passing the object around using this keyword. You can not do this with EJB, and you should know the reason why. Therefore, great care should be paid when developing those classes. You have to make sure the this class actually includes restrictions imposed by EJB.

Other than that, I can not think of any other negatives. Therefore, if your team is not on the same boat as me, it might be fine just going with that approach.

[ July 08, 2005: Message edited by: Jeremy Hsu ]
[ July 08, 2005: Message edited by: Jeremy Hsu ]
 
Ranch Hand
Posts: 174
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I would go with Jeremy and won't recommend this approach.
Session bean should have the business methods and business logic should not be there as it becomes bloated.
i.e Session bean should just act like a Facade.
What is required is a domain model which contains business logic for eg BankTellerManager which gets invoked by Sesion bean BankTellerEJB. This domain model is designed from the requirements and by use GOF patterns , a vey modular and re usable design can be obtained.
Any other EJB can call the method from your BankTellerManager and hene there is no duplication.
Vinay
 
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 is a repost.
https://coderanch.com/t/316503/EJB-JEE/java/EJB-Design-Suggestions
 
Popeye has his spinach. I have this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic