Although it's not really the focus of this entry, I just like saying that. It's such a good marketing phrase; I wish we'd see more like it. And we could, you know - the EGL team is putting together the kind of glitzy eye-catching technology that could be showcased everywhere from a YouTube spot to a Super Bowl ad (do I have to pay to say that?).
I guess though that catchphrase is indeed germane to this entry; in a way it really epitomizes a large part of what I want this blog to be about: moving the i into the future (I'm not going to make all the *i*'s blue this time - bold ought to be enough). I want to really delve into those areas where the particular strengths of EGL and the i work together the best. For example, in the case of the RSDC scheduler, Chris Laffra and I were able to make three technologies - EGL Java/WebSphere, EGL RUI and good old RPG - work together flawlessly. Development was at a pace unlike anything I've done in a long time, and the fact that we could concentrate on the business requirements rather than the plumbing allowed us to deliver code at the speed of thought. It was quite an exhilirating experience, actually.
But what exactly does that mean for my core constituency? What can EGL really do for the long-time IBM midrange customers? These are customers who have entrusted their business to the midrange since it had names like "System/3" and technologies like CCP, customers whose most important asset right now is not even their programs so much as their programmers - programmers with a skill set that all signs indicate is becoming harder and harder to find.
What can EGL do for these folks? Well, in my vision, EGL is nothing short of the wonder drug for these shops. First, it will allow procedural programmers to write web applications. The popularity of languages like Visual Basic and PHP ought to make it clear that not all code need be written in OO, and that procedural programming is still an important otol in the business toolkit. This is particularly good news for business programmers becuase the procedural nature of EGL removes one of the biggest hurdles between RPG/COBOL programmers and the brave new world of the web. The WYSIWYG design tools and the declarative nature of the EGL syntax is putty in the hands of people who have written RPG code.
But if the tool just put a new face on an old paradigm, it wouldn't be the future; it would just be a holding pattern. The future is where EGL really shines. Once you have your business logic encapsaulted in EGL library functions, you will be able to move forward into the world of AJAX and eventually to Rich Web Services (RWS or RUI, depending on which acronym you prefer). But the good news is that you don't have to do that wholesale. You can rewrite parts of your application with JSF (in fact JSF may be all you ever need for large parts of traditional green screen systems) and then apply the new technologies where they are best suited, such as for new executive dashboards or other Web 2.0 types of applications.
I always say thatyou should use the right tool for the job, and for i shops the right tool includes business logic on the i and then EGL for whatever user interface technologies are needed. The beauty is that the right tool for all of the new generation of UI jobs is EGL. [Read More]
JoePluta 100000KMX3 1,086 Views
JoePluta 100000KMX3 Tags:  i business_logic application_modernization egl rpg 4 Comments 2,734 Views
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.[Read More]
Well, of course it was William Shatner, not Captain Kirk, but it was still outstanding. Through a series of terrifically funny anecdotes, Shatner related the software development industry to the movie production industry, and often had the audience howling. It was all great fun.
Seeing my boyhood idol was just one more of the surreal bits of my time in Orlando. Through my own lack of prior preparation, I had to stay offsite, so both days I found myself cabbing through Disney World. It was always a bit of a mental clash to go from the high-energy environment of the conference to looking out the window of the cab and seeing the Tower of Terror.
I would have loved to stay longer, but there are just too many things to do back here at home. When I gave my session, it was clear that the attendees saw the power of the tool, and how EGL could provide them with the fastest way to extend the business logic behind their green screen code to the web and beyond. It's a great story: a few lines of code and you can call an ILE program. Drag and drop an array on a page, and you have a table of data. Or, check a box and turn a function into a web service. Just a few lines of EGL turns the IBM i into a full-fledged participant in modern application architectures.
But it doesn't stop there. Add onto that the new Rich Web Services capabilites and now you're at the very leading edfe of technology. I stuck my head into a Dojo session, and I know that the RWS team is looking at the GWTx toolkit. And that's what puts EGL head and shoulders above things like RPG-CGI and PHP. Instead of spending their time figuring out the plumbing needed to add basic web capabilities to their existing systems, i developers can use EGL to do the plumbing for them and can instead focus on architecting the next generation of applications.
Joe [Read More]
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 [Read More]
winghong 120000Q3UD 1,034 Views
Welcome to the EGL Development Team blog! The EGL development team consists of the testers, developers, writers and architects who make the magic of EGL technology happen. This is a highly talented group of individuals who are dispersed around the world: North Carolina, US (our main site), Connecticut, US, Beijing, China and Toronto, Canada.
In this blog, you will hear from us what we are up to with driving our technology and products forward. Occasionally, you might even hear about what we are up to with our personal lives. We hope to develop a virtual connection with you, our users. Please give us feedback by commenting on our blog entries.
I am very excited about what we are doing and where we are headed with the product. My team and I look forward to sharing our excitement with you via this blog.
Wing Hong (Albert) Ho, Senior Manager, EGL & RBD Development[Read More]