The Four Hundred

The evolution of application development on OS/400 servers is a case study in conformity and conflict. The conformity has its deep roots in the green screen, and the conflict comes in moving to Web interfaces. Alison Butterill has persevered through more than 20 years in the midrange and is currently IBM's technical advocate for application development. With WebSphere embracing the Eclipse environment, it's Butterill's job to explain IBM's strategy and persuade those who are uncertain that WebSphere is the path they want to follow.

Butterill works at IBM's Toronto Software Laboratory. She is a frequent speaker at technical conferences around the world, where she discusses IBM's next generation of application development tools and development environments. I spoke with Butterill at the iSeries and AS/400 Technical Conference last month in Naples, Florida, where she presented several sessions, including iSeries Application Directions. Here's her take on where we are with WebSphere, Eclipse, and the efforts to modernize application development on the iSeries.

Give us a brief overview of the new Eclipse-based WebSphere Studio Workbench and what it offers in the way of Web development.

In June, a new suite of client development tools was announced. It is not really a suite, but I'm going to call it that for a moment. It's really a completely integrated development environment based on a framework technology that allows you to plug in various tools to do whatever type of development work you need to do.

We took the infrastructure out of our individual tools and built it into one workbench, which now provides the infrastructure and some basic function, and then there are individual tools to do specific jobs like Web development or WebFacing. Each of those has become a plug-in to the underlying workbench. All of the tools are similar in look and feel, and the user interface is similar from one to another. Programmers can easily flip between different perspectives--different views--of the development projects they are working on. This is much different from launching individual tools, managing multiple tools, and importing multiple projects.

Please bring us up to date on what previous WebSphere development tools for iSeries have been built to run on the Eclipse platform.

The first tools were a suite of plug-ins, or components, called WebSphere Studio Application Developer. That product is a full-blown integrated environment, including support for J2EE [Java 2 Enterprise Edition] standards and EJB [Enterprise JavaBean], that was first shipped in December 2001.

Also created, in March 2002, was a set of tools called WebSphere Studio Site Developer. It includes all of the functions for someone maintaining a Web site, the tools that help create HTML, JSPs [JavaServer Pages], and servlets. It does not include the tools for creating EJBs. That's the WebSphere Studio Application Developer. Application Developer incorporates all the Site Developer function and adds more.

Site Developer is the tool we [the IBM iSeries Application Development Labs in Toronto, Canada] used to build our iSeries tools on top of. So iSeries customers get a customized "iSeries-ized" version of WebSphere Studio Site Developer. That includes everything that a Site Developer license would give them, plus all the iSeries function, such as WebFacing, some of the CODE/400 function, and the iSeries extension for Java. These functions are delivered as plug-ins.

These tools are built to run on the first version of Eclipse. A second version of Eclipse is expected to be ready later this summer, and this new version is said to be a dramatic improvement over the first, which was panned for being slow and clunky. How do you describe the evolution of Eclipse and what it will mean to the evolution of the development tools?

Anytime you are introducing a technology that is supposed to incorporate so much function, it's going to take one or two tries before it gets right. We heard the complaints you mentioned: It's not as functional as users thought it would be; it's too stringent, and not flexible enough. But the concerns come more often from the tool vendor community than from the end users. The vendors are right to make noise about this, because if we want them to play in our ballpark, we have to set the rules of the game and make sure they are valid for everybody. And we can't change them.

The functionality that is found in Eclipse is not as important to the end user as it is to the tool vendors. Eclipse, as a workbench, has a lot of function that the average end user of a development tool will think is absolutely wonderful.

Where we get concern is from the vendors trying to create the plug-ins to the workbench. They say some of the interfaces aren't as well documented as they should be. They are afraid that when they change to Workbench 2, they will have to recode to accommodate the new changes.

The vendors that are in the Eclipse program with us are very active and vocal in what we are doing. I don't think the vendors are having a problem with us standardizing some things and creating some more flexible interfaces. They have helped us set that direction.

We will migrate our current tools as the new technologies roll into the workbench. We will update the tool suite to be able to use new functions. It won't be instantaneous, but it will be shortly thereafter.

Let's talk about the iSeries end users. Why will Web development with WebSphere on Eclipse be an attraction for developers?

There is one interface for managing all the development projects, regardless of which environment is targeted. Before Eclipse, your Java development projects existed in VisualAge for Java and Web development projects existed in WebSphere Studio. If you needed components to cross over, it required importing and exporting projects, and it was difficult to manage. Now it's done in one environment, and there is one list of projects. When a project crosses over, it is seen in multiple perspectives. So if an application has both Java objects and Web objects, that development shows up in both the Java perspective and the Web perspective.

Also, skills-transfer between the projects used to be more difficult. There were certain ways of doing things with each tool. It's now one. All the tools have a similar look and feel.

Because the infrastructure has been removed from the individual tools and put on the workbench, it provides perspective: This is how the windows will appear; this is the behavior. It means, when we want to deliver a new function, the concentration is on the function, not on delivering the entire infrastructure every time.

For tool vendors it means they can deliver the function faster, because they don't have to build an entire tool around it. It makes them more responsive to technology changes and business requirements. It supports multiple Java run times and allows testing in a choice of environments and with a choice of plug-ins.

We will be integrating more of our existing tool suite[SP1] into the Eclipse-based tools. This time CODE/400 was not completely integrated into the tool. For the time being, the tool has just the editor portion from CODE/400. So the next thing is to add a lot more of the CODE/400 function. CODE/400 was not written in Java initially. We are writing it in Java now and putting it in [the tool]. One of our targets over the next several releases is to move all of CODE into the Eclipse workbench. So it will be launched as part of the development environment. It is one of the flagship products for our toolset.

You will probably see more extensions to the existing tools . . . more iSeries-specific stuff. And, of course, we will need to make it all work on the new Eclipse version 2 workbench.

It's always difficult to talk about the iSeries application development world without mentioning green-screen development. Would you characterize the efforts of the IBM application development team as being instrumental to moving developers off the green screens?

Bingo! I wouldn't say it's solely our efforts, but if the development community will not move off green-screen development tools then how are we ever going to create anything that is a non-green-screen application? That's one of our biggest challenges. The development community knows and loves that whole PDM set of tools, and until we can get them out of their comfort zone and into something a little more modern, we are never going to see applications change.

Our goal is to change the look and feel of applications. We are trying to do that with WebFacing. But our first hurdle is getting the development community to agree to look at the client-based development tools that will let them create more than a green screen.

There are a number of initiatives going on. There's WebSphere Commerce Suite, building a product that will offer a quick way to the Web through e-commerce types of shopping/ordering applications. Client Access is doing things with Host Publisher to try to get people off the green screen.

I heard a lab director from the Toronto Lab, a couple of years ago, tell a group of customers that the iSeries had "the capability to do so much for so long, but unless we can get people to actually do it in their application code, the perception of the tired box stays the same."

It's the application code that's tired, not the box. We need to modernize the applications in order to make the box appear more modern.

Are we solely responsible for getting everyone off the green screens? No, but without us, we aren't going anywhere. Without the cooperation of developers, it's never going to happen.

Alison Butterill has more than 20 years of experience in the IT industry and is currently an IBM-certified consulting IT specialist at the IBM Toronto Software Lab. She can be reached at butteril@ca.ibm.com.