Setting Up A PHP/Web Environment On System i: Where Do I Start?
February 6, 2008 Hey, Brian
This is the first in a series of four articles by Brian Kelley on PHP.
Our company has been following your sometimes promising, sometimes depressing, articles and responses regarding a natural modern interface to the System i and RPG. If IBM wants to build these interfaces for its other platforms, that’s fine too, but I don’t really care about those–at least right now. Though I would like the “Good Brian” to be correct in his opinion of the IBM reorganization (see IBM’s Reorg: The Good Me or the Bad Me?), what I have seen from IBM leads me to believe that the “Bad Brian” got this one right. Since I am not sure to whom at IT Jungle to write my questions on this topic, and since your articles inspired the thought behind these questions, I am writing to you. I hope the “Good Brian” can give me some guidance. Quite frankly, our shop has had enough of the RPG limitations. It is a great business language that cannot deliver a modern look and feel to those applications that we would like to share with our clients on the Web. In frustration, we are now taking the first steps to move to an industry standard methodology that can provide the right look and feel. Right now, we are so upset that we feel that if this leads us from the System i in the future, then so be it. Everywhere I look, and now even at IBM, I keep seeing the three letters “P-H-P”. It doesn’t seem to be getting the negatives that Java got almost from day one. Brian, suppose we want to move our new application efforts to PHP or something better (if there is something better), or even a combination of approaches. Where do we go? Where do we start? How do we get this set up on our System i? How much does it cost? What else do we need? What do we need to learn besides PHP? And after you hopefully answer these questions, I have one more. This question has something to do with that “dream machine for System” notion that you wrote about in The Four Hundred, Saving the System i: Fight Pervasive with Pervasive. Is there a way that I can set up a cheap Linux server or even a Windows server or a desktop client so that I don’t have to mess with my production system to develop and test PHP applications? Any help you give will be appreciated immensely. –Dean Hi Dean, I suspect there are a number of people at IT Jungle who would love to take a crack at answering the series of questions you have asked about the PHP environment. Having just spent half of this summer working with a System i PHP client while preparing to teach my first PHP class in the fall, I am glad you picked me. As a side note, my summer experience more than strengthens my desire to have IBM take the complexity out of Web development. Just as the System/34 and subsequent GSD-vintage machines, including System i, took the pain out of developing for interactive workstations, there is a lot of room for improvement in the CGI, PHP, and WebSphere methods that IBM currently advocates. No matter what the tool, Dean, rest assured it is not a picnic taking your applications to the Web and don’t expect to see a GO LICPGM menu from IBM any time soon. I, like you, know that I cannot wait for IBM to make the RPG business programming language become Web-enabled. They still may. If IBM were going to do what we want in the short term, we would already know about it. Wouldn’t IBM be bragging about it? So, with no direction from IBM, PHP certainly has emerged as a major alternative. Yet there is a part of IBM that still suggests that for a major Web site, you should consider the WebSphere approach. Additionally, there are those who continue to advocate CGI, the earliest method of providing a dynamic Web site. CGI has its own following in IBM with the CGIDEV2 toolkit developed by Mel Rothman years ago. You can download all you want to know about CGIDEV2 at this link. Personally, I would not use this method because it is old and there are few sponsors. However, I know some folks who are very good in this trade who swear by CGIDEV2. PHP has recently become the industry standard for Web programming. With version 5 for those that like the notion of object orientation, CGI has been equipped with a number of OOPS facilities. These advanced capabilities do not take away from the original simplicity of the language. Its availability on System i opens up other options for your shop once you master all of the requisite pieces and you get an application or two under your belt. For an RPG programmer there is one thing that you may find objectionable. The language at first looks a bit like Java, C, and C++. Sorry, it looks nothing like RPG. Since RPG is one of the simplest structures to follow (once you know it), your first look at the PHP language may make you puke. Yet there are those out there who would suggest that RPG programmers are out of it in terms of what languages should look like. Just a few weeks ago, IT Jungle’s Alex Woodie interviewed Duncan Kenzie, the president of Excel Systems and one of the main developers of BCD‘s WebSmart PHP development environment, and Duncan thinks that RPG programmers would do well to get over the need for RPG-type syntax, especially when most other programming languages, besides COBOL, use what I might call the “block structure.” I think that computer science syntax should be left to the computer science guys. I’d rather everything look like RPG. AS/400 aficionados might argue that they have gotten over RPG with CL and they were not forced into the block structure and the brackets and braces notion of coding. I have seen the complaints from the best of the RPG free-form coders out there asking IBM to get rid of the semicolon at the end of each RPGIV free-format line. Even this little bit of what the computer science guys endure daily with their languages creates a sense of annoyance to those who don’t find extra work appealing. Ironically, if you are a free-form coder now, and you have become accustomed to that nasty semicolon requirement, you’ll do better with PHP than those of us still using the fixed form of RPG. Anyway, there are people out there who think it is about time that RPG people accepted that IBM is not taking the language to the Web. Once you are convinced, the good news is that it is not necessarily time to study Java, C, or C++. However, it may be time to learn their form as presented in the PHP language. Though it looks like the other block structured languages at first and it likes all of the special characters, it is much simpler to learn, read, test, debug, and deploy. Keep Duncan Kenzie’s thoughts in your frontal lobe as you move into PHP if that is your choice. He is a very smart person. In the interview, he says, “RPG programmers tend not to be familiar with common programming constructs like curly brackets and semicolons at the end of the lines and things like that, things that have been around in other languages for decades. Some people will take to it immediately and they’re productive in a couple of days, and other people will never get used to it. ‘If it’s not RPG, I can’t do it.'” Other Web Alternatives: The WebSphere Approach Of course, there are other methods that are not as comprehensive as an RPG Web GUI that can get your company to the Web much faster than building your own PHP applications. The other path of which I suspect you have some degree of awareness is the WebSphere (Web Applications Server) path. For almost a year now IBM has been shipping an internal WebSphere server and a pre-installed WebSphere Express V6.0 server with i5/OS. Both of these come without an additional charge. And, for the record from a person who has written eight WebSphere books, the new WebSphere is much easier to work with than its reputation and its past failings. WebSphere has picked up an attribute that was missing in its earlier iterations. You can now count on it. It is stable and when it crashes, you don’t have to go look for another job because it can actually recover itself. Of course, rather than use the pre-installed versions, you can choose to be very current and install the latest version of WebSphere such as V6.1, which has been available for about a year. Then you have a bit more work to do. IBM’s Web GUI Administration tool has really helped simplify managing WebSphere. You still have to understand a lot about its environment and its IFS file structures, but you have to know those things anyway to use HTTP, PHP, and MYSQL. The WebSphere server alone provides little. It is merely the price of admission to the WebSphere world. Without it, however, you cannot run any of the three or four System i software products that can be used to take your current applications and any new development to the Web. Speaking of new development, if you choose any of these methods, I would recommend one of my books, WebFacing Application Design and Development Guide, which is available from the IT Jungle Bookstore. Though this book is built around a version of WebFacing that no longer exists, its value comes from the recommended application structure for your green-screen applications so that when you bring them to the Web with any of the System i tools that we are about to discuss, they behave like point-and-click Web applications. The first and simplest of the IBM System i Web facilities to set up and use is iSeries Access for Web. In addition to a standard 5250 emulation facility, this thin-client approach provides a number of the iSeries Access for Windows (IAW) and iSeries Navigator facilities all nicely packaged in an attractive GUI form. This package is a free entitlement that comes with the same IAW that you run on your desktop. You get the CD containing 5722-XH2 and you install it with a RSTLICPGM or GO LICPGM if it is not already there. When it is installed, in a second process, you need to create a WebSphere instance and a corresponding HTTP instance and install IAWEB through either CL commands or QShell to WebSphere. The second product is HATS. There really are just three, but there is a fourth component for HATS and WebFacing (WDHT) that is a prerequisite. Because IBM uses names such as Host Application Transformation Services (HATS) that are so long and sometimes do not really do justice to the software facilities they identify, rather than use the exact IBM names, I use shorter names. The third product is WebFacing and the prerequisite fourth facility is WebSphere Development with HATS Technology (WDHT). This will also be referred to as the WDHT runtime. As of version 7 of the WDS/WDSC standard edition product the HATS toolkit, the WebFacing toolkit, and the WDHT runtime are provided with the package. Both V7 HATS and V7 WebFacing need the V7 WDHT runtime to function. Unlike the HATS toolkit and the WebFacing toolkit, the WDHT runtime is a chargeable feature. How Does WebFacing Work? With IBM’s standard WebFacing toolkit, which runs within WDSc, you convert your DDS display file source members so that the user interface of your System i RPG, COBOL or C programs can run in a browser. The PC-based WebFacing tool does the conversion. You select the 5250 application’s DDS source panels and you then deploy the new Web-based interface by first uploading it to the IFS. Once it is on the IFS, you invoke the Web GUI Admin feature–your IP address or domain name followed by a colon and 2001 for the port number–to install the uploaded application file (type EAR) to the WebSphere server. The converted (WebFaced) application consists of JavaServer Pages and XML files and other artifacts that take the place of your DDS code (display file) when operating from a Web browser. The standard WebFacing offering permits customization of the new interface. Style properties, graphics, fonts, colors, and layout can all be added to your pages, giving a look and feel that is not exactly 5250. The advanced edition of WDSC (not a free offering) carries this customization one major step further with its Cascading Style Sheets-Positioning (CSS-P) capability so that the 5250 screen panel actually can disappear as fields can be repositioned, unconstrained by the boundaries of the original 5250 area. It offers an almost unlimited ability to customize the Web-enabled interface. When the WebFacing application is running under the control of WebSphere, its Web conversation is controlled by another server module known as the WDHT runtime. The most current instructions for setting up WDSc for the WebFacing toolkit are included in the links above. Several Redbooks and a number of other good books including the iSeries Pocket WebFacing Primer and the iSeries Express Web Implementer’s Guide are also available. Because the WDSC product changes so quickly, there are no Version 7 IBM Redbooks or trade books, but any of the books written for past versions would help you get a feel for what is needed to WebFace your applications. The IBM documentation needs to be examined where specific product notions for Version 7 of the tools are required. HATS & WHDT Runtime The HATS toolkit provides similar customization to WebFacing, as well as a simple standard default template that enables you to deploy ad-hoc applications to WebSphere in much the same way as IAWEB. Like IAWEB, HATS converts system panels on the fly; but unlike IAWEB, it adds the same level of customization (if you choose) as provided by WebFacing. Thus, with system panels or application panels, you never lose the look and feel of the application. It also supports additional tailoring of any screen panel based on its screen content. Unlike WebFacing, you do not upload the display files and Web artifacts per se on the System i. HATS uses the existing panels in their compiled state (no DDS required) and it renders the Web look-and-feel on the fly. Therefore, instead of loading an application to the System i as you do with WebFacing, you would load just the general customization objects that you have built with the HATS toolkit. These then control the appearance of the ad hoc HATS panels. So, the big HATS advantage over IAWEB is that it provides a high degree of page/panel customization and it can have the same theme as a WebFaced application. Thus user menus and system menus can have the same look and feel as the heart of the application set. It also means that WebFacing and HATS applications can be mixed and the user does not know the difference. WDHT runtime is the fourth piece of the WebSphere puzzle and it is very necessary. It provides the System i runtime facilities for both WebFaced applications and HATS-driven applications. One of the major advantages of WDHT runtime besides the HATS/WebFacing intermingling support is that processing is designated as batch. Therefore, systems with minimal interactive capabilities can perform at top speed. This is in contrast to the iSeries Access for Web facility, which requires interactive CPW to drive its pages. Of course with the new 515 and 520 models, if your shop is fortunate enough to have one, this does not matter. However, with older systems it can be the Web deal killer. For a comprehensive table comparing WebFacing with HATS, go to this link. IAWEB, HATS, and WebFacing Recommendation My first recommendation is that before you even begin your PHP installation and learning process, install and examine iSeries Access for Web and HATS, and attempt to WebFace a small application and deploy it to the WebSphere server. Though it is cumbersome, working with these WebSphere facilities is substantially less difficult than working with the PHP environment to provide similar application function. Once you have the WebSphere method implemented, you can begin to develop in PHP or modify some existing applications for PHP. You will be more capable to determine which tool to use for which function if you already have some experience in the field. None of these tools cost anything additional and so it probably is time to use them. You might consider this first phase as part of your overall education since the exercise will also help you in your learning of PHP and its essentials since the elements in the solution have many similarities. I predict that you will be in class for quite a few months while at the same time inching through these installations and testing procedures. If you have a large enough staff, of course these projects can be done simultaneously, but it would behoove you and your team, after each component becomes usable, to reflect on what the component provides and how it can be effectively deployed in your shop. The reality is that with the large libraries of functions that exist in most System i shops, it would take a tremendously long time to convert to PHP without any other tooling assistance. Without a huge budget, the green-screen stuff, by definition, will be around for a long time. Having the WebSphere tools we’ve discussed can really help in your overall modernization. One major advantage is that if an application needs to come on the Web with only a day or two notice, you can actually accomplish it with the WebSphere tools–a process that would take much longer with PHP. As an aside, if IBM provides an RPG tool in the future (though the company will more than likely provide an SDA-like tool to create the page widgets, just as it helps you to know DDS), the learning investment you make now in HATS or WebFacing will pay off if IBM actually one day gives us what we want in RPG. IBM Weighs In In September of 2006, IBM came out with an excellent Redbook for helping users understand all of the various methods available to modernize your applications. IBM System i Application Modernization: Building a New Interface to Legacy Applications is informative, free for downloading, and available at this link. The PHP Environment For the last 20 or more years, whenever IBM needs to build something in hardware or in software, it asks itself if the new item is something new unto itself or something new as part of something else. If it is part of something else or should be part of something else, then IBM uses that something’s architecture to frame how the new item is to be developed. If it is the first of something that may have lots of items, then IBM defines a blueprint or architecture for the general notion and then assures that the new item implementation follows the blueprint. In simple terms, such blueprinting eliminates a lot of waste and assures that something like a building emerges from all of the items combined rather than just 695 walls, HVAC systems, 132 rooms, three staircases, five elevators and 16 floors–all independently designed. In the IBM approach, the end result is a building in which all of the bricks are the right size and they know where they are going before they are fixed in place. On the Java side, for example, IBM did not invent the J2EE architecture, but the company sure plays by its rules when in the Java area. So, one would expect that IBM would perform likewise regarding PHP and its P2EE architecture. Well that’s just silly since there is no P2EE architecture and there is no PHP architecture itself. PHP in reality is a third floor that always requires a first floor and a second floor before it can do anything. PHP is not an architecture to create a full building. Instead there are a number of individual pieces, of which PHP is one, that have learned to cooperate so that buildings can be built and can perhaps be built even better than the J2EE notion. I am not suggesting that Java would be better off without J2EE and application servers but, quite frankly, I haven’t seen J2EE help matters that much on the Java side. Ironically, there are lots of nice Java facades and Java floors and Java basements, but not many Java buildings out there. PHP and its “environment” are so much simpler conceptually than Java and J2EE that even without an architecture, the parts seem to have a sense of synergy. Let’s start with a litany of the parts. Some are optional and some are absolutely required:
The first three things you need in a typical PHP environment are listed in no particular order below:
To learn all about what I would have written if I were to have written how to download and install PHP, read PHP on i5/OS: A Whole New Stack. Author Erwin Earley from IBM tells you how to get and how to install PHP on your i5. He will also give you a good idea what PHP is and where it came from. There are some other options for learning PHP. Zend has a training courseZend Quick Start Course: PHP for RPG Programmers. Also worth taking a look is the Apache Friends Website, where you will notice that these open source folks see the Apache Web Server as the linchpin of all the Web action. It’s not “PHP,” it’s “APACHE.” They do have a point. In a chicken or egg scenario, Apache was clearly the first arrival and PHP was last–right after MYSQL. In many ways these three products are like Irish Triplets. The first version of Apache came from all of the fixes to the NCSA (National Center for Supercomputing Applications) and was released in April 1995. Rob McCool is credited with the major role in its creation, though he credits many others. According to Wikipedia, PHP was written by programmer Rasmus Lerdorf in 1994 to replace a small set of Perl scripts he had been using to maintain his personal homepage. This programmer used these Web facilities first to display his résumé and to collect Web data to see how many hits he was getting. He released PHP as a product called “Personal Home Page” tools along with a Forms Interpreter called “PHP/FI” on June 8, 1995. This is considered the first release of PHP. Since MySQL was first released internally on May 23, 1995, of the three major components, PHP is the youngest. Lerdorf was not the only PHP zealot involved in its development. Two other developers, Zeev Suraski and Andi Gutmans, rewrote the parser in 1997. This formed the basis for PHP 3. At this time Lerdorf’s notion of the personal home page derivative for PHP went out the window and the tricky techies gave the language the recursive name PHP, meaning PHP Hypertext Preprocessor. The first really functional PHP arrived in June 1998 with the new parser, and then Suraski and Gutmans started to rewrite the PHP’s core. The result of this is known as the Zend Engine. Circa 1999, they formed Zend, the company that today manages the development of PHP and with whom IBM partners to bring you a well-running PHP on i5/OS. It may seem like yesterday, but it was Friday, February 25, 2005, that Big Blue announced its partnership with Zend to create an offering called the Zend Core. The offering for System i is known as “Zend Core for i5/OS.” Originally the offering included IBM’s Cloudscape-embedded database along with Zend’s PHP development tools. The Zend Studio is Zend’s preferred IDE, but the company also has plug-ins for IBM’s Eclipse-based offerings. As part of the deal, both IBM and Zend have devoted programmers to make PHP work better with IBM’s DB2 databases, as well as Web services protocols. Having said that, the rumor mill suggests IBM is picking up the tab. Zend Core for IBM is based on PHP 5 technology and includes special modules to provide tight integration with DB2/400, and native support for XML. IBM has worked with Zend to make the installation a somewhat seamless, automated installation and configuration process using the System i’s quite painless RSTLICPGM native command. Erwin Earley’s article shows you exactly how to get your PHP installed and running. In essence the System i package is an enhanced version of the open source PHP engine designed to exploit the native DB2 database facilities of DB2/400. Right now the product delivers all of the necessary drivers and third-party libraries to work with databases, such as DB2 and MySQL–though you have to throw a switch in PHP.INI in order to get MYSQL to work. MYSQL, of course, takes on even more meaning as IBM has made available support for MYSQL to run on the System i in addition to its native DB2/400. Never say never. Even before the official release of Zend for i5/OS, some customers successfully ran PHP applications on i5/OS by porting the open source PHP engine to the System i. IBM had published a Redpaper in 2003 describing how to get this task accomplished. With PHP being big in the Linux world, and with Linux as a supported OS on the System i, IBM has had a Web site available for several years. For i5/OS aficionados this means that limited PHP support has been available and in production for some time–admittedly only for the most technical of us. When you delve deeper into how to use PHP on your client machine to develop i5/OS applications, you will see that there is no significant difference between writing PHP applications for Zend Core for i5/OS and any other platform. The main difference is in calling i5/OS-specific operating system commands and using advanced database features. To be fair, PHP and MYSQL grew up together and that is why there are so many industry standard applications available for the combination of MYSQL and PHP. No, I did not say DB2. The MYSQL interface is what PHP developers have been writing to for at least 10 years. The PHP DB2 interfaces have been out for just about two years. So, MYSQL is on System i to enable the porting of all of these existing open source free applications and free content/development managers such as Mambo, Drupal, and Joomla. Anybody other than a System i-only shop will by design have their new applications work with MYSQL so they can be easily ported. Elements that must interface with existing databases will use the PHP Toolkit to access DB2/400 data. Well, Dean, that’s about it for this part of the answer. After all, you did ask quite a few questions. In Part 2, we will explore the IBM Apache Server and the integration of the MYSQL database into the PHP picture. We’ll also show a simple example of how a very simple MYSQL application can be converted to a DB2 application. In Part 3, we will examine the development environment. You’ll see that it is not exactly the dream machine notion that we discussed in the article that you referenced in your question. However, the Windows client XAMPP distribution is worthy of sitting on all of your Web developers’ desks as it offers a tremendous development and testing platform that can save a lot of redeployments to the i5 server. In Part 4, we will look at canned PHP applications as well as the phenomenal content management packages: Mambo, Joomla, and Drupa. I sure hope Part 1 of my response helped put the major pieces in perspective and the links will help you get the job done. Hold on, next week part 2 will be here for you to gobble up. There is no real need to be impatient Dean, since the to-do list that you have from this part of the response may very well impact your skiing season. Brian Kelly was an IBM Midrange SE for 30 years, and has spent nearly a decade as a System i5 consultant based in Scranton, Pennsylvania. He is also author of dozens of AS/400, iSeries, and System i5 books and he serves as an assistant professor at Marywood University, which uses the OS/400 and i5/OS platform and teaches courses in the box as well. Kelly is also one of the contributing technical editors to The Four Hundred newsletter. He can be contacted through the IT Jungle contact page. RELATED STORIES IBM’s Reorg: The Good Me or the Bad Me? Saving the System i: Fight Pervasive with Pervasive Is PHP the Systems i’s Next RPG? PHP on i5/OS: A Whole New Stack
|