Evaluate your IBM i GUI options. Compare RPG, PHP, .NET, and Java.

If you are a developer on the IBM i, you probably realize that one of the biggest demands from users is a better interface. And you've probably wondered what you should look at besides WebSphere. I know I have been pondering solutions for a long time. The problem in our shop has always been with the high reliability and superior quality of the system. That probably doesn't make sense. How could reliability and quality be a problem? Well, because of this, the system requires only a small amount of people to support a large group of users.

Because you have a small staff with a steadily running system, it would seem frivolous to the budget to hire more people. But if you had just one more programmer on the staff, you could actually work on something that wouldn't directly increase the bottom line but would inherently increase the value of the system. Using the existing IBM i would fully display the capabilities of your system, with the muscle of your proven IBM i logic running behind the scenes. And that would nullify any reasons to buy a whole new system just because it looks better. The result: the users are happy with the software they're using and the service being provided, and the company saves money.

Management's Wandering Eye for a "Prettier" and "Cheaper" solution

To put it another way, your IBM i has been running solidly for years and starts getting taken for granted.  People forget about the nightmares of servers crashing and the system being offline on a regular basis for system updates. And when stories of viruses and hacked servers are occurring, you have the feeling of "it couldn't happen to me" because you are relying on your inherent security and the fact that the IBM i isn't high on hackers' targeted lists.

So those pretty GUIs with the charts and graphs (and smaller price tags) catch the wandering eye of management.  And if that happens, all of those forgotten problems will be put back on the table.  So let's prevent that from happening by evaluating some application server options out there to provide that GUI front-end. And while we're at it, let's consider modernizing our reporting and distribution system and expanding the reach of our IBM i resources while implementing new coding capabilities to support any system that comes your way.

The Options

There are many options out there, which means a lot of information to absorb. Making a choice may seem overwhelming. So let's look at some of the options that I researched for my company and evaluate the pros and cons of each.

RPG

For the RPG option, we were initially looking at its use only internally, but as the research was maturing, we were also considering implementations on the Internet, which created other factors to consider. So I will split the RPG option into two environments.

Internally on the Intranet

For an RPG programmer, RPG would be the obvious place to start and would be the easiest way to implement your new GUI interface. I was initially looking at CGIDEV2 to provide the answers. Unfortunately, I was researching this option just around the time that IBM announced that it would no longer support CGIDEV2. So we decided against it. Even after IBM announced that it would support CGIDEV2 again, it was discouraging to know that CGIDEV2 was teetering on the edge of being dropped.

We did not want to dedicate our training and development efforts into an area that could be discontinued and have to start all over again and be even further behind with the other options that were available.

Externally on the Internet

Security was a big concern for us. On the IBM i, we had a great team of RPG programmers and administrators, and we relied on the built-in security that the IBM i provided. But we were not willing to make our IBM i directly accessible via the Internet. We had great security resources, but their specialties were in Windows and Unix/Linux; they knew hardly anything about the IBM i. So everything would be fine when the IBM i was running, but if we were ever hacked, we would pretty much be on our own with IBM tech support on the phone.

Cost was not a concern internally because we were already using IBM i for business purposes, and the extra load would not significantly impact the current performance of the system. However, cost became a major factor when considering the Internet. It was a lot cheaper to throw redundant Windows servers or Linux servers out into the DMZ to get beat on by traffic and hackers than it was to purchase redundant IBM i systems. And to provide an IBM i for the sheer purpose of Web hosting seemed like overkill. If money hadn't been an issue, real-time RPG horsepower may have been an option.

Because the RPG programming staff is minimal and the Internet talents are unfamiliar with RPG, going with the RPG option wouldn't easily integrate with other departments, where other options were more easily shared among the existing resources. My objective was to provide a GUI interface internally to our existing RPG programs, and I had the foresight to ensure it would integrate easily with our Internet resources.

On the Internet side of things, we wanted to be able to provide business components that could be reused both internally and externally and that had the adaptability to work on multiple platforms. These components could be handed off to a graphic designer and webmaster to pretty it up, without the RPG staff becoming the middleman to deploy and maintain the corporate Web site.

We never did pursue the RPG option, so I have nothing positive to say about this option. I am only discussing the reasons we never did. For those of you who have implemented this solution, I would be happy to hear your comments. I am sure CGIDEV2 is a great product, but we were not willing to gamble on a product that IBM was sending mixed signals about.

PHP

PHP is great for building a Web interface to your IBM i! It has an IBM i toolkit that provides access to IBM i objects and programs. I have a few years of C programming experience and found PHP extremely easy to learn. PHP runs very fast and can easily integrate with other media departments. And by the way, if you're a developer, PHP is a marketable talent to have under your belt.

