Business Interface (Stateful/Stateless)

[S. Kroschk]

Hi,
second question in a row.

When working on the business interfaces i realised that the booking process could be classified in a stateless (the prepare itinerary services are not aware of the customer) and a stateful part.

I'm wondering to implement the prepare itinerary services by a stateless bean and the remaining pay/change/etc. services by a stateful bean (which is, of course be able call the stateless bean, if the prepare itinerary services are requested by a logged-in customer.


This should, imho, increase scalabilty by reducing the number of stateful beans instances assigned to customers at the same time.

Does anyone who would like make a remark?
Thanks in advance
Stefan

Btw. Are there any non-native writers here who have the problem of nearly always mistyping "itinerary"?
;-)

[Wei-ju Wu]

Hallo Stefan,

I am working on my assignment as well. I did it similar to you and employed a stateful session bean. I agree with you that doing so will avoid having to restore conversational state on every request.

Originally posted by Stefan Kroschk:

Btw. Are there any non-native writers here who have the problem of nearly always mistyping "itinerary"?
;-)

Geht mir genauso: "Itinerary, itinerary, itinerary...."

[jay roy]

hi guys

Dont you think the scalability will be much better if stateful session beans can be totally avoided. Instead of using a stateful session bean,just maintain the state by using a simple HTTPSession.
The reason i am saying this is because by avoiding stateful session beans you will get a performance gain because of
1. Inscreased scalability (your stateless beans will be stored in the pool)
2. Lesser consumption of resources since the overhead of maintaining state is not involved.


thanks
J
[ January 10, 2007: Message edited by: jay roy ]

[Wei-ju Wu]

I am using a stateful session facade for the portion of the interaction with the system that I regard as "conversational business processes". So far, it seems that going with the stateful facade made my design simpler than trying to force it into being completely stateless.

There is a section in "Core J2EE Patterns" regarding this topic:

"Business Tier Design Considerations"

I have based my design on these recommendations. What has to be said, though is that a stateless design might be more robust, should the stateful session bean be lost for some reason.

What do you think ?

Originally posted by jay roy:
hi guys

Dont you think the scalability will be much better if stateful session beans can be totally avoided. Instead of using a stateful session bean,just maintain the state by using a simple HTTPSession.
The reason i am saying this is because by avoiding stateful session beans you will get a performance gain because of
1. Inscreased scalability (your stateless beans will be stored in the pool)
2. Lesser consumption of resources since the overhead of maintaining state is not involved.


thanks
J

[ January 10, 2007: Message edited by: jay roy ]

[S. Kroschk]

Hi all,

I decided to use a stateful bean because the requirements documents describe _two_ different client types. A web client and an application client.

The first one is accessing the web-presentation-tier and the other one accessing the business tier. The first tier where both client can be treated uniformely is the business tier. And that's in this scenario the right place to maintain the state. (imo)


ok, but my original question has a different scope:
It's more about: Using statful technics when necessary and stateless ones when possible.

Scenario:

- As long as the customer is not logged in, the prepare itinerary conversation will be handled by a stateless bean
( browser -> webtier -> PrepareRemote -> PrepareBean)

- When the customer logs in, he will ge a stateful bean instance assigned.
( browser -> webtier -> BookingRemote -> BookingBean)

- When a logged-in customer decides to prepare an itinerary the the stateless prepare bean will be reused. The pattern looks like this:
( browser -> webtier -> BookingRemote -> BookingBean -> PrepareLocal -> PrepareBean)

.. with the PrepareBean being staless and the BookingBean beeing stateful.

Do you see what I mean?
Regards
Stefan

[Wei-ju Wu]

Hi Stefan,

as I understand, your design enables the clients to communicate with the EJB container in a mostly uniform way, because the conversational state is handled by the session bean.

From what I can read from your description, you base your decision whether to use the stateful bean on the user's login state and reroute the requests through a stateless path and a stateful path. Probably you could also consider taking the type of interaction with the system into account. Prepare (in my assignment) has a non-conversational and a conversational part, at least that's what I think.

[jay roy]

Well it�s a big debate wheather to use stateful session beans given its disadvantages. I am not saying that stateful beans should be totally avoided, but its usage should be reduced.

Wei-ju Wu: when you say
>> though is that a stateless design might be more robust, should the stateful session bean be lost for some reason.
I am not sure what you mean by �stateful session bean be lost for some reason� . How will a stateful bean be lost?
May be it does, never heard of anything like that before.

Thanks
J

[Wei-ju Wu]

Originally posted by jay roy:

I am not sure what you mean by �stateful session bean be lost for some reason� . How will a stateful bean be lost?
J

I just meant that a stateful bean would most possibly lose its state information on a server crash. If conversational state was saved on the client, there could be the possibility to recover if the client reconnects after a server restart.

I am sure, one could find arguments for and against stateless versus stateful beans, similar as people could find arguments for and against CMP entity beans versus data access objects.