When you're strange,
Faces come out of the rain.
--The Doors

Enterprise Generation Language (EGL) is a strange little language. Actually I say little, but it's far from that; EGL has got untold hours of development muscle behind it, and the team that is building the language is growing. Be that as it may, EGL is still a bit strange: the weird, nerdy kid in school with the thick, black glasses. As it turns out, though, this weird kid has a very interesting ability: He builds Web pages that talk to databases without a bunch of complicated baggage. In this, EGL is kind of like Ruby on Rails. The framework is in place, and all you have to do is fill in the pieces.

But the real strength is in the IDE support for it. Technically, the support is in Rational, but it's in the part of Rational that makes it up the food chain into WDSC, so for all intents and purposes, the EGL tooling is part of the standard System i development suite. And a very nice suite it is, too. For example, you can add a field to a page. When you do that, you have an option of including a submit button (actually there are lots more options here, including adding multiple fields with different options, almost powerful enough to compete with display file DDS, but not quite).

At that point, you can write an EGL routine in the "page handler" for your JSP page and bind it to the button just by dragging and dropping it. Right-click on the JSP and run it and whammo, you just tested your JSP page. This is the first worthwhile use I've seen of the highly touted JavaServer Faces technology.

WDSC is the weird kid's big, tough brother, and he's looking to pick a fight with Visual Studio.

Let's Get Technical

I first wrote about EGL back in December of 2005. At the time, the tool was still one of those well-kept IBM secrets. EGL's development team obviously loved it, but hardly anyone else talked about it nor, I suspect, even knew it existed. Some of that can probably be attributed to the fact that EGL's primary raison d'etre was to Web-enable zSeries computers (which I suppose are called System z today); let's face it, modernizing mainframe applications doesn't exactly generate a buzz in Slashdot.

In my original article, all I was really able to do was get the onboard tutorial (by that, I mean the one shipped with WDSC) to work. The tutorial was really little more than the EGL equivalent of Hello World, so it really didn't provide us with much information. But that's actually sort of serendipitous; since then, I've managed to get my hands dirty in the world of Visual Studio, and because of that, I think I may be better prepared to tell you about what EGL has to offer.

Not Exactly Sexy

As a language, there's very little that's sexy about EGL, at least from a purely syntactical standpoint. It's a fairly straightforward event-driven procedural language, not far afield from Visual Basic. You define functions, and these functions can be invoked either directly or in response to events. For example, the function in Figure 1 is designed to be bound to a button that, when clicked, causes the application to jump to a new page.

Figure 1: This simple function forwards the user to a new page. (Click images to enlarge.)

That's it. Three words to identify the function, four words to send the application to another page. This brevity is no accident; the language has a close integration with the JSP interface. Each Faces JSP page (that is, a JSP page that uses the JavaServer Faces syntax) in an EGL project has an associated page handler, a dedicated piece of EGL code. Such a piece of code is called a "part," but not all parts are page handlers. You can also have general-purpose or business-logic parts that are held in separate collections called "packages." But these page handling parts are special: The IDE knows how to interpret their contents and makes it very easy for you to drag data from the page handler to the page itself.

The DataItem

So no, the language is not very sexy. That's partly by design, I think. It's meant to be a standard, no-nonsense procedural language. In fact, it's no coincidence that the record-definition syntax is extremely similar to COBOL. While one school of programming thought has developed ever-more-complex and sophisticated languagesthe people who designed the SOAP specification fit this descriptionanother group is dedicated to keeping things simple. This latter group encompasses the Ruby aficionados, and I think EGL fits squarely in that camp as well.

But simple does not mean weak or insubstantial. On the contrary, EGL embodies a couple of different techniques that may be a big step along the road to successful high-level application design. One such concept is the DataItem. A DataItem is basically the granddaddy of metadata. When you define a field as a DataItem, you are allowed to define all of the properties that might be needed for this field. This includes everything from UI characteristics to database attributes.

Figure 2: This is the EGL Source Assistant for defining a DataItem.

As shown in Figure 2, the IDE has a very sophisticated wizard for defining a DataItem. You might think that this perhaps flies in the face of what I said just a little while ago about the language being simple. I'm struggling with this a bit myself. However, over the years I've found that if there's any one place where you need flexibility, it's in the definition of the data that is passed from tier to tier. Defining something as two alpha characters just doesn't cut it. And EGL seems to carry this idea to its logical conclusion; the DataItem allows you to define everything. Figure 2 shows the Formatting tab, but there are a number of other tabs. For example, the Validation tab allows you to specify ranges or lists of values or even a database table to validate against.

The Data-Centric Paradigm

So in the EGL paradigm, one entire phase of your development is to properly define every data element in your application. Note that this does not just mean database elements. I can use the data item to define a UI-only control. For example, watch the following steps as I add a checkbox named ARCHIVE to my Hello World.

Figure 3: Here's the EGL for my Hello World page.

Figure 3 shows a typical setup for editing EGL. The left side is the Faces JSP page in design mode, which gives you a WYSIWYG view of the page, while the right side shows the EGL code for the page handler. The circled sections show the definition of the DataItem named ARCHIVE. It's defined as an "int" and its label is also "ARCHIVE". Finally, the DataItem is identified as a Boolean. Then, a little later in the code, I define a variable of type ARCHIVE called "arch".

Figure 4: And here's the corresponding page data for my Hello World page.

Now, when I open the Page Data view for this page, shown in Figure 4, the new field "arch" is available for processing. I can click on it...

Figure 5: The IDE presents a tool tip as a hint when dropping a control.

