aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes question about design of Stateless Session Bean Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "question about design of Stateless Session Bean" Watch "question about design of Stateless Session Bean" New topic
Author

question about design of Stateless Session Bean

Robert Strong
Ranch Hand

Joined: Sep 10, 2002
Posts: 84
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
Ranch Hand

Joined: Jul 14, 2005
Posts: 187
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.


Devender Thareja
SCEA, SCBCD, SCJP
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704
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.


I think, therefore I exist -- Rene Descartes
Robert Strong
Ranch Hand

Joined: Sep 10, 2002
Posts: 84
Valentin:

thank you for your detailed descriptions.
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704
You're very welcome Robert
mohan joyappa
Greenhorn

Joined: Jan 16, 2006
Posts: 4
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
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17260
    
    6

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


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: question about design of Stateless Session Bean