EGL and i

See What i Can Do - V2R1 (Complete!)

JoePluta — Mon, 14 Sep 2009 03:13:13 GMT

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.

See What i Can Do - V2R1 (Update)

JoePluta — Wed, 09 Sep 2009 23:32:57 GMT

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.

See What i Can Do - V2R1 (Status)

JoePluta — Mon, 07 Sep 2009 02:30:30 GMT

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.

See What i Can Do - V2R1 (Notes)

JoePluta — Fri, 04 Sep 2009 13:45:06 GMT

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...

See What i Can Do - V2R1 (Preview)

JoePluta — Wed, 02 Sep 2009 03:34:48 GMT

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?

See What i Can Do - V2R0 - Reprise

JoePluta — Mon, 31 Aug 2009 21:59:02 GMT

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 .

See What i Can Do - V2R0

JoePluta — Sun, 30 Aug 2009 23:43:50 GMT

Okay, I'm now in the pre-flight phase of version two. I'll leave V1 alone for the time being, although I may circle back to it later in order to investigate other pure client-side issues. But I want to get right to the core of what's important to EGl and i, calling business logic on the i. The purpose of V2 is to address the issue that EGL Rich UI requires WebSphere (or some other web application server) to run.

That's simply not the case. Rich UI handles both SOAP and REST service calls, which means that it talks to anything that does either of those. Most platforms can create SOAP services. The problem is that SOAP is over-engineered bloatware; the correct answer is to use REST.

Unfortunately, I don't have any examples of using pure RPG-CGI as either a SOAP service provider or a REST service provider. I could use the wizard provided with the standard i5/OS web administration tool to create a "Web Service Server" but that's still a SOAP service. I'm going to try a sidetrack to write my own code that will provide a simple REST response.

As always I'll be relying on groundwork done by others, in this case I'll probably be reviewing and probably liberally re-engineering code from Craig Pelkie and Scott Klement, as well as making use of Chris Laffra's service monitor. I'll need all the help I can get, because this is completely untraveled territory.

Wish me luck - I'll get back to you in a day or two.

See What i Can Do - V1R1

JoePluta — Sat, 29 Aug 2009 19:47:17 GMT

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.

The New Project - Overview

JoePluta — Wed, 26 Aug 2009 20:36:11 GMT

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!

Well, THAT was Fun!

JoePluta — Wed, 26 Aug 2009 01:05:25 GMT

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.

Notes from iSeries DevCon

JoePluta — Thu, 30 Oct 2008 14:13:36 GMT

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!

EGL Rich UI - The Next Generation

JoePluta — Fri, 05 Sep 2008 16:03:23 GMT

RUI-TNG?

No, seriously, what I mean is this is the next generation of posts on the RUI topic. A month ago I wrote that some exciting stuff was in the works, and now I can tell you about it. This will actually be a short blog entry - I just want to let you know what's coming.

Briefly, I'm writing a book. The book is going to be about using RDi SOA to build EGL Rich UI applications with the i. EGL Rich UI is the "formal" term for RUI, and if you haven't played with it yet, you should get yourself down to the alphaWorks site and get a copy (and yes I know the page says EGL Rich Web Support, but I have it on good authority that EGL Rich UI is the official name).

The book will show how to build a Rich UI interface using EGL and then connect that to a business logic back end written in RPG. Every step of the way will be written and debugged using Rational tooling.

And those of you who read my blog will get an inside look into the process of writing a book. It may inspire some of you to try your own hand at it. Those of you with clearer heads will run screaming...

Anyway, that's the short version. This ought to be an interesting project...

Rich UI and I (and i)

JoePluta — Wed, 06 Aug 2008 17:25:06 GMT

Hello there! It's been a very hectic few weeks here with lots of projects (some of which I can tell you about, some of which I can't... yet). I haven't been able to post as much as I had liked but I hope to be able to fix that over the coming months. I especially hope to give you some updates regarding the Rich UI and how that particular code works with the i.

To start with, I've managed to create end-to-end rich applications using nothing but the Rational tooling. These applications run from a Rich client in the browser written using the latest RUI release, through a web service written in EGL using RBD 7.1, to an RPG program written using RDi 7.1. It's fast and easy - the entire web service infrastructure, for example, only took a dozen or so lines. I'm looking forward to the day when all three components live together in a single workbench, but for now it's pretty easy. In fact, I run all three tools on my desktop at the same time in less than 1GB of memory (my Firefox and Thunderbird take up more!).

I've begun playing with the various widgets, including the Dojo widgets. I created a simple application that invokes a web service to get data and then shows that data side-by-side using a regular Grid object and a DojoGrid. I'm finding some interesting things about developing, including issues with the debugger and with passing complex objects (remind me to explain why you can't create a factory function that returns a DojoGrid).

All in all, it's been very interesting. Unfortunately, the real projects are taking most of my time, so I don't have a lot to share publicly this post, but I hope to be able to tell you more about some of those projects soon. And in the meantime, I'll try to keep updating you with what I've been up to. I see if I can figure out how to post my end-to-end HelloWorld application later this week.

Thanks as always for reading!

Taking EGL and i to the Next Level

JoePluta — Tue, 15 Jul 2008 16:54:56 GMT

Ha! I snuck in under the wire - it's been (just) less than a month since my last blog post. I hate when someone starts a blog and then just stops posting, but I assure you I had good reason. June was a super hectic month (including RSDC and OCEAN), and July hasn't shown any signs of letting up. There are things happening in the EGL world, some of which I can tell you, some I can't just yet. But suffice to say there will be a lot of things to talk about in the coming months - but you knew that would be the case, anyway, didn't you?

At the same time, I've had to keep up with the i world as well. Remember the name of this blog: EGL and i. Well, the i world has had some major announcements lately, many of which have to do with EGL directly or indirectly. For example, the ability to trade up from ADTS (the green screen tools) to RDi has been announced, which puts i programmers one step closer to EGL - hopefully once they play with RDi for a little while, they'll download a trial of RBD and find out what is really available!

Also, IBM announced the new Power 520 Express package - a powerful developer machine that includes a seat of RDi-SOA for EGL. IBM now has an entry level EGL machine for the RPG developer. This is huge. Anyway, I've been writing about that; you can read articles in MC Press and IBM Systems Magazine covering those topics.

But now I'm back and ready to roll with EGL. As many of you probably are, I'm waiting very expectantly for the next Alphaworks drop of Rich Web Support for EGL. As soon as it's available, I'll load it here at the Pluta Labs, and I'll strart letting you know what's up. Some say that Rich UI is a great complement for JSF, others say it is a replacement. I'll let you know what I think as I learn more about it, and this blog will be the primary place where you'll hear about my day to day struggles (well, here and in the forums :)).

Let's see how quickly this old dog can learn some new tech...

Welcome to EGL and i

JoePluta — Wed, 11 Jun 2008 05:22:41 GMT

I noticed that I have been somewhat remiss in that I haven't actually written a formal "Welcome to my Blog" post. This is my first blog, so perhaps you can forgive me that transgression. (I told my good friend David that I had finally releneted and was blogging. His response? "I AM LOCUTUS OF BLOG! YOU WILL BE ASSIMILATED! RESISTANCE IS FUTILE!" Guess he's right.) Anyway, it's that time - time where I try to let you know what this corner of the Internet is intended to be about, and you can decide whether you want to follow the bouncing blogger.

I have a very straightforward goal. I want the i platform to continue on being the best darned business logic server ever designed, and EGL is the way to do it. The reason is simple: the IBM i, whatever it's name or incarnation, has always been about simplicity. You could, with enough work, get another platform to do most of what the i does. But it was always easier, and faster, and more productive with the i. Not only that, but until the advent of the Web, the i was perhaps the last bastion of the one-person IT shop; one good programmer could literally do everything required to keep an i shop running. If you knew DDS, CL and RPG (or COBOL), and knew how to hit F1 and F4, you could pretty much run an i and keep its users happy.

However, in the brave new world of Web development, the i message got a little fragmented. Rather than there being a single path to getting your work done, there were many. RPG-CGI, Net.Data, Java, and now even PHP; these were all heralded at one time or another as the way to the web for i shops, but for one reason or another, they never lived up to the hype. It seemed that the technology was either easy to use but a little out-of-date, or else so bleeding edge that developers couldn't keep up. In either case, the i slipped further behind the curve and we know the outcome: it became that "old" box in the corner that just wasn't glitzy enough. Forget that it had been running all applicaitons flawlessly and with nearly zero downtime for years; the new generation is all about the glitz, and what have you done for me lately.

Enter EGL! By combining a procedural syntax with the concept of hiding complexity, EGL does what i developers have been asking for: it gives them a clean, consistent way to write web applications where they can concentrate on the business logic rather than the plumbing. In many ways, EGL is the spiritual successor to the 5250. While it far surpasses the 5250 in rich user experience, in many ways it's as easy, if not easier, to use than the old green screen SDA. Combine that with a carefully crafted and deceptively simple CALL Interface, and EGL does for the web what display files did for the green screen.

There's a subplot here: using EGL and RPG together. Note that I said RPG; you could also use COBOL if you were so inclined, and lots of EGL folks do. In fact, EGL will generate COBOL and I will spend some time with that particular piece of the technology over the coming months. But I am an i guy, and for the majority of us, RPG is the language we use to code business logic. And while there are lots of really super-bright people working to make EGL a complete, self-contained business language, my particular self-appointed niche is going to be making sure that all those RPG programs (and more importantly, those RPG programmers) can use EGL to enhance and extend their existing applications, letting them co-exist with brand new applications (written in EGL, of course!).

Programmers may some day be able to write entire ERP applications using nothing but EGL; that's certainly the goal of the EGL team. But for now, i shops already have business logic - logic that they've spent years (even decades!) developing - and the best initial use of EGL in those shops is exposing that logic, either directly as browser-based web applications or - moving to the true SOA approach - as web services that can be consumed by other internal and external clients. Then, they can combine that newly enabled business logic with all the rich application features of EGL to create new integrated applications they never dreamed of.

And my goal will be to explain how to do that quickly and productively.