If a Web interface is what you're looking for, PHP fits the bill. You can create your PHP pages and have them easily access your database and your RPG programs. You can run it on your IBM i along with Apache, and you'll have a graphical interface running relatively painlessly as a new layer on top of your IBM i. And PHP runs on just about any server, so if you decide to reuse your applications on the Internet, you only need to modify your IBM i-specific code to point to your Internet-safe databases. And your skill set can support both environments.

PHP is typically bundled with Apache and the MySQL database, a combination referred to as AMP. You can use AMP on the IBM i and Windows. I once built an electronic document management system on Linux with AMP, a combination referred to as LAMP. That project was a success in its functionality and was combined with ImageMagick to perform image conversions. Unfortunately, the client didn't feel that the interface was rich enough, so the result was to create the primary interface with Java and keep the PHP portion for reporting purposes. But that's not to say that PHP couldn't do the job. The Java-PHP combo was the preference of the client, and it's something to keep in mind if you are looking for a richer interface.

Microsoft .NET

Being that this audience is of the IBM genre, I will begin the Microsoft discussion with the well-known cons and try to end it optimistically with the pros.

Con 1: Implementation Options

The complete Microsoft solution… You can use Microsoft products for the integrated development environment (IDE), Web server, database, and operating system. I'm sure I don't need to tell you that if you choose this option, you will be obligating yourself to a condition of being dependent upon nothing but Microsoft, with no alternatives. You'll pour money into licenses and become helpless against future releases that force you to learn the entire syntax and to upgrade all of your software, because if the email server gets upgraded, the operating system and the SQL server will be upgraded too. Then the corporate standard will probably be changed to push the updates across the board, and you'll probably want to update your code from VB to C#.

Not only will you have obligated your servers to being completely Microsoft-dependent, you'll also tie your clients to Microsoft by requiring the use of the products. Then, the products produced from your system will also be dependent upon Microsoft licensing to view things such as Excel spreadsheets, Word documents, and Microsoft Project. However, there are some alternatives available, such as OpenOffice, to overcome this.

Con 2: Learning Curve

The learning curve will be notable for an RPG programmer, as would any object-oriented programming language.

Con 3: Reliability

You will need at least one Microsoft server running Internet Information Services (IIS). There is no way around it. Your application access will have its reliability reduced to the weakest link in the chain, which would be the Microsoft server in front of the IBM i. The reliability of the Microsoft operating system is improving, but you're comparing this to the IBM i, so there is a reduction in reliability.

Con 4: Licensing and Dramatic Requirement Changes (More Licensing)

Microsoft has a reputation for dramatically changing the programming syntax, forcing you to update all of your supporting software and hardware. Yes, you can have Visual Basic programs communicate with .NET programs. But it is not an easy task to convert Visual Basic source code to C#, which is bound to be inevitable.

Pro 1: Implementation Options

The complete Microsoft solution… Yes, complete dependence can also be a good thing because it provides a complete solution. This pro is probably the biggest con for Java, which I'll be discussing next. Because Microsoft provides the complete picture with no options, there is no overhead required on the research for the options. You merely dedicate yourself to it and start figuring out how to do it. You don't worry about the components; you just use what you are given. And that could be quite productive.

Pro 2: Consistency

You are using the same vendor for the operating system and applications on both the server and the client, which ensures compatibility. As long as everything is up to date with the target version of SQL and Office, then you're set.

Pro 3: Development Tools

Visual Studio is one of the best IDEs out there.

Pro 4: Leveraging Existing Talent

You most likely already have Microsoft talent in your IT resources, which is a great benefit. You could take advantage of these resources to gain from their experience. You could also contribute to their projects by providing additional resources available on the IBM i. However, given the extreme differences between the Windows and IBM i environments, I would not expect to see much cross-training between .NET and IBM i programmers. And from my experience, Microsoft-trained personnel are reluctant to learning anything more about the IBM i than what is required.

Pro 5: Larger Resource Pool

The hiring resources are higher in quantity for Microsoft .NET programmers. And if you are looking to improve your marketability, you can't go wrong with .NET. There is always a need for a .NET programmer, no matter what the location or industry.

MS .NET Summary

In summary, if the all-in-one solution is what you are looking for and you are willing to obligate yourself to satisfying all of Microsoft's software and licensing requirements, then Microsoft would the answer.

I believe that once you start using Microsoft on the front-end of your IBM i, it may become difficult in the future to justify the use of the IBM i in the background, given the competing Microsoft solutions that could be standardized throughout the entire system. The advantage is homogenizing your staff's resources to one platform. So I would most likely see using .NET on the front-end of your IBM i as a transitional stage into the Microsoft system replacement.

