You tell me that it's evolution
Well you know
We all want to change the world
—The Beatles

This will be a different kind of "Weaving WebSphere." I'm going to delve into a side issue that seems to be taking a specific sector of our industry by storm, even though the issue is somewhat peripheral to what we normally do as business application developers. I suspect that, over the coming months, I may be doing more articles like this as a result of the maturing of both the industry and our beloved platform.

As the iSeries continues to evolve into perhaps the most flexible technology integration platform ever designed, one of its key features will continue to be its ability to play multiple roles in a heterogeneous network. For example, it will be able to act as a business logic server by exposing business logic through data queues or Web services to an external Content Management System (CMS), while at the same time it will be able to, as needs change, host the CMS itself.

IBM has recently made a huge move in that direction by announcing support for the PHP language; this will make an entire array of PHP-based applications available to iSeries integrators. And of course we already have Java, which opens up just as wide a range of Java applications (remember, don't call them J2EE any more; it's Java EE 5!). More and more, we'll have to use applications that have little or no direct access to either RPG or even our beloved DB2 database. Instead, they'll be standalone applications that will be integrated through Web services or stored procedures. This is the sort of thing that can make an IT manager very worried; introducing a new technology means not only more expertise required, but also another point of failure.

In today's column, I'll introduce you to CMS, which is one of the primary peripheral applications, as well as outline some of the pros and cons of some of the "other" languages out there. When it comes down to it, the most important decision may not be so much what package you use but what language you choose, because it's a decision that will influence a lot of your long-term integration tasks.

Content Management and Knowledge Management

These two topics tend to go hand in hand, especially in today's browser-based world. This is probably because they deal extensively with a common underlying fundament, that of the written word. They diverge there as well; content management (CM) veers more toward presentation and collaboration, while knowledge management (KM) is more about categorization and access, especially searching.

Of course, these two have a wide degree of overlap as well. CM requires search capabilities; as Web sites grow past a certain point, search capabilities become as important as the presentation of the data. On the other hand, regardless of how powerful a search engine it has, any KM application is only as good as its interface. It's easy to see how someone can be confused about the two concepts. However, the two topics are indeed separate, and this article will focus on CMS packages—most specifically, on packages that purport to allow you to quickly create and easily maintain large Web presences.

What Does CMS Do?

In the context of Web applications, the primary purpose of a CMS is to provide a mechanism to add content to a Web site and organize it. Different tools provide different features. For example, WDSC (as well as its immediate ancestor, Rational Web Developer) provides a very powerful WYSIWYG site designer, along with an easy way to apply templates to your site in order to create a consistent look and feel. WDSC is thus a rather rudimentary CMS tool, along the same lines as things like Microsoft's Front Page. IBM has another offering, the Easy Website Builder, that is designed to allow completely non-technical people to build Web sites. On the other end of the spectrum, you have full-blown commercial packages like Vignette, which includes portals, collaboration, document imaging, and the whole nine yards (along with lots of available consulting services, for a not-so-nominal fee).

Joe's Definition of CMS Systems

Accurately defining CMS is a problem that is pretty much endemic to the entire industry. What it means depends a lot on who is trying to sell it to you. So I'm going to narrow the range to a very specific subset of the entire genre.

1. The software must be open-source. You have to be able to get your hands on the source code.
2. The software has to allow non-programmatic maintenance of the vast majority of the content. A subject expert with no programming skills can update the site.
   
3. You must have some way of accessing iSeries data. Otherwise, it doesn't really belong in this column, does it?

That still leaves a wide array of contenders. In fact, the spectrum is still so broad that I can pick two completely different options yet leave out a whole bunch of in-betweeners. For example, let me choose based on language. I'll choose one Java option, because Java is a language entirely embraced by IBM and the iSeries and known by millions of programmers around the world. On the other end of the spectrum, I'll pick Python because it's a relatively lesser-known language, although it has achieved near-cult status among its devotees. Python is not directly supported on the iSeries, although there is a page devoted to a native port of iSeries Python that is currently a few releases behind.

Zope and Plone

OK, let's start with Zope and Plone. My currently hibernating iSeries Advanced Architecture Initiative (IAAI) Web site was originally created using Plone, and the original site took just a couple of hours. I recently downloaded the latest version of Plone and had the default site up and running in minutes (Figure 1).

Figure 1: This is a typical Plone-based Web site. (Click images to enlarge.)

Plone and Zope are Python-based, and you can get all the source code. Python is an interesting language with a lot of unique (and some would say bizarre) little quirks, but it definitely has an avid (rabid?) following, and as I said, it is available on the iSeries, albeit a little bit behind in its current release and not officially supported by IBM.

My second stipulation was that non-programmers have to be able to use it, and that's certainly the case. Zope and Plone are very flexible, and that flexibility can be a little daunting, but somebody can come in through the browser-based administration interface and maintain the content of the Web site.

Finally, the program is written in Python, which means you can technically access other languages such as Java, which in turn allows you to access the IBM Java Toolbox for the iSeries, but the connections are definitely not for the faint of heart. To top it all off, Python does not have a native access to ODBC as far as I can tell and so cannot easily access SQL Server (or other databases). There is a commercial database package, but that's about it.

Pros and Cons

