Bill --
I think the important design point to make, is that you want your
business logic (including rules of behavior, state machine, etc) to be
encapsulated within the EJB tier. This makes for tidier code and a more
elegant design, and also makes your code more client-neutral. One of the
scenarios you describe is to use stateless session beans, and store user
state at the servlet level. While I haven't read the article, and while
I will give it the benefit of the doubt that there might be some hidden
benefit to that, still I would discount it as a design methodology -- it
seems to needlessly spread your business logic across two completely
separate subsystems with completely separate programming paradigms (that
is, the Servlet level and the EJB level). If the only "problem" that
this design is meant to solve is the concurrency issue which started
this thread, then I think the solution I ended up on is a better one --
a simple wrapper class around the session bean which adds syncronization
to the methods.
Hopefully this sheds some light on your follow up question, "why the
aversion to stateless". I have users, they log in to the system, and
they perform actions against a database, and I need to be sure that they
can only perform the actions they are authorized to perform, and only
against the data that they are authorized to access. So I have stateful
session beans for the users; the only "state", really, is "who is this
user?" (obtained from a "logon" method, which is the only method allowed
to be executed right after creation). The rest of the methods check who
the current user is, and use entity beans to get/set the appropriate
data. At the web tier (Struts and JSP), I basically have a library of
Struts actions and custom JSP tags which pretty much just duplicate the
method names in the session bean, passing parameters to the EJB tier and
packaging the return values as javabeans for the JSP to display. So, at
the web tier, there really is no "state" at all, except for a reference
to the user's EJB session bean.
Stateful session beans are the way to go with my application, it keeps
the meat of the system all in one tier (EJB), and keeps my web tier very
simple (it wouldn't be hard, for example, for me to re-implement my
Struts actions in some other framework, since they are just lightweight
pass-throughs anyway).
Regards,
Bryan
Hines, Bill wrote:
> Brian,
>
> Disclaimer: I'm new to EJB and still trying to understand when to use
> stateful/stateless session beans.
>
> Given that, I found your situation interesting. First I'll try to help you
> if I can. There is an article in the February 2001 WebSphere Advisor by Tony
> Higham, on page 10, titled "The Reality of EJB". It should be available on
> their web site. He talks about problems like yours and recommends an
> approach where you use stateless beans but an alternative state-handling
> mechanism such as HttpSession to hold the user's data. Will that sort of
> thing work for you? It sounds more light-weight than stashing the whole
> session bean and/or accessor JavaBean with synchronized methods into the
> session. There are also some good patterns for using session beans in the
> IBM Redbook "Design and Implement Servlets, JSPs, and EJBs for IBM WebSphere
> Application Server", which is available for download on the IBM Redbooks
> site. You might find some ideas there.
>
> Now that I've tried to help, if you could, explain your aversion to
> stateless and why they won't work for you in this situation, so that I can
> learn more.
>
> Thanks, your questions and contributions here are very useful to me.
>
> Bill Hines
> Sun Certified Java Programmer
> Hershey Foods Corp
>
>