Java and WebSphere

And finally, my weapon of choice, Java! Java can functionally do anything that .NET can do, and Java can do several things that .NET can't. But, to me, the biggest one is the ability to run on the IBM i operating system.

Pro 1: OS-Independent

Java runs on any operating system, including IBM i. To me, not much more is needed, but let's continue. Just think about that. You do not need to provide another server to maintain, although you could put a Windows card inside your IBM i box. But you would still need to have that Windows license and perform the additional maintenance and updates. And whose responsibility would that be? Yours?

Pro 2: RPG Integration

To me, an RPG programmer, this would probably be the second biggest advantage that Java would have over .NET. You can use Java classes right within RPG! Through the capabilities of RPG and the use of Java Native Interface (JNI), you can access Java classes directly within your RPG programs. You can't get any more integrated with RPG than that.

Pro 3: Bi-Directional Communication from the IBM i

Sure you can put a .NET front-end onto an IBM i and access the database to create the pages. But what if you want to go the other way around? What if you want your IBM i to access the database on the Microsoft server? How would you do that? The best way to do that is with Java. I was once at a seminar that discussed the use of .NET with the IBM i, and I asked this question. The instructor said to use Java. So I said, "Now I need to know both? Why not just do it all with Java?"

Pro 4: Implementation Options

You have options when deciding how to implement. You could use IBM's WebSphere Application Server, open-source Apache Tomcat, Sun's open-source GlassFish, SAP NetWeaver Application Server, or a bunch of others! You're not obligated to choose from only one application server, so you can do the research and determine which one best suits your needs. And if one is not working out for you, you already have the trained resources and hardware, so you could migrate over to another one. I'm not saying that's a desired result, but it is an option.

Pro 5: Development Tools

Java has some excellent development tools, both free open-source tools such as Eclipse and the proprietary options such as the Rational Application Developer (RAD) and NetBeans. And because the Java IDEs are not all about one vendor's product and are open for development, numerous plug-­­ins are available to support various other languages, such as RPG, PHP, JavaScript, Ruby on Rails, Groovy, and Python.

If you have been meaning to fully get into the GUI spirit, you may want to update your RPG coding environment from SEU. What better way than to be able to code both RPG and Java within the same development tool? You can do that with the IBM Rational Developer for i. With IBM Rational Developer for i, you will have one environment in which you can code in almost any language you choose for the day.

Pro 6: Leveraging Existing Talent

Although you may not have as many Java programmers in-house as you have .NET programmers, there is a good probability that someone is around to handle everything outside of the Microsoft world. She is most likely the quiet one who always finds a way to get the job done at minimal cost, while ensuring that it will integrate with any system.

I find that Java programmers easily mesh with RPG programmers to provide synergy between the two programming environments. They are likely familiar with Unix/Linux, and if you introduce them to Qshell, they'll probably be eager to dig in. They will probably be familiar with the Apache Web server and be able to provide valuable advice on setting that up, right on your IBM i.

Pro 7: Larger Resource Pool

As with .NET, Java is one of the heavy hitters in the programming resource pool. So if you're looking to hire or to enhance your own marketability, you can't go wrong. And as I mentioned in one of my previous articles, "Being an RPG Programmer in Today''s World," there is not much syntactical difference between Java and .NET. So, if you learn one, it will be fairly easy to learn the other. And during your learning period, you don't need to spend any money on the required software. You can get everything you need for free, right down to the operating system by running Eclipse on Linux.

Con 1: Implementation Options

As with Microsoft, the implementation options can be a pro or a con, depending upon what your objective is: flexibility or simplicity. There are so many options for implementation—such as Tomcat, JBoss, WebSphere, GlassFish, and many more—that you may not know where to start. It's hard enough to decide on a programming language. Now you have to decide which components you are going to use to implement it.

Con 2: Learning Curve

The learning curve will be notable for an RPG programmer, but it is a well-invested effort. The difference with Java is that you can begin at a more gradual approach by integrating Java with RPG to start taking advantage of the benefits without having to totally obligate yourself to a completely different way of doing things.

What's the Answer?

In summary, I guess there is no easy answer. It just depends on what best meets the needs of your situation. Of course, being an RPG programmer on the IBM i, I would like to recommend RPG. But the next closest thing to that would be to recommend Java, which will give you everything you need and more.

Microsoft provides a complete solution, but the integration of Microsoft with the IBM i is nowhere close to what you can achieve with Java. It also limits your applications to running on Windows machines. But this may be a viable solution in your environment and may plausibly be the most widely acceptable option in the political realm of management.

And if you need a lighter, faster interface that can be satisfied with a Web browser, I suggest PHP, which has some great resources for the IBM i.