EGL and i

Previous Next
4

Welcome to EGL and i

Posted by JoePluta Jun 11, 2008

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.



Jun 18, 2008 11:09 AM Click to view KurtRump's profile KurtRump

I have seen numerous posts in other forums where traditional i developers have pleaded for a native GUI. Your description of EGL as "the spiritual successor to the 5250" that is "as easy, if not easier, to use than the old green screen SDA" suggests to me that EGL might be the closest thing there is to a native GUI. Would you agree?

I am not an application developer, but I have the opportunity to speak to many of them. One of them took the time to send me an e-mail which documented his thoughts and concerns about current GUI approaches available to the RPG developer. If you're interested, I could forward it to you. Meanwhile, if EGL is the answer, I'd like to have a simple and compelling way to convey this to the i community. Perhaps you could use your blog to help flesh out the story.

Jun 18, 2008 1:01 PM Click to view JoePluta's profile JoePluta in response to: KurtRump

Yes, I think I would. EGL is as close to a native GUI as I want anything to be, actually. While 5250 was a great idea for its time, that was because there really was no other standard out there. The 5250 datastream filled the place of HTML and CSS and all that other good stuff we're using today - if you think about it the 5250 display was in some ways a browser for character data.

Some people are asking for a GUI enhancement to the RPG language - a new datastream for the new millenium, I guess you could call it. But the problem I see with that is that no matter how good it is, it will always be behind the curve. The pace of technology is such that frameworks like Dojo and YUI and GWTx are proliferating and expanding faster than any one company could match. So the best answer is not to emulate, but to integrate. In OO terms, provide an Adapter - use a simple business-oriented syntax to allow programmers to access the complex capabilities of these new frameworks.

That's where EGL is going to really shine, in my opinion. By abstracting the concept of UI, it avoids getting locked into any one technology, and instead allows developers to use the toolset which fits best. The Rich Web Services stuff that's coming out soon is really going to raise the bar on what business programmers can do.

Because the native GUI of the i shouldn't be any one technology - it should be all of them.

And please, send me the response. I'd love to see it and I'd love to see if I can indeed address this entire architecture issue as the blog progresses.

Jun 19, 2008 10:35 AM Click to view KurtRump's profile KurtRump in response to: JoePluta

Following are excerpts from the e-mail I referenced regarding a GUI interface for RPG. When I spoke to the author, he described himself not as a computer scientist or programmer, but as a business man who learned a simple programming language (RPG) and began writing applications to meet the needs of a school district. You'll see in his comments the level of frustration that has surfaced with regard to the complexities of building a Web interface. He goes on to propose a possible architecture from his point of view. And by the way, his reference to both Mac and PC users is intended to raise awareness to the fact that many of the tools available (e.g. HATS) don't list Mac browsers among those that are supported. Here you go...

"This is a big problem for us and other school districts that I know about that are using the AS/400.
We really need to be able to easily talk to our teachers, students and parents and we cannot use
5250 emulation to do that. Many districts are plagued with having both Windows and Mac computers
that they have to support, so web applications need to be browser independent.

Things that we need from our end to support this environment.
1. When I do a wrkactjob, I need to be able to see who is on the computer and what it is they are running. If we try and use the traditional HTTP jobs that the internet runs, we just get hits to our server. That is really hard to work with if there is a problem. That is also a performance hit for the user when programs and files continually need to be opened every time data is needed. All of our work is OLTP. We don't run a public web site from our AS/400.

2. I have avoided using RPG IV as much as possible as it was not written for RPG programmers. It has some nice features for some things and I have used it where needed. I recognize that RPG/400 is no longer being enhanced and I expect that any GUI interface will only be offered in the current version of RPG. If it is easy to use, that won't be a problem. I expect all the 'character to data' conversion that takes place in the 5250 world to also work in the GUI world. Everything that I have seen of the "Open" solutions is a real pain when it comes to data conversions. That is why I expressed the implementation as EXFMT WEBPAGE. That should explain it.

The browser based platform on which the applications are being presented needs to be smart enough to know when the user just clicks on the back button or the red X, to close the window and not just drop the connection. The environment that I am looking for is NOT one where a user is doing their normal jumping around web sites. When they jump into this interactive mode, they need to be under program control so they cannot have access to these other "Web" features, until they exit the application they are in. I don't really want to deal with session cookies, etc. I don't do that in the 5250 environment and I don't want to do that in a Browser environment. To me this is just a screen that I am using to communicate with the user. I want the ability to make the user interface more like a Windows or Mac user program, and not have users jumping around to other things.

Please start with i5/OS and work towards using the browser as a screen and do not work at coming from the Internet and try to get the RPG program to work like PHP or some other scripting language talking to the HTTP server. That is a long way from where I need to be at this point. For those types of activities, I can use PHP or the XML features in RPG for web services. That whole model is entirely too complicated for doing OLTP and too slow to run and or develop applications in.

I hope that this makes it easier to implement. Some kind of a "plug-in" that takes over the browser for this kind of communication would be just fine. This could be checked each time the connection is established to see if it is current. If not, the latest plug-in could be sent to that browser before the application loads. That should be something totally transparent to the application running on the AS/400. What I cannot do is have someone loading or maintaining programs on computers that will be communicating with the AS/400. I have over 60,000 students, thousands of teachers, and a lot of parents. None of them would spend a lot of time on the AS/400, but when they do, the user interface needs to be fast, simple to use, capable of supporting e-mail and pictures, and have the ability to print reports on their local printers. They should also have the ability to browse and attach files, as needed by the specific application. These are simple things that people are used to doing in their browser. If this is a fully integrated function that can be done by running an RPG program on an AS/400 then we have a good connection to our customers.

DDS has a lot of things that our current 5250 emulator does not support, such as mouse clicks, drop down lists, etc. I don't really expect that I would use a green screen to design a browser interface. If I end up using a PC to create the interface, it needs to be very close to what I have used DDS to create for the green screen. I use the PC to create the interface, create an object in a library that will then be available when I compile the RPG program. When I do the EXFMT WEBPAGE, the program runs and displays the screen in my browser. I recognize that is probably the sticking point in the development, because there is no clear way to do that. I have no idea as to how the 5250 environment works currently with my PC and I know even less about the browser and how it works, but somehow the connection needs to be made. I know that the browser is designed to work with the HTTP server, but either the connection needs to be made behind that on the AS/400, or this plug-in needs to be able to get the browser to connect to the 5250 data stream or some other xxx data stream that would be coming out of the AS/400 so that we get this connection made."

Jun 20, 2008 9:46 AM Click to view JoePluta's profile JoePluta in response to: KurtRump

Thanks, Kurt!

This is a very long laundry list and is in effect a sort of design specification for a GUI tool. The primary issue here is that the interface is server-centric; the server runs the show. When I wrote my e-Deployment book back in 2000 I outlined exactly this architecture: JSP pages replaced 5250 screens. I call this "server/client" as opposed to "client/server" and your associate seems to understand the difference.

EGL is not a server/client model. Although it can be used that way, as can JSP, bending the browser to act as a "dumb tube" akin to a 5250 is neither simple nor 100% successful. Certain issues like closing the browser or cross-browser compatibility tend to come into play. My PSC iQ product comes about as close as anything available on the market, and the HATS/Webfacing technology is very similar.

But no, I don't think that there is an out-of-the-box match between what this person is asking for and what EGL provides.

Bottom Banner