This article is not an endorsement of one type of Web architecture or another. As always, such decisions are business decisions, and your mileage may vary. If you were to ask me what I think the theoretical "best" solution is, I would say that in most cases JSP Model II with an RPG back-end is the best, which falls squarely into the WebSphere camp (or Tomcat, or a number of other J2EE Web application servers). But if it is your responsibility to determine the best solution for your company, you should explore the other technologies available. I'll give you a little background of Web application design and then get right into the various methods for creating Web applications that don't involve WebSphere. Finally, I'll briefly compare the Java approach to the others.

Given the focus of this article, I'd like to introduce the iSeries Application Architecture Initiative (IAAI). This fledgling Web site was created to identify and compare various application strategies and to provide quantitative benchmarks of different technologies. The Web site is still in its infancy, but we're adding content daily and we'd love as much participation as possible.

Now, on to today's topics:

• Static vs. dynamic content
• Client-side vs. server-side
• ColdFusion, ASP, and Domino
• Common Gateway Interface (CGI)
• Scripting languages
• Servlets and JavaServer Pages (JSPs)

Static vs. Dynamic Content

At the highest level, there are two kinds of Web content: static and dynamic. At its simplest, static content is simply a bunch of HTML stored in a text document. Such static pages generally don't change from day to day, much less in reaction to user input, so they cannot be used for interactive Web applications. Dynamic content is more fluid. It usually combines static elements with other data, often read from a database or calculated by a program. Dynamic content can be as simple as displaying the current date and time or as complex as a full-blown order entry system.

The original Web was designed primarily for static content, and thus HTML is primarily an output-focused language. Its input capabilities are primitive, and its user interaction almost non-existent. Today's Web applications require much more. That's why various methods have been employed to interact with the user and generate content dynamically, and all but the simplest user interface will require some help in the form of JavaScript to be really useful.

Client-Side vs. Server-Side

Dynamic Web content can be further broken down into two primary categories. With server-side generation, a program running on the host generates some or all of the HTML, which is then transmitted to the browser. With a completely server-side architecture, only HTML is sent to the browser, which then renders it. With client-side generation, code runs inside the browser to generate the user interface.
Client-side generation can be accomplished with JavaScript, with applets, or on Windows machines with classical (pre-.NET) ActiveX components. Each of these techniques runs code on the client to generate the UI. While very powerful, these techniques are not the focus of today's article. Note also that client-side and server-side generation can be (and usually are) used together on the same Web page. In particular, server-side code can be used to generate JavaScript, which is then run on the client, creating a very powerful multi-tiered architecture.

The Proprietary Solutions: ColdFusion, ASP, and Domino

Before I get into the real subject of this article, I'd like to present the original players in this marketplace. Back in the mid-'90s, before CGI and scripting languages were common in the commercial marketplace, there were a few proprietary server-side scripting languages. These languages still exist, and while they may not be growing in popularity like the newcomers, they still have their adherents.

Each of these products requires special (read: expensive) server software on the Web host, and each has its own syntax. It's difficult to get hard figures on the number of sites using the various solutions, but it's likely that more sites use ASP than the other two because all you need to run ASP pages is an IIS server, and most Web hosting providers have IIS servers. (Not only that, but reliable sources tell me that it used to be pretty easy to get your hands on a bootleg copy of IIS.) ColdFusion, acquired by Macromedia from Allaire, was at one time the biggest player in the commercial marketplace; tens of thousands of sites use ColdFusion. Again, numbers are hard to come by, but ColdFusion is still a large presence in the corporate world, and while its syntax is definitely getting a bit long in the tooth, CF enthusiasts are passionate in their love of the language. If you simply count the number of installations, Domino is perhaps the least popular of the three, but its embrace of Java as a programming language and the acquisition of Lotus by IBM have probably added some life to an otherwise declining solution.

Now that I've covered the proprietary solutions, I'd like to turn to the "free" options.

CGI and Scripting

