Developing multi-tiered software has become ever easier, but deploying it is a challenge that IBM Express Runtime was designed to meet.

There are two kinds of developers in the world. One kind loves to cobble together a powerful amalgam of the best-of-breed technologies, learning the arcane features of each type and mastering the subtle interactions between them. The other focuses more on the business logic and sees the enabling technologies as a means to an end. That may be a little bit of an oversimplification, but for the developer who has more deadlines than downtime, the IBM Express Runtime was designed to help deliver the goods.

The Software Stack

The phrase "software stack" came into vogue awhile back with the concept of the LAMP stack, which stands for Linux-Apache-MySQL-PHP. This stack provides all the basic services required to run applications on bare hardware. Linux is the operating system, and MySQL provides the database. Apache is the Web server, and PHP is the language used to write the business logic. Together, these pieces provide an integrated environment on which someone can program. And, theoretically, if you write your application to adhere to the basic interfaces of these components, your application can run on any similar stack.

However, the LAMP stack is more about defining an environment onto which an application can be deployed, rather than the actual application itself. I would call it an "execution stack" onto which one deploys an application. LAMP is also a bit limited; since you're just using Apache (as opposed to a Web application server), you're restricted to the scripting languages, such as PHP. On the other hand, deploying a PHP application is comparatively easy, although it's still not exactly a summer stroll.

Meanwhile, if you're one of those folks who prefers an application server and the joys of Java, then you have to alter your stack a bit. For example, the Red Hat stack includes Red Hat Linux, JBoss with Hibernate, MySQL, and Java. Believe me, there's no good acronym for that one, but I think you get the point: operating system, Web application server, database, and a programming language to tie them all together. (In the interest of unbiased reporting, I'd like to point out that there are Windows versions of the execution stack; one example includes Windows, IIS, MySQL and PHP, although the acronym is a bit unfortunate: WIMP.)

But even so, the execution stack is not the issue. The problem comes with application deployment. Tomcat has a decent structure with the Web Archive (WAR) file, but over the years it's shown some weaknesses, especially when you're trying to build applications from common components. The Enterprise Archive (EAR) file is one step higher, but it's specific to WebSphere. And both approaches have one glaring flaw: they assume you already have a software stack installed (and in the case of the EAR file, a pretty specific stack). Which means that somewhere along the line you have had to already install the execution stack. You must also have learned how to install applications into the stack, and now you have to install the application. Not a problem for a Type One developer (see the opening paragraph) but not quite so easy for someone who doesn't eat, drink, and sleep software.

The Application Stack

What's needed is an application stack. In the purest form, the application stack would consist of all the pieces of the traditional execution stack, be it either LAMP or a Java alternative, and the application besides. But on further investigation, that really doesn't make a lot of sense, primarily because of the operating system component. Most people don't expect to have to install a new operating system just to run a single application. This isn't entirely true; the recent leaps forward in virtualization technology exhibited by products such as VMWare make it much more feasible for someone to run multiple operating systems on one machine, thus making it entirely possible for the full application stack concept to work: in VMWare these are called "appliances," and they do a wonderful job. For example, my mail server is such an appliance. I used to have a separate Linux machine that ran my mail, but awhile ago I installed a virtual machine running Linux on my xSeries machine and configured it to handle my mail.

However, if you aren't running virtualized servers, it's hard to justify including the operating system as part of your stack; it's unreasonable to require that your customers have a different piece of hardware for every application and that the type and version of the operating system on that server is dictated by the application. Instead, what is needed is an application stack that consists of everything except the operating system. The stack would include a database, a user interface, and an application. In the case of a Java-based environment, that would be the Java virtual machine itself, a Web application server, and finally one or more Java EE applications. For the end user, installation is a single pass: all of the components are installed, and the application runs turnkey.

For an ISV, this has a lot of real advantages. You have not only a single deployment component, but also much tighter control over the operating environment, making it easier to avoid issues of version incompatibilities and so on. Java has a real advantage in this sort of environment. If you write your application to the Java EE specifications, it will run anywhere there's a JVM, and since you can get a JVM for just about any operating system, it gives you a wide target audience, wider for example than a pure Microsoft solution. As long as you can find OS-appropriate versions of the other non-application components (the database and application server), you can now deploy your application anywhere by simply including the appropriate pieces.

Enter IBM Express Runtime

And that's what IBM has created with the IBM Express Runtime. IBM has constructed a tool with which you can create entire deployments that include a database, a Web application server, and an application all in one nice package. The Web application server is (as you might have guessed) WebSphere Application Server Express, and the database is either DB2 Express or Informix Express. IBM also includes its HTTP Server, because frankly all Web application servers need a good front-end; even good old Tomcat runs a whole lot better with Apache on the front.

IBM has effectively sliced off the operating system component of the execution stack, creating something called the "platform stack," which consists of only the middleware pieces, including the database and application server. I think this is a fantastic idea on IBM's part; it allows them to focus specifically on the pieces they do best, such as middleware, while allowing their partners to focus on the application code.

More important, though, is the deployment aspect of the product, especially for those of us who grew up with the midrange model. The biggest hurdle today for application vendors is the environment. Back in the day of the midrange, you could write an application in RPG or COBOL for the platform of your choice and be reasonably assured that it would run on any machine of that type. With an integrated database and a completely standardized 5250 interface, there was little in the way of environmental issues that would pop up. You spent less time fighting subtle interactions of the software and more time fixing and enhancing your package. You were able to spend time customizing the software to better suit your client as opposed to trying to find out why their particular installation didn't run correctly. You don't have that luxury with servers today; issues from hardware to operating system version to anti-virus software can all play havoc with an installation, either individually or in concert. So you have to either write your software to the lowest common denominator or spend a lot of time on support calls.

The IBM Express Runtime reduces a lot of that cost by providing a way for you to control both the application and most of the operating environment. With the exception of the operating system itself, an IBM Express Runtime deployment includes every component of the software stack. And since Java EE is the underlying technology, your applications are even further insulated from the vagaries of the hardware or the operating system. Short of a virtualization engine, you can't get a much more controlled environment.

But a deployment tool is not only measured by how easy it is for the developer to create a package from an array of discrete components. The real trick of deployment is to package all these components in such a way that it's easy for the customer to install. That means that the deployment vehicle has to understand not only the individual components but also their interactions and how to make them all work together. Referring back again to the Type One developer, the biggest problem in that scenario is that the best-of-breed components often required specific installation or configuration steps to get them to work together, and while automating those steps is usually possible, that automation usually requires in-depth knowledge of the components.

IBM Express Runtime has two advantages in deployment. First, of course, is the fact that it has a relatively limited set of component configurations. IBM owns those components, and the developers know them inside and out, which leads to the second advantage of the approach: the fact that the tool can include an expert wizard that does the work for you. Building on the general capabilities of the Eclipse Platform and the Rational tooling, the Express Runtime employs something called a Deployment Wizard, which walks you through the steps required to package your application for deployment. You don't need to become an expert in DB2 or WebSphere deployment; the wizard does all of the packaging for you.

Deployment in the i Environment

The idea isn't entirely complete, at least not for IBM i developers. There is no specific capability today for packaging and deploying host programs written in ILE languages. The deployment is pretty specific to the Java application components. But installing libraries of ILE components is nowhere near as difficult as deploying a Web application. So while the Express Runtime may not make it easier to install the ILE portion of a multi-tiered application, what it does for i shops is to remove the burden of having to learn all the vagaries of deploying the Web portion of the application. Instead, the developers can focus on the actual business logic, and in these days of ever-more-complicated programming environments, that's a remarkable achievement.