What's new with EGL, and what's coming?

And I thought my last article started with some bad news. I'll tell you all the good news about EGL, including the amazing new mashup support, but first the bad news.

The i Loses a Hero

Unless you've been living on Mars, you already know that the System i community lost a true hero recently. Al Barsa Jr. was one of the staunchest allies the platform ever had. He was a true friend to IBM in that he wasn't afraid to tell them the truth no matter how hard it hurt, and he wasn't shy about it. I attended COMMON pretty regularly back in the day, and two of my sharpest memories include wandering the computer room with Chuck Myaard and listening to Al hold forth on the state of the platform.

Those two guys epitomized COMMON for me: Chuck working in the back rooms, making sure everything hummed along, happiest if he was never seen (if you read this, Chuck, I love ya), and Al just as happily standing center stage with a microphone in front of him telling IBM the things many of us thought but were a little too intimidated to say.

Well, Al passed away right after COMMON ended, and the world is a little less for it. It briefly entered my mind to say it was "fitting" that he should spend his last moments at COMMON, but of course, there is no fitting way to leave this life, except perhaps at an advanced age surrounded by friends and family. I'm sure in hindsight we all wish Al had stayed home instead of going to COMMON this year, but in the end, Al did what Al always did: He thought of the community above himself. He will be missed.

Picture: Al doing what he did best, telling IBM what they need to do.

Al had many more sides than the one I knew best at COMMON, and I'll leave it to others who knew him better to tell you about them. You can visit http://www.mr400.com/ for messages from friends and co-workers, as well as look the Midrange.com archives. One post from Greg Wenzloff of Beck Manufacturing summed it up for me: "We now have a new machine still in the box and I have Al's 199 page handout right on my desk. I am ready because Al taught me what I need to know. He will be missed."

The COMMON Education Foundation (CEF) has announced the creation of the Al Barsa Memorial Scholarship, an honor that could hardly be more fitting. It shows that COMMON understands the enormous benefit Al's presence gave and the positive effect he had on so many people. And while the CEF is technically a separate organization from COMMON, in this case this is clearly a heartfelt message from the entire organization, and it's a very classy gesture.

On to the Future, and That Future Is EGL

OK, it's time to up the ante on EGL. Rational Developer for i (RDi) and Rational Developer for i, Service-Oriented Architecture (RDi-SOA) are now generally available, as is an alphaWorks preview of the new RUI/RWS tools. I hesitate to use the acronyms for this new facet of EGL; its original name was Rich User Interface (RUI), but for one reason or another, it's now Rich Web Services (RWS). However, most of the developers I talk to still call it RUI, so I get confused. The official name though is RWS, at least on its alphaWorks site. You'll find a lot of very cool incubator technologies at alphaWorks ; I'll be telling you a lot more about them in coming articles.

Other Options

OK, so why EGL? Well, I've been reading a bunch of stuff in the mailing lists recently about trying to build Web applications with things like Net.Data and PHP. The primary reason I hear for using these tools is that they're easy to use. The PHP advocates also point to the popularity of the language, and that's certainly a plus, although I think there may be a certain chicken-and-egg issue occurring there.

PHP is more popular at least in part because it's easier to learn and in part because it's easier to find a host. Not only that, there is a large selection of prepackaged Web application software available, much of it free. And if we agree that most Web sites are not maintained by professional programmers, then it's clear that PHP has a huge leverage over environments such as Java and .NET (yes, I'm using the dot-N word because, love or hate Microsoft, .NET is a fully featured programming environment).

If you want to put together a Web application with as little programming effort as possible that can be hosted as cheaply as possible, especially if you're willing to host on somebody else's hardware, then it's awfully hard to beat a LAMP (Linux, Apache, MySQL, and PHP) stack. Even if you want to host it in-house relatively cheaply, with the rise of virtualization you can download entire preconfigured systems and run them in a virtual machine. That way, even if you attempt something outside your envelope of knowledge and break the system, you can revert to a backed up working version in seconds.

However, dear reader, you (probably, if you are reading this publication) and I (supposedly, since I'm writing for it) are professional programmers, and we should be looking at fully featured programming environments, and of those, there are really only two: Java EE and .NET. I'm not going to address RPG-CGI; if you choose that route, this is a completely moot discussion, because you won't be using PHP or indeed any other language. As I've said in the past, if you are a pure RPG shop and simply can't invest the time to learn any other language, RPG-CGI is a perfectly acceptable alternative.

In case you've never used it, Net.Data (not to be confused with .NET) is IBM's scripting language. It is very similar to other scripting languages: You write interpreted scripts that can perform various functions and then invoke a method that outputs HTML, using markers to include variables from the script. The beauty of Net.Data is that it has intrinsic support for SQL, REXX, and compiled programs. It's a great option if your primary concern is not prepackaged software but instead ease of use and a quick edit/run development cycle.

So Why Use EGL?

But if you do intend to use a non-RPG language, then you need to choose your operating environment. I've talked about PHP, and I don't want to get into a big ruckus about why I don't consider it a full-fledged programming environment. If you agree with me, then you are down to two options: Java EE and .NET. Since Java runs natively on the IBM i, then it's a clear winner for me. In fact, IBM's focus is still squarely on Java, from the Rational group's Eclipse-based tooling to the WebSphere Application Server to IBM's Java Toolbox. It's clear that if you want to stay close to IBM's core direction, then Java is a good place to bet.

However, the immediate complaint from people is the learning curve for Java. The effort involved is a real concern for many programmers. We just don't have the time to learn a bunch of new technologies, and thus the allure of scripting languages that can drastically reduce our initial learning curve. With Java, the perception is that it takes a long time to learn how to create Web applications. This perception is a little faulty; the amount of Java needed for Web applications is very small. I've taught people to create working Web applications with RPG business logic in a single session. JavaServer Pages (JSPs) are just as easy as Net.Data or PHP scripts to write. It's the plumbing (connecting the variables on the JSP to an ILE program) that requires a bit of work. That's because Java is a strict OO language, and it requires you to build the entire application framework from the ground up.

In my conversations with Jon Paris, we've often discussed that what is needed for RPG programmers to be able to easily embrace the Java EE world is a sort of "procedural Java": a way to write Java EE code without having to learn all the mechanics of object-oriented programming. And that, good reader, is exactly what EGL is.

By providing a simple, concise procedural language that is then translated to Java, EGL gives the programmer the best of both worlds. EGL allows you to concentrate on the business aspects (what fields are displayed to the user, what table to read to get a piece of information, what program to call to validate a transaction) without having to worry about the syntactical intricacies of the language. If you're unsure as to how that syntax makes programming easier, I'd point you to some of my other articles on EGL. But as an example, here's the total code required to show an array of records on a screen calling an RPG program to return the data.

Figure 2A: This is the EGL code required to call an RPG program to load an array.

Figure 2B: This is the corresponding RPG program in its entirety.

The two code snippets above are all that is required to display an array of records. No other code is required to build the Web page. The Web page itself is designed using a WYSIWYG editor; Figure 3 shows an example of that editor. You might remark that it would be easier to just use a simple SQL statement, and in fact EGL would allow that. In that case, the code in Figure 2A would be reduced to a single "get" operation, and there would be no RPG program. But this example shows that you can easily write complex business logic in RPG to provide the data to your end user; no matter how sophisticated the RPG program, the amount of EGL code required would remain the same.

EGL as a Productivity Tool

But just being another programming option, no matter how good, isn't enough these days. Programmers need tools that allow them to leverage new technologies quickly without having to reinvent the wheel. The libraries in languages like Perl and PHP and Python are good examples. Hans Boldt used to always point out that you can create an HTTP server in Python with one line of code. I may be exaggerating; it might have been three lines of code, but no matter: The point is still that a good library makes your life easier. Another big deal these days is "frameworks" in which much of the programming for standard tasks such as database maintenance are provided by the language.

EGL provides both frameworks and libraries. The tight integration with JavaServer Faces (JSF) provides an almost coding-free drag-and-drop design capability in the Rational Business Developer (RBD), which is also an integrated component of the new RDi-SOA tool. You simply define variables (which can be simple fields or complex records) and then drag and drop them onto Web pages using a WYSIWYG editor; the plumbing is then built for you. An EGL "page handler" is built with predefined locations for inserting code to load the page. You can then write a function to handle user input and, with the same drag and drop, attach that function to a button on your page. The function can use a single instruction call to pass user data to an ILE program for validation and processing.

Figure 3: The JSF page editor provides powerful drag-and-drop design without hand-coding.

EGL also provides a powerful and growing set of libraries to perform functions ranging from controlling standard HTTP sessions to converting between EGL variables and external formats such as Simple Object Access Protocol (SOAP) and JavaScript Object Notation (JSON). That means that as your technological needs evolve, you will be able to quickly design applications using industry-standard techniques without having to leave the framework of the language.

What's Coming in EGL

More important, possibly, than all the low-level integration features of the EGL language are the high-level capabilities that come only from a 4GL. EGL allows you to create a complete maintenance application (also called CRUD for Create, Read, Update, and Delete) just by walking through a wizard. EGL has built-in support in the WYSIWYG to add AJAX support to your application without having to write a single line of JavaScript.

And with the new Rich Web Services capabilities, EGL adds the capabilities of interfacing with external services without writing a line of Java or JavaScript. The developers continue to encapsulate standard interfaces within library functions that make it easy to integrate the latest technologies into your programs.

Figure 4: This is a slide from my upcoming presentation at RSDC, showing various Rich Web features.

Figure 4 is a perfect example. This slide is part of a session I'm co-presenting with George Farr at the Rational Software Developer's Conference in June. To create this slide, I used several embedded functions within the new EGL Rich Web Support to create graphical widgets using standard business data. Many of these come from live calls to some of the Google Web services. The EGL team continues to add these features such that it's a matter of a single line of code to access these powerful features.

Figure 5: Accessing a map requires only a call to the showAddresses library function.

This is an example of the encapsulation you will see as the tool matures. I create an object of type GoogleMap and then pass it variables, variables that I could have read straight from a database table or received from a program call. The EGL team shields me from the intricacies of the new technologies, which in the end is one of the reasons that languages such as PHP and Ruby get so much traction. It's not that programmers can't learn the syntax; it's that they want to be able to get their jobs done quickly, and the more grunt work that is encapsulated, the better. Scripting libraries provide a lot of that because they are a level of abstraction, something that has been missing from the Java EE architecture.

With EGL, I think we're just beginning to see the extent of what a well-written framework built on the solid architectural underpinning of Java EE can provide.