My definition of an expert in any field is a person who knows enough about what's really going on to be scared.
—P. J. Plauger, Computer Language, March 1983

I had a lot of fun finding a quote for this article, although the one I used above is a little bit on the gloomy side. One of my favorites was this: "The nine most terrifying words in the English language are, 'I'm from the government, and I'm here to help.' " Any guesses? It was Ronald Reagan. Man, he had a way with words.

Anyway, I'm from MC Press Online and I'm here to help... really! What I've noticed in recent months is that we're starting to see a lot more debate on the issue of Web application deployment, and with the recent announcements about PHP and especially MySQL, I think this is shaping up to be a really interesting time in the evolution of our platform.

Now, we all know that the Chinese curse goes something like, "May you live in interesting times," and that sometimes boring isn't so bad, but we don't have much of a choice. IBM has cast the die for us, and while the ever-expanding set of choices may seem daunting and even frightening, now is the time to figure out what the best direction is for each of us.

A Quick Preview

In this article, I'll introduce you to the options for developing Web applications. I hope this will be the first in a (short) series of articles comparing and contrasting the various supported options available to System i folks. I use the term "supported" very carefully, as opposed to "native" or "available." The three options currently supported today are HLL CGI, JSP, and now PHP.

Notice that I used the term "HLL CGI." This was deliberate, because although the vast majority of CGI work on the box has been in RPG, you could conceivably use any ILE language, including C or COBOL—or, if you had a real masochistic streak, even CL. i5/OS and OS/400 have had the capability of calling any HLL program from an HTTP server for quite some time. CGI programs are very simple: They read requests from the user and then format an HTML output stream. Every angle bracket, every slash, every tag must be formatted in the CGI program. We'll see later how the CGIDEV2 toolkit (as an example) does much of that work for you, but in general that's how CGI programs work.

