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?