With SEU having been sunsetted, you know you have to move to a Rational tool, but which one? This article provides the answers.
IBM has an undeniable history of creating some of the best software available for business application developers, but it hasn't always been easy for us to get it. The maturation of the Eclipse product as a software delivery platform and the corresponding growth of IBM's Installation Manager (IM) have been remarkable, but the growing pains were at times challenging and many of us green-screen types managed to get a bit lost in the shuffle. Most of us come from a background where at most we needed to make sure we included the development tools on our hardware configuration, and the varied and sometimes conflicting array of options in Rational can be overwhelming. This article will explain the state of the product line today and help you chart your way through the sea of choices that confront you with version 8 of the Rational tooling.
So What Is This Thing Called Rational?
Perhaps the easiest way to think of the Rational product line is as an assemble-to-order development tool. The various Rational products are components that can be combined into a single workbench, according to your needs. It's more than an Integrated Development Environment (IDE), because the workbench can be assembled to meet various development roles. Note that this assembly process is just the gross configuration; even after you've created your basic workbench, you can further refine your role by enabling or disabling finer-grained features of the components you have installed. Rational refers to these features as capabilities, and you control them through the infamous Preferences dialog as shown in Figure 1.
Figure 1: This is the Capabilities page of the Preferences dialog. (Click image to enlarge.)
But the focus of this article is the broader configuration of the workbench itself: assembling the various Rational products needed to create a workbench that fulfills the various development roles that make sense in a typical IBM i shop. I'll also explain how these different configurations relate to the prepackaged tools we're familiar with as IBM i developers. I'll begin at the beginning, by defining the various products and their purpose. The three products most likely to be used by IBM i developers include Rational Developer for Power Systems (RDP), Rational Business Developer (RBD), and Rational Application Developer (RAD). Each of these has its own target development task.
Let me address the two non-i specific components first. RBD is the tooling for IBM's EGL language. It includes tooling for both the thin-client EGL applications based on the industry standard JavaServer Faces (JSF) technology and also the newer and very powerful Rich UI tooling, which generates JavaScript-based Rich Internet Applications (RIA). As delivered today, the Rich UI can create applications using either the popular Dojo toolkit or IBM's own widget library, which has been enhanced significantly in version 8. Basically, though, EGL is a 4GL for Web applications with a unique concentration on business application development, and RBD provides the tooling for that language. RAD, on the other hand, is the pure Java EE tooling targeted toward traditional Java developers. It contains all the JSF tooling (much of which is shared with RBD) but is more focused on writing and developing Java EE applications using the standard Java tools, with hooks for some of the more advanced Java EE technologies, such as Java Persistence (JPA), and the service architectures, such as Java API for Web Services (JAX-WS) and Java API for RESTful Services (JAX-RS). You can think of them as two roads to the same destination: one for people who want to get in the car and drive, and the other for the driver who likes to tinker under the hood.
The third component is RDP. RDP can be a little confusing all by itself because it has its own optional features. However, the majority of us won't worry about most of those options, since they pertain to AIX and Linux development. It's good to know that they exist, especially if your shop develops in those environments, but for the purposes of this article, we'll just stick with RDP configured with the IBM i-centric feature, the RPG and COBOL Development Tools for i. I'll use the term RDPi for this configuration.
How Do They Relate to the Tools I Know About?
To answer that, I have to start with the tools. Our first GUI tool was the WebSphere Development Studio Client (WDSC), which went through many iterations until it finally ended up at WDSC 7 as a tool that provided everything you needed to development not only green-screen applications but Java EE applications as well. Near the end of its life, it even got an extra feature for developing EGL applications, so really WDSC was able to do a decent job of what RBD, RAD ,and RDP deliver combined. However, most folks who used WDSC either used it as a GUI replacement for PDM and SEU or as a full multi-tier Java EE development environment. The former task is entirely replaced by RDPi, while the latter would require a combination of RDPi and RAD. So if you used WDSC as just a green-screen development tool, install RDPi. If you did multi-tier development, install both RDPi and RAD.
So does that mean you need to switch between RDPi and RAD to get the same work experience as the old WDSC multi-tiered development environment? No! That's the beauty of the Rational product delivery mechanism. You can install both RAD and RDPi into the same workbench (or "package group" in IBM terminology). You can do this during the initial installation, or alternatively you can install one component into an existing installation of the other component. This mix-and-match capability is one of the key features to the Rational strategy, and I think it will continue to serve IBM well in the future. Already, with just what I've explained, it's clear that you can have some developers using just the green-screen development tools and some doing full multi-tier Java EE work, both using the same basic tooling. As your developers extend their abilities, you can extend their tools with a simple upgrade.
Getting back to the comparisons, what if you are using Rational Developer for the IBM i (RDi) today? Well, RDi was WDSC stripped down to just its green-screen essentials, so the clear replacement for that toolset is RDPi. It's really a one-for-one substitution.
The other IBM i GUI tool being using today is RDi-SOA. This was IBM's bundled product to allow IBM i developers to build multi-tiered Web applications using traditional ILE server languages for back-end business logic in combination with the new EGL tooling. People using that particular tool set would have to replace it with a combination of RDPi and RBD. Like the RDPi/RAD combination above, the RDPi/RBD assembly can be created in either a single installation step or in a two-step installation where one component is installed into another.
What About Licensing?
That is an entirely different discussion and one which I hope I can address in a later article. The problem is that it's not always clear what exactly to order for fully licensed versions of these tools. For example, you can order RDPi version 8 during your IBM i ordering process; it's licensed product ID 5733-RDG. However, you would have to go to the Rational side of the house to get RBD if you were trying to create an RDi-SOA replacement. Interestingly enough, though, IBM seems to have a bundled offering for RDPi and RAD, called Power Tools for i. Unfortunately, I don't yet have as clear a definition on the licensing as I do on the basic configuration. Stay tuned and I'll bring that to you as soon as I can. But for now you can certainly download the trial versions of the Rational V8 components and see how they work in your environment. I'll leave you with the links to the trial versions of each of the products: RAD, RBD, and RDPi.
as/400, os/400, iseries, system i, i5/os, ibm i, power systems, 6.1, 7.1, V7,
LATEST COMMENTS
MC Press Online