...and drag it to the WYSIWYG editor. I like how the IDE displays a tool tip (as in Figure 5) that tells you what will happen when you drop the field.

Figure 6: This is the Insert Control wizard.

Once you drop the field, the Insert Control wizard appears as shown in Figure 6 to allow you to modify various behaviors. You can define the field as being used for display, update, or creation; each mode changes how the field behaves and also gives you an additional option to define submit buttons for the field. I'm going to make the field input-capable but not add any buttons.

Figure 7: The result of the wizard is the field and its label being added.

Figure 7 shows the result. The editor is EGL-aware, so it gets all the information about the field from the page handler and then defines the field on the screen as a checkbox (this is the common-sense UI control for a Boolean field). This level of automatic binding between the UI and the data definitions is what makes EGL very powerful. I haven't delved deeply enough into the language to see how flexible this behavior is; I don't know whether you can, for instance, tell a Boolean field to not represent itself as a checkbox, but instead as a custom widget (perhaps some clickable text that toggles between TRUE and FALSE).

These Are the Data That Bind

You may have noticed back in Figure 2 that the DataItem definition wizard had a tab named SQL Record. This brings us to the concept of a record. A record is one of the standard ways in which EGL talks to the outside world. For instance, you can define SQL records that will connect to a relational database. You can just as easily define an MQ record type, which will talk to an MQ Series message queue. You can also use records to create what are in effect data structures: complex data types with many parameters that can be passed to functions as a single entity.

Records have some cool properties in and of themselves, but as is the case with most of EGL, they're even more impressive in conjunction with the IDE and specifically when creating Faces JSP pages. Unfortunately, while I was able to use the included database with predefined parts, when I tried to import that same database, I couldn't get the import process to complete. That's going to have to wait for a third installment, but that's OK because I also want to attach directly to a DB2 database on the System i as well as call RPG programs, all of which require a bit more setup than in the tutorial.

No Language Is an Island

Well, they shouldn't be islands, anyway. IBM recognized that when they enabled Java on the System i and gave us the Java toolbox (which I still consider one of the great unheralded open source projects of our time). The Java toolbox gave Java programmers unprecedented access to all System i functions, including the ability to directly call RPG programs. This is where a lot of code generators tend to fall down. Enamored with their own code-building skills, or sometimes simply too restricted by their own technical and architectural decisions, many 4GL vendors don't provide a clean, universal way of calling other languages. They figure that you can design the database and they'll take care of everything else.

The EGL folks have a different view of things. In addition to the record-level interfaces to things like SQL and MQ Series, there are hooks in place for calling RPG programs on the iSeries, as well as invoking static methods in Java. Disclaimer: I haven't yet played with these interfaces to any great degree, and some of them are still in their formative stages. But you can rest assured that they're next on my list of things to take for a serious test drive.

Second Impressions

My first impressions of EGL were not negative, but I wasn't exactly shouting its praises either. I've seen 4GLs throughout my career; remember, I was the manager of architecture at SSA, and I had an intimate (and often stormy) relationship with the AS/SET development team. I won't mention any names, but in general I've rarely been impressed with code generators.

However, EGL has some things going for it that you don't find in other languages. First, the central focus is on data. Rarely have I seen an environment that is not only language-agnostic, but protocol-agnostic as well. Typically, the only communication between layers will be through some "industry standard" technique, such as result sets or EJBs or Web Services, or else some proprietary interface. Rarely is there an ability to extend the interface to your own custom code. EGL seems to have the hooks in it not only to call custom programs, but also to use not just one, but pretty much all of the current communications standards.

Just as important, though, is the fact that the EGL editor is the first Eclipse-based product that I've seen with the features I consider necessary for a 4GL. These folks have the drag-and-drop visual IDE down to a science. The ability to drag a function onto a button is a direct swipe at Visual Studio .NET, and as you might guess, I like the EGL version better. In addition, most of the wizards have round-trip capabilities. For example, the DataItem wizard is capable of parsing an existing DataItem definition. Contrast this with something like the procedure wizard in RPG, which can only be used to create new procedures. A large part of this is the fact that the EGL language is such a simple, declarative language, but I'd still love the RPG folks to take a look at what the EGL team has accomplished.

Yet I'm still not sold. To me, RPG is still the best language available for writing data-driven business logic. But at the same time, EGL is a rapidly evolving language with some very ambitious goals. My next pass is going to focus on interaction with the non-EGL world, both invoking legacy business logic and exposing EGL as a Web Service. I want to see how EGL plays in the portal arena and whether it has any capabilities in the mobile device and rich client space. But I have to admit that, for once, first impressions can be overcome. I'm beginning to see EGL, together with the power of the Rational tooling, as a true player in the next generation of application development.

Look For Yourself

If you have the time, I highly recommend that you download and walk through the tutorials. You'll need to upgrade your WDSC environment to Version 6.0.1, and once you do, you can then run the tutorials. They're huge and simply chock full of information. They are still primarily zSeries-centric, so be prepared for that. But if you take the time to work through them, I guarantee you'll garner a real appreciation of the product. You may not need what it does, but it still does it very well. The tutorials, along with a ton of other great documentation, can be found at the EGL Zone. That link has some great introductory material. Then, click on the link marked EGL Resources, and that will take you to the tutorials. I suggest starting with the Version 6.0.1 Tutorials and then moving on to the Technical Samples.

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been working in the field since the late 1970s and has made a career of extending the IBM midrange, starting back in the days of the IBM System/3. Joe has used WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. Joe is also the author of E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step, and is speaking at user groups around the country in April, May, and June. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..