The State of AS400 iSeries Application Modernization

Historically, our old AS400 and ISERIES applications were stateful.

In information technology and computer science, a system is described as stateful if it is designed to remember preceding events or user interactions; the remembered information is called the state of the system.

So, if we are looking at modernizing legacy AS400/ISERIES applications, is it a mistake to try and simply modernize to 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, but it’s still old-fashioned under the covers.

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-i 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”?

Stateless Model

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.

Stateful Model

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.

Summary

Stateless is the future.

Beautifying old Stateful AS400 and ISERIES 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 cough paperweight on the shelf above the monitor. Which, while being totally nsfw, did make me chuckle.

From AS400 Green Screen to IBM i Web

Over 75% of associations run IBM i Power Systems for their core business applications.

Over 75% of associations run IBM i Power Systems for their core business applications.

However, the Web UI versus 5250 Terminal (aka green-screen) banter continues. From personal experience, the VAST majority of business still use an old fashioned 5250 terminals as their customer facing screens. Most casing speedier responses and ease of typing over the superior client experience of a web UI.

Learn more