Sifting Through the Java Quagmire
September 8, 2004 Kevin Vandever
Four Hundred Guru has published a range of articles on the Java language. As much information as we’ve provided, however, I still don’t think we’ve solved the Java mystery for many iSeries professionals. I still hear the how, when, and why questions from many of you out there. So I’d like to take a step back and provide some high level answers to these questions, so you can sift your way through the quagmire to what you really need to understand.
The reason for so many questions from the iSeries community is not that we are incapable of learning Java and the Java environment. On the contrary, I’ve seen a number of RPG programmers learn Java and become productive Java developers. In most cases, however, those successful in making the transition had to make the complete jump to Java. No half-steppin’ here. To truly learn the language and, more important, the environment, one must make the leap. And that is where the problem lies. I think many of us RPG and iSeries folks are trying to take it all in. We are trying to learn it all so that we can tackle any problem. Well, that just may not be a practical approach. Of course, it’s always good to know what technology is out there and how it might benefit you and your shop, but with Java there is so much to learn that those of us who try to maintain our productivity on the RPG side while also attempting to be completely productive on the Java side might be biting off more than we can chew.
I don’t mean to say that to understand and be proficient at one technology disqualifies you from understanding and being proficient at another. But there is so much to choose from when deciding to learn Java. Where does one start? Beyond the basics of the Java language and environment, the answer to that question depends on your interests and what you’re trying to accomplish at your shop. The good news is that we don’t have to choose between Java and RPG. We can combine the two technologies to solve our shops’ business challenges. However, we may also decide to completely avoid Java or to completely rewrite our applications in Java. The choice is yours, and it is a daunting one. All this said, if you can understand from a high level some of the choices out there, and when you might use each one, then you might be able to make more informed decisions on the direction of your application development projects. Let’s take a look at some of these choices.
INTEGRATED LANGUAGE ENVIRONMENT
“What the heck does this have to do with Java?” you might ask. “Not much,” is the appropriate answer. However, understanding ILE and RPG IV can open up many opportunities for you and your application development projects. For one, the basic building blocks of ILE are closely related to Java and the object-oriented (OO) environment. Not exactly the same, but closely related. If you are able to learn ILE and the new capabilities of RPG IV, you are that much closer toward understanding OO. Another reason to learn ILE is that it is the only means of using two of the Java/RPG interoperability techniques discussed below. However, the most important reason for learning and implementing ILE might be that by doing so you may be able to extend the life of your iSeries applications and the iSeries itself. The ILE provides tools that allow you to open your applications to other languages on the iSeries, as well as those outside the iSeries. It also allows you to completely overhaul your applications without learning another language. How many other languages can say that? So, whether you plan to open up your applications or you simply want to decrease the maintenance effort and make your applications more efficient, learning ILE and RPG IV is the way to go.
COMMON GATEWAY INTERFACE
Technically, CGI doesn’t qualify as a Java topic, either, because there is actually no Java used. But I lump it in because it is a technology used to extend the iSeries beyond green screens and out to the World Wide Web. The ingredients in a CGI application include RPG, HTML, the HTTP server, and potentially some Java script, which is not the same as Java, but that’s a topic for another article. CGI is used when you want to write your business applications in RPG–and, I suppose, COBOL, although I’ve never done it–or you want to leverage already-written iSeries applications. The key requirement for implementing CGI is that you want the user interface to be a Web page, which is where HTML comes in. Instead of using DDS as your user interface, you embed HTML inside your RPG code and display the output on a browser. I’ll mention quickly that the HTML doesn’t have to, and should not be, actually embedded in the code. It can be stored in a file or data structure and accessed by the application when needed. Anyway, once you’ve designed and coded your HTML, you use RPG as you would when writing any other interactive program, except that, instead of READ and WRITE statements, you use a few APIs (application program interfaces) to process the HTML. So, to recap, you have RPG as your business logic, HTML as your user interface, and APIs as the mechanisms to process the HTML. The next ingredient is the HTTP server. The HTTP server comes standard, and free, on your iSeries and allows you to accept requests from and write responses to the browser. There is much more to the HTTP server and HTML, and I invite you to check out the articles we’ve written on the subjects. Using these three primary ingredients, you are able to write iSeries applications that extend beyond the iSeries while minimizing the learning curve by not causing your application developers to learn a new language.
JAVA NATIVE INTERFACE
This technology is not new to Java, but using it with ILE native methods is. A native method to Java is a method, in OO speak, that is not written in Java but can be natively called from Java. This is one of those techniques I mentioned above where you’ll require an understanding of ILE in order to implement it. What JNI allows you to do is to make calls to iSeries ILE applications from Java. The nice thing from a Java standpoint is that nothing new is added. Java has always been able to call native methods; however, in the past those native methods were usually written in another OO-based language, such as C or C++. As of V5R1, you can prototype an ILE subprocedure and create an ILE service program that can be called from Java. Cool, eh? This technique is used when you have Java applications that need to access non-Java iSeries ILE applications. The major road block here is that the Java and ILE applications have to reside on the same iSeries server. There isn’t a way, yet, to call remote native ILE methods from Java, so for now the Java and ILE have to be on the same box.
AS/400 TOOLBOX FOR JAVA
The toolbox may be the oldest, most widely used, and favorite way to access iSeries resources from Java. This is because the toolbox is packed with so much stuff. It is also because the Java applications don’t have to reside on the iSeries. There have been many articles written by us on toolbox content, so I won’t go into too much detail here, but by adding the Java toolbox to your Java application development environment, you’ve once again extended your iSeries applications and resources beyond the walls of the iSeries. The reason why I use the word “resources” is that the toolbox allows you to do more than just call iSeries programs. Of course, it does allow you to call both ILE and non-ILE applications, but it also allows you to access many other iSeries objects, such as database files, data queues, and data areas, to name a few. I can’t do the toolbox justice in the space allotted in this article, so I invite you to investigate for yourself what you can do with the toolbox. Just know that including the iSeries toolbox for Java in your Java development environment essentially tears down the walls of the iSeries and opens your enterprise applications to the rest of your development shop–without sacrificing security along the way.
PROTOTYPING AND CALLING JAVA METHODS FROM RPG
If you have Java applications and need to access them from your iSeries applications, there are a couple of ways to accomplish the task. For one, you can use the run Java command (RUNJVA) in a batch environment to run a Java application. Or you can run Java applications from the QShell environment, either from a QShell command line or via a QShell script. But what if you want to call Java applications directly from your RPG applications? What if you not only want to call Java applications but also want to retrieve data from those applications? There is a very cool way to do just that. You can now prototype Java methods, just as you do ILE subprocedures, and call them directly from your RPG. Once you create the prototype, which is a little different from creating a prototype for a subprocedure, the call to the Java method looks like a call to any other ILE subprocedure. It’s kind of the opposite of the JNI technique mentioned earlier. To use this technique you need to understand both ILE and the new features (as of V5R1) of RPG IV. Using this technique, you can call core Java APIs–those included with Java runtime environment–as well as any home-grown Java application. Just as with JNI, the Java and RPG applications must reside on the same server. You cannot call remote Java methods–yet. However, I have used this technique to get at Java applications outside my iSeries by first calling a Java processing program on the iSeries and allowing that program to access the Java on the outside. Be creative, and you’ll be amazed at what you can do.
PURE JAVA
This is the most drastic technique. It calls for rewriting your iSeries applications in Java. To use this technique, you’ll need more than a firm grasp on the Java language and environment; you must completely change your mindset on how to develop and implement applications. You should understand the development tools associated with Java applications, the difference between a Web server and an application server and how to configure each, and you need to rethink how you build and implement applications. Rewriting your enterprise applications in Java is a huge step, and, in my experience, is usually one taken by a team of well-seasoned Java developers who have never heard of the iSeries or RPG but need to work with those who have, in order to complete a successful rewrite. And this technique may not constitute a rewrite at all. It may be the case that a new application, such as an e-commerce Web site, is being written in Java and that this new application needs to access the iSeries data and business logic. In such a case, you may use a combination of the techniques described above, such as the iSeries toolbox for Java and possibly JNI, to make this all work. Learning pure Java takes time, and there are plenty of resources out there for you to tap into, including many of our own articles.
THE CHOICE IS YOURS
Now that you have an understanding of what high level technology choices are out there and how they tie in or relate to Java, you can take some time to see what technique or combination of techniques best fit your shop and investigate further. Before digging too far, don’t forget to perform a search right here on the Guild Companies site, as we’ve covered all of these topics at some point in the past two and a half years. Some topics in more detail than others, but we’ve covered them all. I hope that by organizing these techniques as I did, you are able to see how each might fit in your shop and better focus on which to learn first.
