myth buster: Stateless vs. Stateful

If you feel offend or run when reading this post, please stop reading...

When I was starting the project, the topic of "Stateless Web" was starting heating up. At first I thought it was great idea, so I can get rid of the session, no need to worry about the memory usage, easy to scale up/out and less trouble (with "stateful", you have to handle a lot exceptions around the state).

So what is "Stateless" anyway, I thought "Stateless" means with same input you get the same output.
And as the Restful web service, it looks like you can have that. This is make perfect sense with some web applications/site like Google, you put in search criteria, it gives you the result.

But what if I want implement an application that has security feature (login/logout, access control), and also some sort of work flow with business rules, can "Stateless Web" do that?

Take a simple example, if user submit the form, the application needs to authenticate and authorize the user, so you have to have somewhere to remember the login user's info (user id, roles so and so on) and can id the client.

As I can think of there are 3 places I can store this information, client side, middle tier(Session) or persistent layer (DB).

With storing on the client side, the client side control the flow, and the server side has to fully trust the client side. so normally if you want "secure", you have to have the client send back the user id and password along with the normal request every submit and authenticate everytime, in more complex sample, if the current operation is based on the previouse operations result combination, it's even harder, client have to trace the whole flow and send all extra information back with the normal request, for example, you applied a filter on the list so it only show a subset of the full list, you modified one row on the second page, so when it back to the list page, in order to apply the same filter, the client has to trace the filter criteria cross pages.

With storing on the middle tier (Session), the extra information stored in the session, every time submit, client only bring back the session ID along with the normal request, it saves a lot trouble, for example, cross pages state restoring, but it requires to clean up (for example timeout/invalid session, clean some states from the session once the whole flow is done).

With store on the persistent layer (DB), it's pretty much same with session, the only difference is instead of put into memory, you put it on the disk so you don't need worry about the memory and disk can be cleanup with batch. as trade off, it may hard to scale, also create big IO bottleneck.

I can't think of any other way to do this, and most of the "Stateless web framework" left this part blank. So I'm guess the "Stateless web" really means "You take care of the state problem by yourselves".

Starting the Journey with JSF and CDI.

Over the past year I have bean redesigning and developing our in-house application. It's a large financial web application, the old system has been there for close to 10 years and it was built on top on some specific platform (Weblogic and old version of Tomcat), there are a lot developers with different skill set (I mean some of them really don't have any skill) so the code base is really bizarre.

So I started prototype with JSF & Seam, and later on move to JSF2 with CDI. The old project has over 300 pages and total files close to 4000 files, the new code now is around 1600 files. It took so long to close to the finish line, so I'm thinking to share some thoughts and experiences that I had related to JSF2, CDI, application design, and of cause some rant.

So if you are doing JSF2/CDI or going to do JSF2/CDI, better read this first.

Stay tuned.

Hello world!

Just a test