Okay, I've written the first-generation RPG proxy program. Basically the proxy's job is to extract the request from the EGL Rich UI runtime and invoke the appropriate business logic.

It's a little more complex than that. If you're testing locally your request is automatically redirected to the local proxy that runs inside the workbench. The proxy calls your CGI service and your service extracts the data from the request. The request looks something like this:

{"bindingName":"PollService","method":"getPoll","params":[0]}

And you return data that looks something like this:

{"result" : { "name" : "Language Poll", "choices" : [{ "choice" : "RPG", "votes" : 87},{ "choice" : "EGL", "votes" : 33},{ "choice" : "PHP", "votes" : 2}]}}

Not too difficult. However, once you deploy to your host machine, things get a little more complex. The runtime no longer uses the proxy in the workbench, and instead it has to send to your proxy. Your proxy program then has to unbundle the request from the larger request, which now looks like this:

{"uri":"http:\/\/IRUIHOST\/cgi-bin\/POLLSVC2.PGM","queryParameters":{},"method":"POST","body":"{\"bindingName\":\"PollService\",\"method\":\"getPoll\",\"params\":[0]}","headers":{"EGLREST":"TRUE","egl_statefulsessionid":"JSESSIONID","Content-Type":"application\/json; charset=UTF-8"}}

A little more ugly, no? Not only that, you have to also buffer your reply into something just as complex. However, I managed to hide most of that complexity in a single program named EGLPRSCGI. I then have two programs, POLLCGI2 and CGIPROXY, each of which calls EGLCGIPRS to get the parameters from the client. Each then calls POLLSVC1, which is the actual business logic, and then formats the response as needed (CGIPROXY does a lot more formatting).

Eventually, CGIPROXY would have to recognize all the various requests and call the appropriate service program. But for now, you can get the project, and you can see the result on the SWICD website:

http://see-what-i-can-do.com/poll2.html

It's pretty slick, actually.

The project interchange file is on the project interchange discussion post.

It looks like I may have bitten off more than I can chew with this little project. I'm not completely certain, but it looks like the concept of an EGL Rich UI application using nothing but an HTTP server is not going to work. Unless I'm mistaken it looks like the Rich UI REST calls go through a proxy servlet. This is done for a practical reason; it allows the Rich UI to make calls to services other than the original host, a feat which is not allowed in normal AJAX calls. However, it does mean that even if the actual REST service is served by Apache (such as my RPG-CGI service), the proxy servlet still needs to be running in a web application server on the host.

Thus the vision of a Java-free Rich UI application has hit what may be a fatal roadblock. (Note: the reason it worked in debug is that evidently the workbench has that proxy server magically enabled. I still don't have all the details on that bit of sleight-of-hand, but I'll let you know if I get more specifics.)

It was still a useful learning experience, but all in all I'd have preferred a better outcome. In any case, I think it's time to put the Java-free RUI on the side and get back to traditional Rich UI development. And if nothing else, I've got a cool widget written.

Look for the "normal" version in the next day or two.

Given how easy it was to create an RPG-only service, I've decided to kill two birds with one stone with V2R1. I'm going to create my first persistent widget, and I'm going to do it without any Java code (and thus, without the requirement for a web application server). I'll eventually return to this code and rewrite it using traditional host-side EGL for the service, but this first non-Java version will be an interesting exercise.

The concept of a "persistent widget" is going to be crucial to this project. The term means a widget that persists between accesses and can be accessed by multiple sessions. In its simplest form, a persistent widget is simply a widget backed by a database. In my first go-round I think I'll create a "Poll" widget. A poll will have a unique name, and for children it will have choices, each of which has an attribute of choice text and number of votes.

The EGL record for this will be wonderfully simple, and unless I'm mistaken the RPG program will be very simple as well. I think that by my next blog entry I ought to be able to create an RPG program that not only returns a Poll object, but also allows update. That should then make it almost trivial to create a user interface that allows anyone to vote in the poll.

What do you think? My idea is that we ought to be able to create a whole library of self-contained persistent widgets which can then be used to build applications. What other widgets do you think might make sense?

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!