I have presented session at iSeries DevCon pretty much since the conference's inception, and this year is no exception. Of course, I'll be doing the heavy lifting on EGL and some other related topics, but there are lots more great speakers and sessions. In my humble opinion, there isn't another conference that better provides both true nuts and bolts programming techniques with a solid application of future-proofing technologies.

Trevor Perry and I have recorded podcasts about what you can expect; click on the link to go to my podcast.

You'll have to enter an email address to get the real link, though.

Okay, with expert guidance from Chris, I managed to engineer a Java-free RUI application architecture. It's not exactly simple. In test mode, any REST request goes through an invisible proxy in the workbench. The request that your service sees is not what the proxy sees; the EGL JavaScript runtime actual wraps your request inside a larger request which is sent to the proxy. The proxy unbundles that and sends it to the target service. The proxy then takes the response, rebundles it and sends it back to the runtime.

So, if you're writing your own RPG version of the proxy, then you have to do all that bundling and unbundling. Then you have to invoke the target service. I, however, skipped that. Since I have control over all the pieces, I extracted the actual business logic and re-wrote the target service to call the business logic. Then I added code in the proxy to call the business logic directly.

It's not quite as complicated as it sounds and it works really well as a proof of concept. I can now say with certainty that it is entirely feasible to write a complete, Java-free EGL Rich UI application, using only RPG as the back end.

I'll clean up the code and export the project (including a savefile with the RPG code) in the next day or two.

Well, this has been an interesting little excursion. I really wanted to make sure that I tried to test the boundaries of the "Java-free" EGL/RPG architecture and as soon as I did, I ran into a little bump.

The problem is that you can't use a variable as the URL of the REST request. I don't understand the limitation and I haven't really asked about it yet, but the limitation is real for now. And because of that, you can't just pass your parameters as variables in the URL and then retrieve them with simple calls to QzhbCgiParse in your RPG-CGI program.

All is not lost. As it turns out, when you call a function in a REST service the parameters for the function are passed to the REST service as a JSON string. The JSON string is somewhat buried in the POST data and to make it even more challenging the data is in ASCII, but the parameters are more or less accessible, depending on how hard you're willing to look.

