Hi,

I am trying to arctitect a web app which will be running on websphere.

One of the *features or requirement* is being stateless - one argument in favor of being stateless is - for easier load balancing as then request can go to any server machine, making location of server machine completely transperant.

Is it possible/advisable to be completely stateless or I am going to be digging troubles for myself by signing to be stateless?

-Thanks,

Why should they be mutually exclusive ?. A hybrid of SLSB and SFSB should be good enough unless you want to completely choose one for other. SLSB for Session Conversion which will support the load balancing while SFSB to handle your business and persistency needs.

" SLSB for Session Conversion which will support the load balancing while SFSB to handle your business and persistency needs. "
Can you elaborate on this or point to any useful web resource in this regard?
-Thanks

A lot of architects preach statelessness as the ultimate solution to scalability. I think this is a little bit like preaching the use of C as the ultimate solution to performance.

Yes you will get great scalability and have very few deployment issues if you use only stateless beans, but what will you lose? If your application needs state, it needs state. You'll end up storing the state somewhere else where it might be much harder to manage (like browser cookies, HTTP sessions, or giant URLs).

Aside from that, modern J2EE containers can give you stateless EJB while still providing good scalability and reliability using state replication and similar technology.

Certainly you should go stateless if you don't really need the state, but I'm in favor of doing what makes the most sense for the application at a high level and figuring out how to optimize it later if necessary ("optimize last, if at all", that's been good advice in our business for a long time).

Frank

"Yes you will get great scalability and have very few deployment issues if you use only stateless beans, but what will you lose? If your application needs state, it needs state. You'll end up storing the state somewhere else where it might be much harder to manage (like browser cookies, HTTP sessions, or giant URLs)."



Is it possible to maintain state in a SFSB when writing a web app? Doesn't state in a SFSB become stale as soon as the user presses the back button or uses a cloned window?

If the users of a web app only selected hyperlinks, pressed submit buttons and used one browser then SFSB state would be manageable. Because users *can* use the back button and clone windows we have to assume they *will*. Some developers solution to this issue is to inactivate the back button prevent window cloning with java script. There are a plethora reasons why this is bad, eg, javascript is not standardised.

I see the most appropriate place to store state is in the mechanism that is controlling state transition - the browser. When the user changes state the state information moves with them and never becomes stale. You avoid having to write complex algorithms that track state transition and prevent SFSB state becoming stale (testing these algorithms is difficult especially if you web app is large).

The most success I've had with browser state is hidden fields. This is a simple solution that will save you time and head ache.

Sivan.

Those architects including myself may be refering to an application being stateless if it handles its own state correctly, i.e. It manages its state with a persistent shared memory store or clustered backend database. Then the architect does not need to worry about state and can just get on with load balancing the cluster and scale effectivley... as always terms in IT get very abused and I'm probably wrong but a lot of people use the term my way...

If your requirement is invisibility of the exact server machine, this is not incompatible with storing state.

Software or hardware routers combined with a service performing replication of state across a cluster allow will load balancing for a stateful system. This has a performance impact however.

Rendering your system statesless just to employ load balancing is somewhat ill conceived. You need to assess just how much state you require in each tier, and where performance is likely to require load balancing.

I mean Session Conversation not Session Conversion. Application Server provides new SLSB for every request. Since they do not maintain any state information they should easily suffice the need of load balancing. Using this SLSB Facade (Session )invoke business and persistence related processing using SFSB ( like EJB ).

Refer to any good book on EJB and links related to J2EE Design Patterns

thanks