"Free" is a relative term, but in general these solutions do not require licenses other than those you already have for your machine. Even the most "expensive" solution based on entry cost, RPG CGI, is free for anybody who has an iSeries and a compiler.

So now we come to CGI and scripting languages. The CGI specification was developed in the mid-'90s to allow a Web server to invoke a program on the server to generate HTML dynamically. How the program operates is of no concern to the Web server, though there are two primary methods: calling compiled programs that generate HTML or calling interpreters that process scripts to generate HTML.

The difference between the two is pretty specific: A CGI program is a compiled program that generates all the HTML internally, while scripting language interpreters process additional script files to generate the HTML. CGI programs are written in compiled languages such as C or RPG, while scripting languages such as Perl and PHP pass through an interpreter. The line blurs a little bit with some of the advanced CGI techniques; compiled CGI programs may also read "templates," which are similar in nature to scripts. However, the processing of a template is typically still hard-coded in the CGI program, whereas the script language interpreters are entirely controlled by the scripts themselves.

For iSeries developers, the quickest way to the Web is probably RPG CGI . While RPG is not intrinsically well-suited for CGI programming, RPG CGI has one unassailable advantage over other methods: RPG programmers don't need to learn a new language. There are books on the subject (such as Brad Stone's e-RPG books), and there are free development tools available (such as the powerful CGIDEV2 library available from the Easy400 Web site or Bob Cozzi's original CGITOOLS service program). These tools provide wrappers around the somewhat-difficult-to-use APIs that are required to write CGI programs.

Programmers familiar with other platforms might try developing CGI programs in C or C++, but neither of these languages is particularly well-suited for CGI programming. Multi-purpose compiled languages simply don't do as well for Web development as scripting languages.

Scripting Languages

So why are scripting languages so good for CGI development? Primarily because HTML by its nature is a text-based environment. RPG deals with fixed data records very nicely, and C and C++ are best suited for low-level systems programming, dealing at the bit and byte level. But HTML is a stream-oriented protocol: The Web application server sends a stream of text to the browser, which interprets the stream and renders it into graphics. (You might think C is suited to streams, but really it's too low-level a language for all the repetitive work required for Web programming; you can see a good example of this at Jukka Korpela's Web site.)

Few compiled languages were particularly comfortable in the Web programming arena, but that didn't mean all was lost. A particular class of languages mostly deriving from the UNIX platform loves stream files. These "scripting languages" are designed to support the transformation of text files from one format to another and as such are better suited to Web design from the very start.

Now, when I say "scripting languages," I don't mean that such languages are only good for quick, one-time programs (although they certainly excel in that department). Instead, these languages share a few basic characteristics. They are interpreted, which means no compilation is needed--hence, a fast development cycle. They are designed for rapid development: You don't have to declare variable types or even declare the variables at all. And finally, these languages tend to have sophisticated built-in libraries for supporting basic functions like text and files, functions that typically require you to write your own support routines in the compiled languages. Some of the more sophisticated so-called "second generation" scripting languages have support for high-level Web development functions like HTTP communications.

General-Purpose Scripting Languages

There are probably dozens of different scripting languages. Many are general-purpose scripting languages that are often used in CGI development: Perl and Python are two of those. It's important to note that nearly any language can conceivably be used as a CGI programming language, especially in the UNIX environment. For example, a simple Bourne shell script can be used as a CGI program:

Invoked as a CGI program, this program outputs a simple Web page that prints a hello message and the current time and date. Thus, it is clear that any language that outputs data can theoretically be used for Web page development. In reality, certain requirements, such as error handling or performance, rule out some of the languages from practical use, but it is important to note that "scripting language" does not mean "Web development language."

Some general-purpose languages are better than others for Web development. Perl is designed to process any type of data and generate reports, so it is well-suited to generating dynamic HTML. Python is another language that can be used for many purposes, and it has a number of functions in its built-in library that are designed specifically for Web programming.

Web-Specific Scripting Languages

The three commercial products I mentioned earlier in this article--ColdFusion, ASP, and Domino--are all scripting languages. Another commercial product (but free to iSeries developers) is Net.Data. And while Net.Data is perhaps losing ground to other IBM initiatives, it's still a powerful and easy-to-use language.

The difference between general-purpose languages and Web scripting languages is that the Web scripting languages tend to be a superset of HTML. Domino is a little different in that it has it's own concepts for just about everything, but the rest of the languages are really just HTML with macro extensions. Take a simple ColdFusion example:

Note that, unlike the Bourne shell example earlier, this example includes no specific "print" statements to output the constant HTML tags. Typical scripting languages include some sort of special syntax that changes the mode from "output whatever is in the script" to "execute the special commands." In ColdFusion, they are tags that start with the letters "cf." PHP is slightly different:

The PHP code is contained within the "online tutorial.

Servlets and JavaServer Pages (JSPs)

So how do servlets and JSPs compare to these approaches? Well, by themselves, they really don't offer a lot of advantages. Servlets are essentially CGI programs written in Java. And while Java may have some superior string-handling capabilities, it's still a new language to learn, and you have the same problems as you have with other CGI programs in that you have to format all the HTML yourself. JSPs, on the other and, use what is really a Web-specific scripting language, although the "scripting" part is actually written in Java. So while it's a little easier to write the HTML for the page, you still have to know Java to add the dynamic content. Add to this the fact that both techniques require a Web application server and the J2EE techniques don't provide any real benefits other than portability.

This changes with the introduction of the JSP Model II architecture. Without spending a lot of time on the subject, the concept of JSP Model II is a true division of duties, where a servlet invokes a back-end processor to retrieve data and then sends that data to a JSP where it is formatted for display. This architecture promotes an n-tiered, multi-language approach that provides for excellent reuse and security. None of the CGI approaches provide this sort of separation naturally. The scripting languages in particular tend to encourage the use of embedded SQL statements in the UI layer, an architectural approach that has traditionally caused problems during maintenance.

So Which Is Better, CGI or J2EE?

This is really the big debate, and as I said at the beginning, it's a business decision. You need to weigh the pros and cons of the various approaches as they apply to your particular business environment. For example, one of the biggest issues with the J2EE technique is that you need a separate Web application server such as WebSphere or Tomcat. CGI programs only require your basic Apache HTTP server and maybe an Apache mod file for performance reasons. There's also the whole Java issue; many people just aren't prepared to learn Java. So if either of those is a sticking point in your decision-making process, you may want to stick with CGI, especially since the tools keep getting better. Not only that, but there are lots of resources out there, especially for the older, more established solutions. One good place to start is the CGI Resource Index.

This can be the deciding factor. If you can find an available open-source solution that comes close to meeting your needs, you may be able to reduce your development time significantly. And while the Java open-source community has a lot of great packages that help development, some of the other communities offer entire applications. I've introduced you to the various options; it's now your job to determine what best fits your business requirements.

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been working in the field since the late 1970s and has made a career of extending the IBM midrange, starting back in the days of the IBM System/3. Joe has used 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. Joe is also the author of E-Deployment: The Fastest Path to the Web and Eclipse: Step by Step, with WDSC: Step by Step coming out this October. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He 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 Developing Web 2.0 Applications with EGL for IBM i, 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..

---

MC Press books written by Joe Pluta available now on the MC Press Bookstore.

		Developing Web 2.0 Applications with EGL for IBM i Joe Pluta introduces you to EGL Rich UI and IBM’s Rational Developer for the IBM i platform. List Price $39.95 Now On Sale
		WDSC: Step by Step Discover incredibly powerful WDSC with this easy-to-understand yet thorough introduction. List Price $74.95 Now On Sale
		Eclipse: Step by Step Quickly get up to speed and productivity using Eclipse. List Price $59.00 Now On Sale

Also Read

Open Source Starter Guide for IBM i Developers: Language Basics

Open Source Starter Guide for IBM i Developers: Ruby and IBM i, An Introduction

Open Source Starter Guide for IBM i Developers: i Object!