Typically our aging AS400 and Iseries applications are stateful. So, if we are looking at iSeries application modernization, is it a mistake to try and simply
modernize beautify them retaining their stateful flow, or should we be looking at refactoring them in a stateless direction?
Is it really a mistake to use a stateful architecture for modernized web applications?
I think of stateful modernization as ending up with a modern looking application. It’s really just skin deep, if we screen scrape or lay a nice graphical tool over our old green screens. It’s not modernization is just making an old application look modern. (you all know the major players in this space, so I’m not going to name names and get myself in trouble 😉
I guess as an IBM RPG developer my main question is “Do I want a modernized web solution to be built around what is comfortable with existing old-school RPG programmers or designed and built focused on the businesses future needs?“
What does this waffling nerd mean when he talks about AS400 Modernization – “stateless” and “stateful”?
In the pure form of the stateless model, a client program makes a request to an application server, which sends data back to the client. The server treats all client connections equally and saves no information from prior requests or sessions. A website that serves up a simple static web page is a good example of the stateless model. The server receives requests for pages it hosts and sends the page data to requesting browsers, much like a short-order cook making meals for diners.
Special Offer for all NICKLITTEN Punters
20% Off with Coupon: NICKLITTEN
In Partnership with SNUG CBD - American readers get 20% off
CBD helps with relaxation, focus and great for pain relief. I highly recommend the SNUG CBD Tincture to help keep you in the zone when programming!
When an application operates in a stateful mode, the server keeps track of who users are and what they do from one screen to the next. Preserving the state of users’ actions is fundamental to having a meaningful, continuous session. It typically begins with a login with user ID and password, establishing a beginning state to the session. As a user navigates through the site, the state may change. The server maintains the state of the user’s information throughout the session until logout.
Stateless should be the Goal
The main advantages of a stateless approach may not always be obvious. But as a web project evolves the design advantages will be come sharply obvious. Overlooking them will almost always limit us. So lets look at some of the best advantages of STATELESS design:
Industry Standard: Almost every mobile or desktop web application is stateless. A stateful application on the other hand is most common in green screen development.
Leading Edge Technology: Using standard UI technologies like jQuery and scripting is far more flexible and responsive than beautified Rich Display files or DDS to XML/JSON conversions.
Scalable: Stateless is clearly more scalable because it runs in batch in a pool of APACHE jobs. Stateful applications require one job per user and a persistent connection which can create a bit of a log jam.
Flexible Navigation: Browsers were made for stateless web applications which do not need to be navigated linearly. Stateful applications force you to enter and exit from a certain spot.
Modularity: Stateless applications are ideal for a services oriented architecture and make our applications more modular.
Stateless is the future.
Beautifying legacy Stateful applications is just applying a bandaid.
PS: the blog header image has absolutely nothing to do with web-service technology, aside from the fact that it’s a very cool looking computer desk. I stumbled across this image online, and then while admiring it in closer detail I noticed that he owner had a rubber
dildo paperweight on the shelf above the monitor. Which made me chuckle.