Stateless Architecture with CDI+Weld

[alexcrown]

How best can one design a stateless web application with CDI/Weld?

With Struts 2 and Spring this is possible since they are by design stateless.
I learned that stateless applications are scalable whereas stateful applications are not. What are the advantages of stateful applications over stateless applications?

Thanks

[chasetec]

The advantage of a stateful application is that it has state. (shocker, I know)

Stateful applications can scale just fine. The stupid scaling myth comes from the EJB world. Clients can share stateless session bean instances instead of each having their own stateful instance of a session ejb. The problem is that almost all applications need state at some point. You can keep the state in the client tier or the persistence tier but then you have all the extra overhead of transferring the state on every invocation of your business logic.

If you want to write a stateless application then (this may come as a shock) don't store any state.

Are you really not using HttpSession in your Struts applications? I doubt it. @SessionScoped would imply storing client state in the server. @RequestScoped would imply a stateless (or at least very short lived) state.

[alexcrown]

Thanks Mathieu.

Of course I am using HttpSession in my Struts 2 application to store state. I just wanted to know if the idea of having a stateless business logic layer is possible with CDI/Weld. CDI/Weld are stateful frameworks if I am correct. They advocate having a business logic with state in the middle layer of the application.

I think emulating Struts 2 in CDI/Weld is possible by having a @RequestScoped bean to represent an Action class in Struts 2 parlance. Also by having a stateless session bean as your service class, you can emulate a Spring 'prototype' service class in Struts 2.

My conclusion is then that with CDI/Weld you the two. I can decide to use CDI/Weld to develop my application the Struts 2 way or otherwise.