The option of using Plone and Zope has some powerful positives. Zope and Plone are sort of like the Eclipse of CMS; a wide range of "products" that can be plugged into the framework are available on the Internet for download. As with Eclipse, some are free and some are commercial, and the quality varies as widely as you would expect. And as with WDSC, one bad plug-in can wipe out your existing workspace, so I encourage lots of testing prior to using one of these plug-ins.

There are even some Python plug-ins for Eclipse, so even though IBM hasn't yet officially endorsed Python, you can still edit your Python code along with the rest of your system (Figure 2):

Figure 2: This is one of the Python plug-ins for Eclipse.

So while the Python-based option is feasible, it is really very much at the outside edge of the envelope as far as what I would consider to be something I'd use in a mission-critical environment.

OpenCms, the Java-Based Option

On the far other end of the spectrum are the Java-based options. There are quite a few, with different levels of "openness." Following the guidelines I laid down, I decided to try a package called OpenCms, which is a completely open-source CMS package that is primarily targeted at the Linux/Apache/MySQL/PHP (LAMP) crowd, except using Java instead of PHP.

I downloaded OpenCms and, using the Windows installer, got it running under Apache in just a short time. Then I began what I consider to be the real test: getting it running inside of WDSC.

Why Run Inside of WDSC?

Why is this so important? To me, it's crucial that you be able to debug your applications. Even if this is closer to the "buy" side of the make-vs.-buy decision, I still want to be able to get in there and make changes, and you'll see why that's important as I continue.

First, I did a quick reconnoiter of the Apache Tomcat option. WDSC can connect to an external Tomcat instance and debug that way. However, I consider that an extreme fallback position, because it won't allow me to run on a supported iSeries server. Tomcat can indeed run on the iSeries, but it's not supported. So instead, once I got the barest capabilities running (I was able to start the Tomcat instance and run the OpenCms system inside of a WDSC browser window), I immediately moved on to using WebSphere. And at this point, things got a little more interesting.

First, the system wouldn't even start properly. It turns out that there is an obscure difference in the Java libraries. I'm still not 100% certain whether it's a JVM issue or a JRE library issue, but in any case, a couple of lines of code need to be changed in the OpenCms code for it to even initialize properly under WebSphere. I found the fix doing a little Google magic, and then I had to make the change to OpenCms.

And this is why you want source code, preferably in a language you're relatively comfortable with. I was able to pull down the source code, attach the source to the JAR files inside of WDSC, and then identify the exact place the problem was occurring. Further, I was able to include the source for just that single class into my project, make the necessary change, and have the modified version override the distribution version.

Voila! OpenCms came up! However, there was still a problem. And while I'll avoid the details of my trials and tribulations, let's just say that I had to make something of a hack into the code in order to get it to run under WebSphere (for those with way too much time on their hands, the hack has to do with changing the context from an invalid value of /WebContent to the name of the project). From a management standpoint, the important point is that I was able to make the change and get it running, as shown in Figure 3. I doubt I would have been able to make this level of change in a Python- or PHP-based solution.

Figure 3: This is OpenCms running on WebSphere 6.0 inside of WDSC.

There are other issues. First, the program won't run at all under WebSphere 5.1, at least in part due to an incompatible version of the XML parser. Second, there are still some obscure problems that look like they may have to do with the version of the JVM being used. One of the biggest problems I see for WebSphere in the future is the fact that IBM continues to lock each version of WebSphere in to a specific version of the JVM. And while I can understand that to a degree with earlier versions of Java (especially with the security aspects), I can no longer understand why it's possible for other Web application servers to run on multiple JVM versions but not WebSphere. This will continue to be a sore spot in WebSphere's acceptance in the open-source community.

Problems with this particular package aside, I have to say that from a management standpoint, I'm more comfortable with a Java package because of the level of tooling and support available for the language.

The Rest of the Spectrum

As I said, I consider Python and Java to be the ends of the language spectrum, at least as far as iSeries support and integration is concerned. I won't bother with .NET, and RPG doesn't have any CMS packages. So what's left is the middle ground, which today is almost completely populated by PHP packages. Back in the day, it would have been Perl but Perl is a more general-purpose scripting language while PHP is the current golden child of Web application development (to complete the picture, Python and Ruby are the two young upstarts). Your venerable elders are C and C++, but they're all but retired these days except among the GOP (grizzled old programmers).

Tons of PHP options are out there for just about every application, and CMS is no exception. PHP is an interesting compromise for iSeries integration because it has some stated support from IBM, yet it's not really an iSeries language and doesn't have any out-of-the-box support in WDSC. So while it's not an unsupported option like Python is today (I guess technically Python is a community-supported option, but it's a really small community), it's at the same time nowhere near as integrated into the iSeries development paradigm as RPG and Java are. Chances are, though, that you're more likely to have PHP-capable people on your staff than you are seasoned Python programmers. Then again, you're unlikely to find either of these skills among your green-screen developers, so you're still going to face a challenging integration project. However, I find it interesting that a number of programmers I know actually gravitate toward the less-strict scripting languages, such as Visual Basic and PHP. I don't know what makes a programmer lean toward Java or Python, but you really should take a good look at the skills of your staff before deciding on a language. And once you've done that, you can begin your search for the right package.

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