Java’s Brewing on the AS/400
It’s hot. It’s powerful. And now, it’s headed to the AS/400 nearest you. What are we referring to? Java, of course. Java dominates as the programming language of choice for Web-based applications and indeed, its platform independence has completely transformed the way many business applications are both written and used. So it’s not surprising that Java on the AS/400 is considered a critical step forward in the evolution of the AS/400 platform. To learn more about what this all means for AS/400 users, MIDRANGE Systems recently spoke with IBM’s John Quarantello, AS/400 Java segment manager, and his counterpart on the AS/400 e-business side, Louise Hemond-Wilson.
MRS: Let’s start with the basics. Why is Java so important to the AS/400 community?
JQ: Java is important for application development on the AS/400 for a variety of reasons. Basically, Java provides three main things that the AS/400 needs—a language that can be used to create a graphical user interface, an environment that is designed for Network enablement and portability. With Java, AS/400 customers can extend their existing applications, and/or write new applications. And as customers look to develop Web-based applications, they should look seriously at Java because it really has become the industry standard today.
| "If you’re running applications like payroll or general ledger or accounts payable and you don’t need network-enablement or graphical support, by all means, continue to use RPG for the next 10 or 20 years." |
MRS: Java is certainly recognized for its portability and cross-platform support. In what way does this benefit the AS/400 community specifically, though?JQ: That’s the thing that we’ve always had problems with—a lot of times applications start out on a Unix machine or an NT machine, or sometimes even a 390, and over the years, we’ve found it very difficult to port those applications to the AS/400. Now, with Java, we’re able to do ports more easily—in a matter of hours in some cases. Java is an ideal environment whether you’re adding new applications to the server, or trying to attract new programmers to the AS/400 platform. I typically joke and say that there are over a million Java programmers today and they’re all AS/400 programmers, they just don’t know it yet.
MRS: Why is the AS/400 such a good platform for Java? Examples here?
JQ: The AS/400 has been optimized several different ways for Java so we think we have one of the best Java environments. Basically, we’re a Java-certified platform, which means that we meet the rules and specifications that Sun puts out to obtain certification, but then we actually took things a bit further. Instead of running the JVM (Java Virtual Machine) as an application like other servers run it, we went below the machine interface and wrote it in C++ at the very lowest layer of the operating system. So, from a performance point of view, we’ve tuned it to run as fast as it possibly can on the AS/400. So that’s one area of optimization.
Another area of optimization, that shows up in our Java Development Kit (JDK), are capabilities that allow you to maximize performance when you know you’re running on a certain type of hardware. So the Java portability is still there, but if you turn on our direct execution compiler, for example, you’re able to improve performance up to five-fold.
| "You can now have a small Java virtual machine in a ring, and if I wear this ring and I get hit by a car, they can plug my ring in and it has my medical history, my health insurance information, my attorney’s contact information, whatever." |
We’ve also optimized Java on the AS/400 for people who have existing programs and data that they want to access on the AS/400. In fact, we’re one of the few platforms that has a toolkit—the AS/400 toolkit for Java—that’s optimized to access information from the AS/400. Basically, we’ve got a set of Java classes that they can use when they’re pointing to an AS/400. This means programmers can be more productive because they don’t have to spend a lot of time programming this themselves.
MRS: Have people really started to take advantage of this? If so, can you provide some specific examples?
JQ: Probably the strongest example we have is Intentia. Intentia is one of our largest ERP vendors and they basically have rewritten their entire Movex product line to be a Java server platform. In the past, they were an RPG-only type of ERP vendor and AS/400 only. Now, with their Java environment, they not only support the AS/400, but they also support Intel platforms, Unix platforms and 390 platforms too. That’s one example that demonstrates the ability to port applications from the AS/400 to other servers. A couple of other examples, which demonstrate the use of Java to migrate applications to the AS/400, include BEA Web Logic and Bluestone. Neither of these two Web application servers were supported on the AS/400 in the past and now, through the AS/400 Toolkit for Java, their applications can be moved very easily to the AS/400.
LH: Another aspect of this is that some of our traditional partners like LANSA, through the use of WebSphere and Java, are revitalizing their offerings and are coming out with strong, complementary offerings for e-commerce using the technology. So it’s benefiting not only those partners who were never traditionally AS/400, but also those who have been with us through the long haul.
MRS: To what extent should AS/400 applications be written in Java? When is it appropriate to use Java? To use RPG? In general, does IBM support a migration or an integration strategy?
JQ: It depends. Do you want to use Java on the client, in the middle, or do you want to use Java on the back-end? There are a lot of people who would like to modernize their applications—they could be customers or ISVs that need a better look and feel. For some of them, the concern is to be able to network-enable their application, and they want graphical support. But they’re not worried about portability. For them, products like Jacada or Seagull’s JWalk are basically front-end Java clients that give you the network-enablement and the graphical user interface that people want as a browser as a client, and the back end can remain in RPG or whatever. So that’s one way for people to buy themselves a couple of years of improving an application without touching a line of code at the back end. And that’s a way of extending your applications out to the Web vs. having to rewrite them.
If you’re running applications like payroll or general ledger or accounts payable and you don’t need network-enablement or graphical support, by all means, continue to use RPG for the next 10 or 20 years. It’s a viable platform, we’re continuing to make improvements in it, and actually, I’m not convinced that those third-generation languages will ever go away. You really need to have a requirement for the things that Java provides for it to make sense for you to embrace it.
Another thing to consider is the skill set of your people. This is very important because Java is very different than RPG, and in a lot of cases you may have RPG programmers who either don’t want to or can’t learn Java because procedural programming languages like RPG, are so different from object-oriented programming languages like Java. You’ve got to make sure you have the right mix of education and training to move your staff to this environment.
LH: I think this also extends to the customer in terms of what they can consider as a client that comes to their server for processing it. It’s no longer tied to a PC desktop. You can now have a small Java virtual machine in a ring, and if I wear this ring and I get hit by a car, they can plug my ring in and it has my medical history, my health insurance information, my attorney’s contact information, whatever. We’ve completely exploded what can be considered as a client so we’ve given customers a whole new broad horizon of what they can consider a client, so that's part of it, too.
JQ: Most customers are starting to build applications for the Web that are going to involve transactions, and that’s really where Java plays very, very well because you can build things like shopping cart applications using Java servlets, or applets, or Enterprise Java Beans. And these applications are then portable across the AS/400 as well as other platforms.
MRS: This brings up an interesting issue. What about support for Enterprise JavaBeans? And are these EJB-type applications truly portable, in your opinion?
JQ: When Sun’s chief executive Scott McNealy talks about it, he came out with Java as a "Write Once, Run Everywhere" solution. Well, I’m a little more cynical—I think it’s "Write Once, Test Everywhere." But are they portable? The answer is absolutely, yes they are. In terms of how this plays from an AS/400 point of view, the way that people are going to take applications to the Web is through infrastructure and it’s through Java components. The infrastructure is provided through a product and a brand of products called WebSphere, and there are two versions of WebSphere. The standard edition, which comes free with the AS/400, and the advanced edition, that has just recently become available.
The standard edition provides support for servlets and Java Server Pages, which is basically HTML with a Java tag at the end. IBM customers like Famous Footwear and Welch Foods have shopping cart applications up on the Web today developed using WebSphere, the standard edition. Over time, we think that people are going to need more robust, better performing applications. They’re really trying to remove the application developer from the infrastructure to have them focus on the business logic, and Enterprise Java Beans does that better than servlets and Java Server Pages. So the advanced edition of WebSphere provides the EJB support that is not included in the standard edition. It costs $7,500 per CPU but it does give you a lot more capability in terms of removing the programmer from the idiosyncrasies of the plumbing, per se, from a Web application server point of view.
| "When Sun’s chief executive Scott McNealy talks about it, he came out with Java as a ‘Write Once, Run Everywhere’ solution. Well, I’m a little more cynical—I think it’s ‘Write Once, Test Everywhere.'" |
MRS: Generally speaking, how would you characterize IBM’s overall Java strategy?JQ: The easiest way to think of it is that in some cases, people will want to separate the back-end logic from the front-end user interface. And in some cases, all they’ll care about is being network-enabled, and being graphical, and they want to keep their back end the way that it is. Now they can use a tool, as I mentioned like Jacada or JWalk to do that, or they can basically write Java for the client and then use the AS/400 toolbox to call an RPG or a COBOL program. So that’s where people say, “I need to build it and develop it to extend the existing application to the Web, but I don’t want to have to redesign the whole thing because it works fine.” So in a lot of cases, you’ll just be using the toolbox to call a program and so you get the good user interface and you get the browser enablement, but the back-end stays just like it was before.
In some cases, people will want to build a new business-to-business, or business-to-consumer application that doesn’t exist today—you’re not going to use RPG to do that. So for new applications like that, Java is more appropriate.
MRS: So, does that mean that eventually Java is going to be the right tool to use to build back-end applications?
JQ: Absolutely. Performance has been dramatically improved and with our optimization, we don’t think that there’s much difference between RPG performance and Java performance. In fact, Intentia says that it’s almost equal today, with their new version that was written in Java.
The best way to think of it is if you’re currently an AS/400 programmer, or a customer and you’ve got 100 percent of your applications in RPG, the migration is going to take years to move to Java. And in some cases, it may not even make sense to take an application like a general ledger application and do it in Java. For other people, that are new to the AS/400, they won’t have much interest in RPG, and will be inclined to simply write the applications in the new technology, whether that means Domino or Java or XML.
LH: Having been a customer that had to write code for a living, I think it’s good that we continue down the path of, “We’re not going to force you to throw everything out and go to something new. We’re there for you as you migrate those applications into the new technologies.” When you do that migration is really dictated by what the customer’s business needs are.
MRS: So, what’s ahead? What can users expect to see in the coming year with respect to Java on the AS/400?
JQ: Basically, we’ll be continuing with various releases to optimize the Java environment so that it has more functions and better performance.
The other thing you’ll see is we’re investing in the area of XML more and you’ll see more support for XML. One of the important capabilities that XML provides is data portability. Java provides application portability—XML is an excellent environment to support data portability. So if somebody has some data in a relational database, some data in a flat-file system, and some in an embedded database, XML gives them the ability to present all different forms of data into one user interface. The really exciting part of XML is that that’s how the AS/400 is going to be communicating to pervasive computing devices—that’s how we’re going to be talking to Palm Pilots, cellular phones, Personal Digital Assistants, rings and so on. And it won’t be long before we’ll begin to see this technology becoming available. In fact, we expect to see this all happening in the second half of this year.
LH: There will also be derivatives of XML—different versions of XML that are discipline-specific—for instance in the area of trading partner agreements, which will become extremely important in the B2B space.
MRS: Any plans for a dedicated Java server?
JQ: No. But that’s a good question. There are no current plans for a dedicated Java server. What we want to have is a server that is able to handle all or most of the emerging workloads better than it can today. So, if you’re looking at which way we’re going, we don’t want to have a dedicated Java server, or a dedicated WebSphere server, or a dedicated XML server. We want a single server that can support all different types of emerging workloads such as the ones I mentioned—including Domino, because Domino runs on the dedicated server today as well as the standard AS/400s.
LH: If you look at the practical application of some of this stuff, in the area of e-commerce for example, it quickly starts blurring into the other areas like the business intelligence space, or the CRM space, and you don’t want to become so much of a pillar that you’re forcing server farms if that’s not what a customer wants to do. If they want to take all of these different technologies that overlap so much to solve a particular business need, you don’t want to force them to break out of each one. So we’re trying to take a step back and look at it from the standpoint of how a customer practically implements this in their business and determine the optimal configuration for that. That’s where all these other emerging workloads come into play as well.
JQ: The emerging workloads are typically very CPU intensive, so they work best with fast microprocessors. The traditional workloads—the 5250 RPG environments—work best with interactive workloads, so what we have with our current product line is the ability to optimize the processor based on whether you’re dealing with an emerging workload machine, or an interactive workload machine. A year ago, we had server models and system models and we think that confused the marketplace. So what we now have is the option to have say 0 percent interactive, with everything optimized to run Domino, and WebSphere and Java; or say 50 percent of my applications are RPG and 50 percent are these emerging workloads—I now have the option of buying as much or as little interactive capability as I need to model what my current workload looks like.
Our objective is to offer flexibility. What we don’t want to do is to require a separate machine to accomplish these things.
MRS: Any other thoughts on this subject that you’d like to share with our readers?
JQ: The AS/400 continues to reinvent itself—we have a unique architecture that allows us to come up with these new technologies and people don’t have to necessarily rewrite their applications. So we’re going to try to provide the best of both worlds. We want to support our current customers with their existing applications, which could be RPG or COBOL, as well as attract new vendors, new application developers and new solutions with these emerging technologies. And we think we can do it in a superior fashion with the AS/400 because we provide things that are not necessarily available with NT-based machines, like the scalability, the robustness of the environment, and the security of the AS/400. So, while it may sound like a bit of a cliché, we think we can provide the best of the old along with the best of the new.
Related Editorial:
Java: Transforming the AS/400?Serving Up Java PagesRelated Information:
IBM DeveloperWorks (new window)