Session Beans best practices

Thread view:

Memi Lavi - 02 Aug 2004 15:19 GMT

Hi Gurus.

I'm quite new to the EJB concept, so my question may sound trivial.
One of my friends told me that it's not a good practice to have too
many Session beans (stateless) in an application, since the
performance of the EJB container may get worse, and it's better to
have more methods in a single session bean than to create a new one,
since the EJB container will have to hold all the beans in the memory,
which will result a drop in the perfromance.
By saying "too many" I mean tens, maybe a couple of hundreds (no more
than 200, for sure).

I know that the classic OOD concept denotes that each logic unit
should be encapsulated in its own class, as opposed to the claim
above.

What is the right path to go? Is there any limitation on the Session
Beans number?
Our application is based on WAS 5.02, which talks to DB/2 on AS/400.

Reply to this Message

Oliver Fels - 02 Aug 2004 15:54 GMT

> What is the right path to go? Is there any limitation on the Session
> Beans number?

In theory the limitation is given by the physical memory available to the
application server- however as you have already noticed performance
constraints are also an issue.

Your question relates to a design decision- which functionality is
encapsulated by one or more session beans primarily depende on the problem
to solve. The solution for the specific problem can be mostly covered by a
specific design pattern and can't be enumerated by numbers.
Eg. take the facade pattern which in a lot of cases gives you a minimum
amount of session beans from the number of entity beans- or database access
functionality.

Most application servers I have encountered let you define pooling
strategies for session and entity beans thus freeing memory for beans not
in actual use at a cost of performance.
EJBs are extremely resource consuming and it is recommended to equip the
application server with a high amount of resources.
BTW, the experience I have gained in one of my last projects is that session
beans aren't necessarily the memory hogs- if you have high in and out
traffic into a complex database entity beans will give you an interesting
challenge.

To come back to your problem I suggest you extract your functional
requirements first and then take a look at the various EJB design patterns
found eg. at the SUN Java site and http://www.theserverside.com

This will help you a lot.

Oliver

Reply to this Message

Memi Lavi - 02 Aug 2004 21:05 GMT

> > What is the right path to go? Is there any limitation on the Session
> > Beans number?
[quoted text clipped - 28 lines]
>
> Oliver

Thanks for the info.

Let me focus on my specific requirements.
Our application deals with many entities. Let's refer them as
Customers, Orders, Cancellations, Payments and Confiscations.
Now, in a classic OOD, I would have created a seperate class for each
entity, which encapsulates the methods rellevant for each entity. eg.
Customer.CreateOrder which returns Object of type Order,
Cancellations.GetAll which returns a collection of Objects of type
Order, and so on.
Is that design still rellevant in the Session Bean world, or should I
encapsulate all the logic mentioned above in a single session bean,
which will have all the methods rellevant for all the entities?

Reply to this Message

Oliver Fels - 03 Aug 2004 07:36 GMT

> Let me focus on my specific requirements.
> Our application deals with many entities. Let's refer them as
[quoted text clipped - 7 lines]
> encapsulate all the logic mentioned above in a single session bean,
> which will have all the methods rellevant for all the entities?

If you have several entity beans which should be dealt with by a single
session bean you will soon be running into the issue to manage several
entity bean references in a single session bean.

Thirst thing to consider is what you would like to accomplish. A session
bean primarily encapsulates business logic. So try to group together
functionality required and make this into appropriate session beans.
Second question to ask is what data access you need and if it should be done
via facade patterns.
Don't focus on data when designing session beans- focus on functionality.
At the end you will see that for a certain functionality data objects of
type X and Y are required- so you will need a getter method in a session
bean talking with a specific entity bean to acquire this data from the
database.

Just continue that way, this path is straight forward. If you look around
for more patterns as time goes by you will see more and better approaches.

Oliver

Reply to this Message

Memi Lavi - 04 Aug 2004 09:14 GMT

> > Let me focus on my specific requirements.
> > Our application deals with many entities. Let's refer them as
[quoted text clipped - 27 lines]
>
> Oliver

Thanks for the explanation.

I understood that the SB should be my functionality (BL) layer. My
question was: should I consider performance issues unique to SB when
designing the SB layer, or should I design it as I would design any
other regular BL, using regular classes?
With regular classes, I tend to create many, fine grained, classes.
Are there any proble with this approach when using SB?

Reply to this Message

Oliver Fels - 05 Aug 2004 09:08 GMT

> Thanks for the explanation.
>
[quoted text clipped - 4 lines]
> With regular classes, I tend to create many, fine grained, classes.
> Are there any proble with this approach when using SB?

The more session beans you are using the more bean references you will have
to hold in your client implementation and access functionality via several
beans thus improving network access.
What you will have to find is the golden path ;)

In general your approach is ok.

Oliver

Reply to this Message

Memi Lavi - 05 Aug 2004 14:38 GMT

> > Thanks for the explanation.
> >
[quoted text clipped - 11 lines]
>
> In general your approach is ok.

Thanks for the info. It really helped.

> Oliver

Reply to this Message

Session Beans best practices

Free Magazines