I'm going to take the time to write a simple procedure to extract the parameter string from the POST data. Then in order to make things simple I'll write a second procedure to treat the parameter string as a single string parameter (if that's not too confusing). It will assume that any REST function has only a single parameter of type string.

With that, I can then build comma delimited data in the Rich UI client and parse it in the RPG program using %scan. It's not quite as seamless or flexible as the magic Record-to-Data Structure conversion of EGL, but it will prove the point. Once that's done, though, I think it will be time for me to move to a true EGL Service implementation.

Anyway, that's what I'm working on. Hopefully I'll have it done in the next day or so. It's just a little bit of a speed bump.

Comments would be great. And if an IBMer happens along this and thinks I'm doing something completely bizarre, feel free to let me know...

Okay, this was a lot easier than I expected. I'm not saying it didn't requier a little research; the QzhbCgiParse API is not for the faint of heart. But a little research, a little careful reverse engineering, and I was able to create a program that responds to a Rich UI REST request. And it takes nine lines:

QzhbCgiParse( '-v Cust': 'CGII0100': cust: %size(cust):
              bytesRead : dsError);
if (bytesRead > 1);
  cust = %subst( cust: 1: bytesRead-1);
endif;

data = 'Content-Type: text/html' + CRLF + CRLF;
QtmhWrStout(data: %len(data): dsError);

data = '{"result" : "' + 'Name-' +
       %trim(cust) + '"}' + CRLF;
QtmhWrStout(data: %len(data): dsError);

return;

The simplicity of the code is rather impressive. The first line gets the data from the URL, the next three strip off the trailing LF that QzhbCgiParse insists on giving you. The next two lines send the header, the last two send the response formatted as a JSON string. That's all there is to it. There are obviously a couple of prototypes, and the ubiquitous error data structure that is familiar to anybody who codes API calls in RPG, but those can be /COPY'd in. The meat of the code is the eight lines above (nine counting the return).

The code in the test program is even simpler:

testService testService { @RESTBinding
  {baseURI = 
    "http://IRUIHOST/cgi-bin/RUIT1.PGM?Cust=77654"}};
call testService.getName() 
  returning to ts1listen
  onException ServiceLib.serviceExceptionHandler;

It's a standard REST call, except I change the baseRUI to pass the parameters. Now, I haven't gotten around to figuring out how to pass the parameter via the actual method call, but for this particular proof of concept I don't care about that. The point of this exercise is to prove that anything you can do with "traditional" EGL - that is, a web service written in EGL and deployed in an application server that calls an RPG program - can be done using nothing but the Powered by Apache server and standard RPG-CGI - that is, no Java, no WebSphere, nothing you wouldn't have to know for any other approach. You just have to learn the EGL Rich UI syntax.

Now, I wouldn't recommend this approach since if you can write EGL Rich UI you can write host-based EGL just as easily, but if you absolutely cannot run WebSphere or Tomcat, then this will allow you to still use EGL Rich UI.

Nifty, huh?

Let me clean up the example to something a little less trivial and I'll post this project, probably tomorrow sometime. As I noted at the beginning, I'm doing this solely in my free time and I used up most of that time tonight writing this blog post .

Although still in the "hello world" stage, I think ther are a few basic web functions that I can verify before moving into the more rarified world of business applications.

One problem with a language like EGL (or indeed any program generator) is the potential for lock-in. While it does a lot of things really well and really productively, you have that nagging feeling at the back of your mind that you're going to hit a wall somewhere, and that's when the proverbial other shoe will drop.

For example, you might want to incorporate some nifty widget from the outside world. Typically, this involves hacking the generated code, those hacks then get wiped out the next ttime you generate. This has been the bane of 4GL programmers forever. But EGL is supposed to be better than that - it's supposed to be designed with extensibility in mind. To that end, I used this version (V1R1) to see if I could take advantage of outside code.

To do that, I went to one of the roughly sixteen million web sites that allow you to create free hit counters, and I created one. I then added the generated HTML to my RUI page using the "HTML" widget. The results were expected: the counter works fine.

The new PIF file can be found on the See What i Can Do thread.

Okay, what's the new project all about? Well, it's got a whole set of rather ambitious goals, from creating killer apps for the i to comparing the productivity of EGL compared to PHP.

What I plan to do is simple: I'm going to create apps right before your very eyes. As I noted in the previous post, I've got one up and running, at http://see-what-i-can-do.com. The application is simple: it shows "Hello There" and if you roll your mouse over the graphic, the phrase "...from see-what-i-can-do" appears. Pretty simple stuff.

It took me about five minutes to create the application. In fact, it took longer to create the nifty "Hello There" graphic than it did to write the EGL that displays it. And then it took me another hour or so to figure out how to create a virtual host in Apache and deploy the application. Now, though, I'm pretty confident that I can update the application and deploy it in just a minute.

In fact, I'm going to do that as I write this entry. I'm going to add "V2.0" to the message. It's 3:30PM by my workstation. Let's see how long it takes.

Fire up RDi-SOA.
Modify the EGL.
Redeploy it locally.
Copy the file to the IFS.
Rename it to index.html.

Done... at 3:32PM.

Cool!

Okay, the idea is to create the applications, and then make them available as downloadable Project Interchange Files. I'll start with simple applications like this using only Rich UI. Next I plan to attach to RPG programs, starting using simple RPG-CGI. Eventually I'll use traditional EGL to provide the web services, but one step at a time.

I plan to write a number of applications: dashboards, blogs, polls, inquiries, data entry, you name it. Follow along with me as I do it. Oh - and tell any PHP advocates you might know about the project as well. Because I double dog dare them to be able to do anything as quickly as I do it...

Later!

So let's see here ... the last time I blogged was December of last year. That was a looooong eight months ago, folks. But now I really am back. The new book is in production with a release date of November 1st. It took a lot more effort than I'd expected, mostly because I didn't even know what "EGL Rich UI" was when I first envisioned the book.

No matter; the book is very cool and provides a complete in-depth guide - with source code! - to building multi-tiered applications using the IBM i as the business logic server (although technically speaking you can use anything as a service provider - that's part of the beauty of SOA).

So now with the book out of my hands (and hopefully into yours!), I'm starting a new project. This one is much better suited to blogging, and I'll post about that in my next blog entry.

I haven't been posting this month because I've been really busy getting ready for iSeries DevCon. This is one of the best technical conferences, although you might consider me a little biased; in four days, I give one all-day jumpstart (this year on migrating from PDM and SEU to RDi) and then 10 sessions and hands-on labs. It's always been a forward-thinking conference; I did sessions there on Eclipse and Visual Age for Java (Eclipse's predecessor) as far back as 2001, along with some of my first web-enabling sessions.

Since then, they've always been ready to present the latest technologies and so this year I gave what I'm pretty sure was the first hands-on EGL lab at an i technical conference, along with a number of other sessions and labs ranging from multi-tier architecture development to extending Rational tools with Eclipse plugins. My session on Eclipse, WebSphere and Rational was repeated, and even though the second one was in the last slot on the last day, we still had good turnout.

In the i space, EGL has to deal with all the buzz surrounding PHP and MySQL. To me, that buzz is nothing more than white noise because PHP just doesn't stand up to EGL when it comes to ease of use, adoption of advanced technology and integration - especially with the i. As a simple example, PHP's connection to the i involves using a PHP knockoff of IBM's Java toolbox, and while the toolbox is phenomenal technology, using it directly requires a lot of code; a simple program call might require dozens of lines of code. With EGL, it's a simple CALL statement. And when I demonstrated how easy it was to build entire applications using RDi-SOA to write EGL front ends and RPG back ends, people started getting excited. In a simple 90-minutes lab attendees with no prior Java experience were able to create an EGL record, build a JSF page, then flip over to the RSE perspective to compile the RPG business logic, and then back to the EGL to add a few lines of code to attach the two.

I also did a lab on multi-tiered architecture without EGL (using plain old JSP and Java) and the people who attended both really got an understanding of what EGL was all about: simplifying the plumbing. Even the simplest web application requires a significant amount of plumbing code in any 3GL, whether it's Java or PHP or RPG-CGI. EGL removes all of that for you. Not only that, but the very nature of the language makes it easy to reuse code, so that once you've created a JSF client, it's simple to turn around and create a rich client or a web service. I think that really hit home with a lot of the attendees.

Anyway, I'm back now and I'm focused on the Rich UI book. You'll see a lot more about that in the coming weeks. It's good to be back, and thanks for reading!