question about design of Stateless Session Bean

[Robert Strong]

hi, I'm using BEA Weblogic8.1, I'm a little bit confused about the optimal process of building J2EE(EJB) application from UML use cases and interaction diagrams.

Currently, the way we work is that, first business analyst gather requirements, and draw use cases or activity diagrams for developers. Then, developers need to design the class diagram, interaction diagram, and code EJBs.

So, usually I'd create a Stateless Session Bean for each use case, as a controller. The Controller Stateless Session Bean would interact with CMP Entity Beans or DAOs, and each method in controller stateless session bean represent a step in use case scenarios, so related steps in a use case is grouped into one stateless session bean.

I doubt this kind of design does not always provide optimal performance. if two heavily used methods are within one SLSB, it'd likely cause very high timeout ratio for the SLSB. I've heard that in BEA Weblogic, each SLSB can work with at most 13 threads, so at most 13 instances of SLSB. when too many users simultaneously request those two methods, the 13 instances would be in use all the time, other requests need to wait, this SLSB might experience very high timeout, and transanction rollback ratio.

so, how to deal with this situation in SLSB design? just seperate these heavily used methods in different SLSBs?

any help appreicated!

[Devender Thareja]

Hi Robert,

The design is such a subjective thing that different people will approach different design for same problem. Some are obviously better then others. From my point of view, you can not say that for each use case there a developer will create one EJB. Sometimes developer may re-use existign EJB, code re-use is the main advantage of Java. Here is an overly simple example:
Suppose there are 3 use cases:
1. Say hello - Hello Mr. X.
2. Say date - Mr. X, today is <date>
3. Say bye. - bye Mr. X

In above 3 cases, only user name need to be revtirieved from database. So developer has to write only one SLSB but from BA's point of view there are 3 use cases.
Similaraly for one particular task, more then one SLSB may require.
So there is no correlation whatsoever.
I am surprized that Weblogic can not create more then 13 instance of one perticular EJB. Never heared of that. I thought there is no bound of EJB scalability. Can somebody comment on this please?

Hope it helps.

[Valentin Tanase]

Hi Robert,

First of all I doubt that implementing a SLSB for each use-case is always the best approach, but is true that I cannot see any reasons why you shouldn�t do so if it makes sense to your design. However the designing choice, this should not impact your application performances at all. Your application could be configured to provide similar performances whether you have only one SLSB or 100. There are common best practices for tuning the SLSBs, but as a rule of thumb the more the bean is used the more instances in the pool you�ll create. As for the story of a certain number of threads per EJB instance I believe that this is just a story and I wouldn�t take it very seriously. You should ask for some reliable source of information that proves this theory, eventually some official documentation posted on the bea�s site. Usually you use application queues if you�d like to restrict or control the number of threads used by a specific application. To figure out the optimal number of threads is an iterative process and you should perform appropriate load tests in order to figure this one out.
Finally one more word about heavily used methods. This should not be a problem if the pool is properly tunned. The problem however is about the methods that heavily executes. I mean if you implement use-cases that take a lot of time to execute that�s a serious problem. In such case grouping the methods in separate beans that get assigned to their own execute queue, might help. Using messaging if appropriate might be another solution.
There is however one more thing that you might consider in your design (you should decide whether it is useful or appropriate to your system): consider implementing your business layer as POJOs, and use the SLSBs as wrappers for making your business layer available to remote/local clients. This at least might give you the advantage that you can test your business layer outside of the container and will reduce the functional testing to only providing appropriate integration test cases.
Again this is just my opinion.
Regards.

[Robert Strong]

Valentin:

thank you for your detailed descriptions.

[Valentin Tanase]

You're very welcome Robert

[mohan joyappa]

If we use SLSB as session facade for each use case controller, then where do we store the session?As a http session?
if we are going to use http session, then how about java application?where do we store session info for them.

answers would be appriciated

Mohan

[Mark Spritzler]

Originally posted by mohan joyappa:
If we use SLSB as session facade for each use case controller, then where do we store the session?As a http session?
if we are going to use http session, then how about java application?where do we store session info for them.

answers would be appriciated

Mohan

Well, this particular question isn't about a web application. As far as Session, there are many solutions out there for handling Sessions for Web Applications, including the Struts Framework.

Basically, but not always, you don't want to use a Stateful SessionBean, and you won't save "state". I believe there is a much better solution not having to save state, except for that information which you store in a database. Now, each call will have information needed passed to it, but nothing more. And using Messaging for those algorithms that take time, make the system much faster, and light.

Mark