11
Wed, Dec
4 New Articles

Weaving WebSphere: Comparing the Web Languages

Development Tools
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

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.

http://www.mcpressonline.com/articles/images/2002/070606AD%20(WW)%20-%20Comparing%20The%20Web%20LanguagesV300.png

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.


http://www.mcpressonline.com/articles/images/2002/070606AD%20(WW)%20-%20Comparing%20The%20Web%20LanguagesV301.png

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.

http://www.mcpressonline.com/articles/images/2002/070606AD%20(WW)%20-%20Comparing%20The%20Web%20LanguagesV302.jpg

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

http://www.mcpressonline.com/articles/images/2002/070606AD%20(WW)%20-%20Comparing%20The%20Web%20LanguagesV303.jpg

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.

http://www.mcpressonline.com/articles/images/2002/070606AD%20(WW)%20-%20Comparing%20The%20Web%20LanguagesV304.jpg

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..

BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now!  Request Now.

  • SB HelpSystems ROBOT GenericForms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: