In the i community, EGL's biggest strength may be simply that EGL does i better than anyone, and that makes it the integration technology of choice.

Over the past couple of years, I've talked quite a bit about Enterprise Generation Language (EGL) and its capabilities as a business development language. I started out as a skeptic, but I gradually came to admire the philosophy of the tool: let the business application developer focus on the business, not the technical minutiae. In today's article, I'll explain how that philosophy allows you to leverage your most important and valuable asset: your business developers.

A Quick Review of EGL

Let me first give a 30,000 foot view of EGL. And even at that level, I need to narrow the focus a little bit to specifically hone in on how EGL works with the IBM i community, because EGL is a huge tool. Since at its core EGL is built on a base of Java, EGL targets just about every platform on the planet, and that's just the server-side code. The other side, the rich client tooling, is built on JavaScript, so it runs in almost every browser. This combination makes EGL one of the most universal languages available today.

But that's not really the strength of the tool, especially within the context of this article. Other languages have a similar breadth of implementation; Java can run nearly anywhere and, with the addition of the Google Web Toolkit, you can even write Java code that is converted to JavaScript that can then run in your browser. Microsoft's .NET tooling can work on both the client and the server, albeit within the confines of the Microsoft environment. And both Java and .NET provide support for thick client programming, which is an area that EGL doesn't really concentrate on. So while EGL is indeed a broadly targeted tool, that alone doesn't make it unique.

Instead, where EGL really stands out is in its integration with other technologies. Java integrates very well with other Java and to a minor degree can work and play reasonably well with other technologies, at least at a very low level. Unfortunately, as the Java application development stack becomes more complex, reaching on up to things like portals, Java is less an integration environment than a predefined architecture. And of course the Microsoft strategy is almost the antithesis of technological cooperation. It's very much the .NET way or the highway.

EGL is different. EGL takes a page from its underlying foundation, Eclipse, in that it is first and foremost a framework meant to be extended. It is this extensibility and the tooling that enables it that gives EGL a substantial advantage over every other technology. In fact, the parallels to Eclipse are so strong that it makes sense to take a look at that now-venerable package. You may remember that when Eclipse first came on the scene, there were a number of competing tool sets, including the nascent Visual Studio suite, NetBeans, and even Eclipse's direct predecessor, VisualAge for Java. Most grew organically from preceding tools, which gave them an advantage in features and familiarity. The new Eclipse platform was a completely new environment, although fortunately the folks that built it were some really bright folks with no small knowledge of the IDE concept, having already created the VisualAge products.

But how in the world would this small, upstart tool actually compete with the established players? Why would someone want to throw away years of experience with another tool to use this little-known newcomer? Perhaps because it allows people to enhance the package themselves and build upon their own knowledge to extend the Integrated Development Environment (IDE) and make it ever more powerful. To be honest, I don't think even the original developers had any idea that this novel idea would take off and transform the IDE industry, but that's exactly what it did. Eclipse gave developers the ability to work "outside the box" and to integrate their own abilities with the tool rather than be limited by only what the tool provided.

One point needs to be made here about code generation. In a noble effort to help programmers be more productive, many IDEs provided pre-fabricated pieces of code via features with names like "snippets" or "wizards", or even worse as libraries included in the product's runtime, usually without source. These snippets made it very easy for even novice programmers to cobble together relatively complex applications in record time. However, the development time was rarely eliminated, it was simply postponed. It is a maxim among developers that the hard part of building an application is not the initial programming but the subsequent modification and debugging, and the programmers who relied heavily on tool-generated code without understanding the underlying architecture often found themselves in charge of an application without the skill required to maintain it. It was this gap between what could be built and what could be maintained that ultimately led to the demise of the code generator as a tool in many development shops.

Applying the Lessons of Eclipse to Application Development

Fast forward to the middle of this decade. The World Wide Web was fast becoming an integral focal point of business application development, and in turn the browser was quickly becoming the default interface to that new world. Advances in user interface design were fast and furious, and it seemed that a whole new generation of applications was just around the corner. However, that corner seemed to stay just out of reach, and the most common complaint from the development community was that the technology was just too complex. Just to create a "simple" application, one needed to have substantial if not expert skills in a multitude of technologies. Even in a homogeneous environment like Java, you still needed to know at a minimum Java, HTML, XML, and JavaScript--and at more than just an introductory level. This sort of knowledge made subfiles look relatively easy in comparison. And this was just the user interface; add into that advanced database knowledge, including SQL and its Java-enabling technology, JDBC, and finally that gave you enough knowledge to create relatively rudimentary applications.

This is the chaotic environment that business application developers found themselves in. RPG programmers in particular were hard-pressed to become conversant in all of this new technology; they had enough on their plates just trying to learn ILE and free-format RPG, all the while trying to address a backlog of user demands. Throw in the requirement of learning not one but multiple new programming languages and the task become overwhelming.

Some of the new tools made matters even worse. Through mechanisms such as coding by convention or more extensive wizards, specialty environments like Ruby on Rails or the venerable Visual Studio tools allowed even relatively inexperienced programmers (and in some cases, even end users!) to quickly knock out visually exciting applications in almost no time. PC-based with nimble interfaces, these "application generators" quickly became popular, especially in IBM i shops, where they offered a respite to the change-deluged developers. But just like code generators of yore, most application generators usually created code that was rigid in nature and inflexible in the face of changing requirements and technologies. Many a company found out about those limitations only after they were so far down the development path that the pain of switching to a new tool was greater than the pain of staying with the one they currently had.

EGL addressed this task a little differently. Rather than attempt to provide pre-designed applications in a sort of "fill in the blanks" approach, EGL instead focuses on eliminating the more tedious and error-prone aspects of today's architectures, using a simple, easy-to-understand syntax. While it does have some built-in application generation capabilities, I frankly never use them. But a large part of that decision is because I prefer to use RPG for all my business logic, and for that it's much easier to simply roll up my EGL sleeves and write the few lines of interface code required to call my existing business logic.

The beauty of EGL is that it understands traditional procedural programmers like me. With a few clicks, I can quickly identify an RPG program to call on a host. I can pass any sort of data to it, including most importantly "records," which in the RPG world are simply externally described data structures. EGL takes care of all of the data transformations, and I can focus on simply writing the call, a call that looks as simple as this:

     CALL ORDSVR(dsControl, dsData);

What you see is a simple call to a program with two records, each of which shows up in the RPG program as a data structure. What you don't see is all the technical machinations required in other languages to create a connection and convert the data and call the program and convert the returned data and so on. More importantly, though, is that once I've written that call, I can then wrapper it inside a function. In that function, I might call the program in a loop and build an array of records. EGL makes that very easy because I can define an array of any record, and the array will extend itself as I need it. Not only that, but business programmers will appreciate the fact that the first element in an array is index 1, not index 0! Any language that has a zero-th element and no primitive for fixed precision decimal numbers is not a business language. But I digress.

The important thing is that the idea of a record is fundamental to EGL. I'm not talking about an "object," although records do have some object-like characteristics. What I'm talking about here is the fact that an aggregation of data can be fundamentally created, changed, and passed from place to place without any low-level technical theatrics. This is what makes EGL a business language and what allows it to leverage your existing developers' skills. As long as you can make your business logic programs callable, you don't have to write a single line of business logic in anything other than the RPG (or COBOL) your current developers are comfortable with. They don't have to learn Java or PHP or any other language, and you don't have to rewrite (and re-test and re-debug) your applications.

So Why Is This So Important?

Ah finally, getting around to the point! And an important point it is. This record-centric nature of EGL is what makes it so easy to create not just pretty applications, but applications that are both pretty and functional as well. Take a look at Figure 1.

Figure 1: This thin client application uses an RPG server and took about ten minutes to create. (Click image to enlarge.)

First, I wrote the function that wrapped the call to the RPG program. The function was a dozen or so lines that simply retrieved the order header and then all of the lines and put them into an array. EGL allowed me to create a record that included both the header and the array of lines, and it was this complex record that the function returned to the user interface. It was then literally the work of 10 minutes to drag and drop the components of that complex structure onto the WYSIWYG editor to make the screen above.

Had I decided to stay with the thin client, I would then have turned the page over to someone with good Web skills to turn it into a pretty page using a Cascading Style Sheet. Hopefully, the corporation has a standard one, and the designer can use that.

That, however, isn't the half of it. I can also create a rich client using the exact same EGL function. The user interface design is a bit more complex, but the logic is still written in RPG! The underlying plumbing is pretty intense. The rich client is written in JavaScript and uses AJAX calls to invoke the RPG program on the host using an intermediate Web service. The beauty, though, is that you don't need to know any of that. A click here, a call there, and you're done. The EGL record type and indeed all the same EGL syntax is just as valid in the rich client as it is in the thin client and of course the RPG code is exactly the same. Talk about leveraging your assets!

Figure 2: This rich client uses the same business logic as the thin client.

The takeaway from this is simple: no matter what your user interface requirements, you can use EGL to develop them, but you don't have to rewrite a single line of business logic. If your logic isn't callable, you'll need to make it callable, but you'd have to do that no matter what architecture or technology you chose. But with EGL, once you've got callable business logic, the sky is the limit as to what you can do with it.

A little self-serving plug: this entire architecture is laid out in detail in my new book coming out in October. Look for it at the MC Press Store!