JSP (short for JavaServer Pages, in case you're unfamiliar with the term) provides a slightly different capability. You write an HTML page, and interspersed in the HTML, you have small bits of Java code that plug in data. It's much more like a display file; the base HTML is similar to the constants in the DDS, while the Java bits are analogous to input and output fields. It's not quite that simple, of course, and the JSP architecture I'm outlining is specifically JSP Model 2, as opposed to the older Model 1 approach.

Then you have PHP, which is a pure scripting language. With PHP, all of your "programs" are actually scripts. These scripts are HTML pages with business logic calls interspersed. Because there is no provision for a controller, PHP is really a pure example of the Model 1 approach. Let me explain it in a little more detail.

Model-View-Controller (MVC)

One of the easiest ways to differentiate between the various approaches is by its adherence to the MVC design approach. It's really easiest to explain MVC by showing the evolution of the JSP architecture from Model 1 to Model 2.

There should be a caveat right about here. I am very much an advocate of JSP. But more specifically, I am a proponent of what I call a "thin veneer" Model 2 JSP design. While we'll see what that means in a little more detail shortly, the idea is that I like to use a very thin layer of Java, most of it in the JSP, along with a generic servlet to provide a user interface to business logic written in RPG.

Figure 1: JSP Model 1 uses a non-MVC architecture. (Click images to enlarge.)

Here, the JSP actually gets the request from the user. The JSP has to identify from the request what the user wants to do (that's the controller part of the job); then it has to go out to the database to create beans (this is the model task); and then it finally displays the data to the user (this is the view part). If you have at least some semblance of proper architecture, the database access might be encapsulated in the bean, although I've actually seen embedded SQL calls interspersed right in the HTML.

In any case, it's obvious that if anything changes, be it UI or business logic or database, you have to go to the JSP to change the code. This is sort of like putting RPG right into your display file DDS. The MVC philosophy is designed specifically to move away from that tight binding.

Figure 2: JSP Model 2 takes advantage of the MVC architecture.

As shown in Figure 2, different components have different roles in the MVC-aligned JSP Model 2 architecture. Specifically, you have a servlet that responds to the user input and determines the next page to display. It then instantiates any beans that are needed by the page; these make up the model. Finally the servlet hands control to the JSP, which performs its view role by displaying the model.

There are a number of advantages to this approach, ranging from the ability to have different views for different users very easily without changing any business logic (other than identifying a different JSP to display), to the inherent future-proofing of being able to simply slap on a different view when a new UI technology comes around (for example, it's quite easy to have one JSP for a full browser and a different JSP for a cell phone and then be able to add a new JSP whenever a new device comes along).

Comparing the Three Dialects

I will introduce you to each of the technologies by introducing you to a very simple customer inquiry page in each language and letting you compare them. The examples are not going to be entirely complete and will in fact be missing the majority of the setup work required to get the programs up and running. However, this first article is designed solely to give you a brief taste of each technique.

RPG-CGI

In my introduction I talked about "HLL CGI" and stated that you could use any System i language to develop CGI programs. However, I am going to focus on the technique that is far and away the most popular: CGIDEV2. Several commercial products work similarly; I think the granddaddy of them all is Brad Stone's eRPG SDK. Anyway, the majority of these types of tools use a template that you populate in your program.

Figure 3: This is a simple CGIDEV2 page.

As you can see from the example above, CGI follows a pretty simple philosophy: Read in the template, fill in the substitution variables, and write out the HTML to the browser. Each template can contain multiple "snippets" of HTML, and you can write them out in any order. Thus, in the case of a table, you create a snippet for a single row and then write out that snippet once for each row in the table. I want to avoid the complexities, but you can actually have multiple templates loaded, and you can write from different templates. This would allow you to do some interesting modularization of Web pages.

Note I've offloaded the actual business logic of getting the customer to a separate program. That's because I want to use that same program in the other examples in order to give you as much of an apples-to-apples comparison as I can. All three Web application samples will call the GETCUST program to get the customer name. While it would be much easier in CGIDEV2 to simply CHAIN out to the customer file, I'm trying to keep a level playing field. I'll try to delineate the pros and cons of each development environment at a later date. And in reality, for all but the simplest inquiries, the code for the underlying business logic of any Web application will be more complex than a simple CHAIN, so you would want to encapsulate it anyway. That way, you can move to another UI technology with much less difficulty, as well as reuse the business logic for anything from a green-screen program to a Web service.

JSP

Figure 4: This is a similar function using a JSP.

JSPs function a little differently. With a JSP, you send beans to the session, and then the JSP pulls values out of those beans as it needs them. As you can see from the figure, a JSP Model 2 approach uses three separate components: the JSP itself, the servlet, and the bean. The JSP contains the HTML along with some bits of Java that pull code out of a bean. The servlet creates a bean, puts it into the session, and then invokes the actual page. The bean itself uses a PCML document to invoke the GETCUST program.

There are some nice features with this approach; since the data is "pulled" by the JSP rather than pushed by the RPG program (as is the case in CGIDEV2), you can create business logic that develops generic beans and then let different JSPs use different pieces of the data. For example, you might have company, user, and session information in a single session bean and pull only the various pieces and display them as you need them. In a template approach such as CGIDEV2, you need to know all of the fields in the template and update each one in your RPG program. Not only that, but session-level information can be added to the session once at the beginning and can be pulled by every page without having to specifically merge it in the RPG logic each time.

Note: I did cheat a little bit in that I'm not including the PCML document that is used to call the program. It's basically a four-line XML document that identifies the program to call and its parameters. Here's the PCML document used to identify the GETCUST program:

PHP

The PHP version is a bit different. Even though Zend has done a masterful job of enabling its Core PHP interpreter into i5/OS, it's still a little bulky when it comes to calling existing business logic. Also, please note that while these are just snippets and really haven't been tested, I'm pretty confident in my CGI and JSP code, but I'm not as certain of the PHP code. If anybody notices some really egregious errors on my part, please let me know in the forums so we don't mislead anyone too badly.

Figure 5: Here is the PHP version of the customer display page.

The first thing you will notice is that there is only one piece of code for the entire page. I've reduced the code a little bit by not including the lines that require you to define the PCML as a string variable. My guess is that you could probably read that document from a file if you needed it, but I worry a little about performance. But that's not relevant to today's discussion.

Instead, you can see how you define the connection and then the program. Throughout these examples I've avoided even the most basic (and even required) error checking; while crucial to a good Web application, it would only complicate the issues here, especially since PHP has two completely different error mechanisms (the "or die" clause and the more Java-like exception technique).

Comparison

If nothing else, this shows you the distinct component structure of each technique. CGIDEV2 relies on a template that is filled by an RPG program. JSP uses beans to send data to a JSP. PHP combines business logic and HTML into a single script. That's of course a gross over-simplification, and I need to go through a number of additional examples to show you how the techniques really compare.

Also missing from today's introduction is any discussion of the setup involved. In general, CGIDEV2 is relatively simple and uses nothing more than some simple Apache directives, while JSP requires the use of WebSphere Application Server and of course the knowledge of Java. PHP actually runs in the PASE environment and does some rather complicated maneuvers under the covers, including, as I understand it, proxying requests from the primary Apache HTTP server to another one running in the PASE environment. I'm not entirely clear on the whole architecture, and I hope I can give you more definitive information a little later.

For now, though, since Zend shields you from most of that stuff, I think it's safe to say that from a pure initial complexity standpoint, PHP is right in the middle between CGIDEV2 and JSP. If there is interest, I might look at writing a simple tutorial piece on building and deploying the simple program I've shown here in each of the major Web dialects. We might even be able to broaden the scope a little to include non-IBM approaches such as ASP.NET or Python or even Ruby.

However, I think there's still more information needed on the basics of these three languages. In the next article on this subject, I hope to compare some slightly more complex business logic examples, including how to handle one of the more common requirements in the business application world: enabling and disabling input fields.

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. and has been extending the IBM midrange since the days of the IBM System/3. Joe uses WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. He has written several books, including E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step. Joe performs onsite mentoring and speaks at user groups around the country. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..