Get Thee to the Web, Part 2

In this second article of three, we will continue our exploration of moving to the Web by having a look at the rest of the common components of Web applications.

Tiered Design

This is probably the most important part of designing any Web application. It is essential that the application is tiered in such a way that the interface is separate from the database is separate from the business logic.

The basic concept is that you should be able to change any of the components without affecting the other components.

Although this has always been a good principle of any application design, it is something we did not have to be too concerned with in a 5250 environment. 5250 has an interface that is well established and unlikely to change. This is not the case in the world of the Web.

Say you have just developed your first Web application, you have shown it to your users, and they are mightily impressed (as always). But it won’t be too long before that now familiar question is asked: Is there an iPhone app for this?

The Web is a place of constant change and you need to ensure that, as the interface changes, you minimize the effect it may have on the actual application.

So it will be worth your while to do a little research on the concept of Model-View-Controller (MVC). This is a design pattern, commonly used in Web applications, that allows for separation of application logic/data from the input and presentation (GUI). The basic concept is as follows:

• The Model is the back-end applications (programs and database). It should be written as a set of re-usable/callable “services”. ILE programs, service programs, and procedures are ideally suited for this structure.
• The View is the interface. When talking about a Web interface, we are using HTML, CSS, and Javascript, as discussed in the previous article.
• The Controller is the code that controls the flow between the View and the Model: it receives input from the client (in this instance, a browser), calls the appropriate functions in the Model, and generates the next View to be returned to the client.

Basically, your back-end application should be fully modularized and make full use of ILE functionality.

You Need a Web Server

To communicate with the Web you need a Web server. The IBM i provides two built-in Web servers: the Apache server (used for CGIDEV2 and PHP), and the Integrated Web Server (used for Java). The Integrated Web Server is available from V5R4 onward–prior to that you would have to make use of Websphere Application Server or Tomcat.

The basic function of a Web server is very simple–process HTTP requests from a client and return data. The data will usually be in the form of HTML, but, in reality, can be just about anything (e.g., a spreadsheet or a document). Since most of the requests will be from browsers and we are talking about Web applications, we are mostly talking about returning HTML documents.

Figure 1 shows the basic functionality of a Web server.

• An HTTP request is sent from a client (a browser). How do we know it is an HTTP request? Ever notice that http:// at the start of a URL in your browser?
• The Web server determines if the request is for a static document (i.e., a HTML document stored on the system) or for a script (i.e., call a program).
• If the request is for a static document, the document is retrieved and returned to the client.
• If the request is for a script, then the script is run (program is called). The script generates a HTML document, which is returned to the Web server which, in turn, returns it to the client.

In both instances the end result is the same–the Web server returns an HTML document to the client.

Figure 1: A Web Server.

Configuring a Web server is probably one of the most off-putting parts of getting to the Web. But the good news is that the Apache server is an open source server that runs on multiple platforms. There are a multitude of free distributions of the Apache server (such asXAMPP) that you can install on your PC. This gives the opportunity to experiment before you try it out on your i. When you are ready to bite the bullet, start the Admin server using this CL command:

STRTCPSVR SERVER(*HTTP) HTTPSVR(*ADMIN)

Then, in a browser, enter the URL of http://youri:2001, where “youri” is the name or IP address of your system, and configure away.

Or have a look at some video tutorials on configuring Apache server for use with CGIDEV2.

A Stateless World

And now we come to the real crux of developing applications for the Web and the major difference between communicating with a browser as opposed to a 5250 display.

There isn’t a permanent connection between a browser and a job on the system, as there is between a 5250 terminal and an interactive job.

A Web server consists of a number of server jobs waiting to process requests from clients. The process is that a browser sends request to run a script that results in the script running in a server job. The script generates an HTML document that is returned to the browser.

So far, all well and good. But, if the browser now makes another request to run a script (another script or the same script again), there is no guarantee that it will be the same server job that processes the request. In other words, the server jobs will process requests from multiple clients–which server job processes which client request is at the whim of the Web server.

Therefore, a script cannot assume that requests are coming from the same client, which means that it cannot store variable values (state information) between calls, as it would in a 5250 program.

Your script must handle persistence and store state information in a way that it can be accessed by all server jobs. This may be a facility provided by the language you are using (as with PHP and Java), or you may have to develop your own technique (as with CGIDEV2) using a database or a user space to store the information and issue a unique session ID (a key) to identify the state information (which is stored in the browser using cookies or a hidden field).

This may have a certain ring of familiarity to some of us older System/34 and System/36 RPG programmers. The good news is that modern RPG makes it a lot easier to handle the MRT process. Yes, some techniques just refuse to go away.

End of Part 2

Up to this point we have examined the concepts that are applicable regardless of the solution you choose: designing and maintaining the interface, tiered design, what a server does, and statelessness.

In the final article, we will compare and contrast the scripting solutions available with CGIDEV2, PHP, and Java.

Paul Tuohy is CEO of ComCon, an iSeries consulting company, and is one of the co-founders of System i Developer, which hosts the RPG & DB2 Summit conferences. He is an award-winning speaker who also speaks regularly at COMMON conferences, and is the author of “Re-engineering RPG Legacy Applications,” “The Programmers Guide to iSeries Navigator,” and the self-study course called “iSeries Navigator for Programmers.” Send your questions or comments for Paul to Ted Holt via the IT Jungle Contact page.

RELATED STORY

Get Thee to the Web, Part 1

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot