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

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

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.

It's been an interesting few weeks as Chris Laffra and I have been working on the scheduler application for RSDC. To give you a quick overview, I'm running the EGL part of the application on a Windows workstation (in fact, I'm running it inside of RBD's test environment). That in turn talks to my IBM iSeries model 270 and exposes the RPG business logic as web services. The front end that consumes the web services (written in EGL Rich UI) is being served either through that same RBD instance or from a public PHP server in Norway somewhere.

So as it stands, you could be using a browser in South America to talk to a server in Chicago that talks to an iSeries in the same room, or you could be using an iPhone in Japan to talk to a PHP server in Norway that talks to that same iSeries in Chicago. And all of this without Chris or I having to write a single line of Java code or do much of anything except generate the WSDL using RBD (me) and consume it (him). And all with excellent speed. And you should see it when the whole thing is on a single LAN!

Anyway, the really interesting bit happened last week. The iSeries (and its successors, the System i and now the IBM i) share an incredible reliability. They're very good about handling RAID disk and they also will tell you about any problems they're having. I happen to have two servers: an older workhorse model 270 that I own and that I use for day-to-day application serving, and then a newer development box that I lease, getting a new box every year or two to keep up with the latest technologies.

Well, the production machine, where I was running the application, started telling me it had a pending disk drive error. I love that - not only does it support RAID, but it also tells you when one of the drives is acting up even before it fails so that you can be ready to replace it. And while replacing a drive is easy enough, rebuilding a RAID set takes time. Since we were getting close to the conference and actually had the application up for live testing, I didn't really want to bring the machine down for the couple of hours it would take to rebuild the RAID set.

So I made an executive decision. I brought down the WAS server in RBD, did a save/restore of the RSDC library from the production i machine (the model 270) to the development i machine (the model 520), changed the server name on the Linkage parts, did a quick regen of the app, and restarted the WAS server. All of this took about five minutes, and nobody was the wiser. And reflecting on this, since I use a hardcoded HOSTS table on the workstation, I could have simply changed that entry to point to the other model 520 and saved myself two of those five minutes.

The point of all this? Well it seems that the architecture is doing exactly what it's supposed to do. Chris was able to do initial testing without even needing the back end. Then, once the back end was up, it was easy to run the front end simultaneously on two different machines. And as for the back end, failing over to a different machine is as easy as changing an address in the HOSTS table. Chris and I have been able to concentrate on features rather than infrastructure, and that really is the promise of EGL.

Joe