Value Object vs. Stateful Session Bean

[Peter Bergoff]

Hi again,

Could a Value Object be used to store data? For example - a client requests data and it's sent to the client via a value object. Then the user makes changes to the same value object's data which is then later saved to a database.

I guess the thought is the value object is passed to the client. The client uses and modifies the value object over time. Then when the changes are all done the user saves the changes which are sent back to the ejb server via the same value object.

If the data being modified was on the ejb side we'd use a Stateful Session Bean I guess.

Thoughts??

Thanks. : )
[ June 17, 2004: Message edited by: PETER BERGOFF ]

[Ip Patrick]

>> Could a Value Object be used to store data? For example - a client
>> requests data and it's sent to the client via a value object. Then the >> user makes changes to the same value object's data which is then later >> saved to a database.

>> I guess the thought is the value object is passed to the client. The
>> client uses and modifies the value object over time. Then when the
>> changes are all done the user saves the changes which are sent back to >> the ejb server via the same value object.

Yes I think you can use this updatable value object approach. But sometimes each data may be concurrently accessed and modified by different client. So some other mechanisms may be used to coordinate data access.

>> If the data being modified was on the ejb side we'd use a Stateful Session Bean I guess.

Hope you can elaborate more on this question

Thanks.

Patrick

[Mark Spritzler]

Peter, my philosophy is to not use Stateful Session beans. There are always other alternatives.

If you need to hold state, and not store in a database, then EJB's really probably won't be your best bet. Also, this is true if you are using the Web. i.e. Servlets and JSP, they have a better mechanism for session, either URL re-writing or Session contexts.

You really should make all EJB Session beans as Stateless. Keeping that in mind then you can choose your design patterns from that.

Also keep them as thin as possible, meaning they are just windows/interfaces to the outside world, and that the real work can be done by plain old java objects running inside the server.

Oh, wait, this is the Architect Cert forum. Maybe your assignment requires you to use Stateful Session Beans.

Mark

[Peter Bergoff]

Good thoughts. Thanks.

[Peter Bergoff]

So would you agree to these scenarios:

To get data to the user:
web client -> business delegate -> SSB -> DAO -> Value Object
(In this case the VO was passed from the ejb tier to the web tier. This
one is pretty well documented in the Cade Sequence diagram)

To set data during a user's session:
web client -> business delegate -> Value Object
(In this case the VO was updated in the web tier)

To persist data in a database:
web client -> business delegate -> SSB -> DAO -> Value Object
(In this case the VO is passed back to the ejb tier and then used to update/insert data in the database)

Opinions/Thoughts??

Thanks.

[Peter Storch]

Originally posted by Mark Spritzler:
... my philosophy is to not use Stateful Session beans. There are always other alternatives.

If you need to hold state, and not store in a database, then EJB's really probably won't be your best bet. Also, this is true if you are using the Web. i.e. Servlets and JSP, they have a better mechanism for session, either URL re-writing or Session contexts.

...

I wouldn't generalize this rule. I think the EJB container has the same posibilities to handle the resources occupied by session state as the web container can.
There are some perfomance results out there which proofe Statefull Session Beans better performance than Stateless Session Beans (because of e.g. no bean pool operations). Or at least no significant differents. It depends on the usage.

You shouldn't abandon Statefull Session Beans just because someone said (or some books state) that they are bad. It really depends on the usage and on your alternatives (http-session, temptable, etc.). You should always (ALWAYS) make your own performance analysis.

It really depends on where you need the session data (webcontainer and/or ejb container), how much data it is (serialization issues), how long a session lasts approximately and how many parallel session you might have.
You should also consider appserver clusters and failover issues. That can have an impact on your design desicion.

[Peter Bergoff]

lol - yes, I should have stated this isn't the law in all cases. However, are the scenarios I gave one valid way to answer the needs of the Cade part 2 example?

[Mark Spritzler]

You shouldn't abandon Statefull Session Beans just because someone said (or some books state) that they are bad.

Nope, not taken from books, but from all of my experience with them.

Mark

[Peter Storch]

Originally posted by Mark Spritzler:
Nope, not taken from books, but from all of my experience with them.

Yes, experience is good. And it should be your own and not someone elses. This can be different sometimes in somecases

[Peter Bergoff]

Would you agree that ONE answer to addressing how to get and set data in an application could follow these examples:

To get data to the user:
web client -> business delegate -> SSB -> DAO -> Value Object
(In this case the VO was passed from the ejb tier to the web tier. This
one is pretty well documented in the Cade Sequence diagram)

To set data during a user's session:
web client -> business delegate -> Value Object
(In this case the VO was updated in the web tier)

To persist data in a database:
web client -> business delegate -> SSB -> DAO -> Value Object
(In this case the VO is passed back to the ejb tier and then used to update/insert data in the database. Not really sure how to show the VO
in this case.)

Opinions/Thoughts??

Thanks.

[Peter Storch]

Yes, that's ONE answer (the one with keeping the session data in the web tier).

One other answer could be (with keeping the session data in the ejb tier):

Get data:
web client -> business delegate -> SFSB -> DAO -> Value Object

Set data:
web client -> business delegate -> SFSB -> Value Object

To persist data:
web client -> business delegate -> SSB -> DAO -> Value Object



You should have some arguments why you chose the one over the other solution. Not just say here it is, eat it.

[Peter Bergoff]

True enough. Thanks for your thoughts Peter.