Blog Posts

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

EGL Rich UI makes the development of Rich Web Applications much easier. Why is that?


(see http://geekandpoke.typepad.com/)

Web2.0 applications are hard to build because developers have to learn many different technologies, such as JavaScript, HTML, CSS, Ajax, Dojo, SilverLight, SOAP, Flex, XML, JSON; the list of acronyms goes on forever. Many of the required technologies operate on a very detailed, low level. Furthermore, most of these technologies use completely different metaphors and abstractions, which makes them hard to mix and match. The end result is that web rich applications require highly skilled adaptable software hackers. Matching those skills from a pool of traditional business developers is a big challenge.

EGL Rich Web was specifically developed to easily develop these highly responsive rich web applications. EGL strives to provide abstractions that are at just the right level, allowing developers to focus on the "what", rather than on the "how". All user interfaces are expressed in a declarative language, and Ajax calls are very easily implemented because EGL Rich Web automatically parses the resulting JSON and XML documents and turns them into easy to manage EGL data structures.

Furthermore, with the addition of EGL Rich Web support, it is now possible to write an entire web based application, from server to the user interface, in EGL. And, once you have learned EGL for one specific application tier, you can immediately transfer those skills and be productive in all parts of an application.

The Application Transformation Blog is a forum for IBMers, customers and business partners to discuss the who, what , when, where , how and whys of transforming legacy applications written in VAGen, SmallTalk, I4GL, Natural/ADABAS, RPG, CA Cool:Gen, CA Ideal, CA Telon, Maestro, APS, Powerbuilder, VB, and other 4GLs to Rational Business Developer featuring EGL technology.

This blog should be used by customers who have spent huge sums of time and treasure developing custom applications that set them apart from competitors and optimally support their specific business processes. Yet when it comes to functionality and technology, these custom applications can quickly grow old and lose their value. So th ey need to find alternatives that leverage their investments.

Who is a candidate for Applicaiton Transformation?
Literally any IT organization running older legacy systems that are core to the business, not necessarily broken, but are on life support due to the software being in maintenance mode, a lack of skilled IT programming staff in the older language or an IT strategic direction is to move to a new , modern software development platform.

When is it appropriate?
That depends on the specific business need, for example:

Extending the application lifecycle
Transitioning to an SOA
New UI (User Interface) requirements - Web/JSF, Rich Client/Web 2.0
Improving agility and Increasing competiveness
Vanishing RPG developer skills - Consolidating development teams

Through maintenance, functional aging can be circumvented or at least significantly slowed. Most of the time, however, technical aging goes unnoticed until unreasonably high maintenance costs arise later on in the lifecycle; application agility declines; or the development platform begins dying a slow death. These are all indications that it's time to migrate an application to a new technological platform before its costs outweigh its benefits.

When they reach this point, companies often find themselves in a bind. They realize that it's not cost-effective to simply replace their legacy applications with modern standard software. And few can afford to continually rewrite all of their custom software to keep it up to date. Even if they can afford rewrites, companies realize that the money could be better spent on a more cost-effective approach to modernizing and migrating to the latest technical standards.

How do you approach application transformation? What's involved? Which technologies? Are there phases?
There are three main phases in any applicaiton transformation:
Discovery aNd Analysis(DNA)
Code Transformation
Implementation, Testing and Deployment

From a technology perspective the target of all Rational Application transformations is Rational Business Developer featuring EGL technology. Embedded in Eclipse, EGL offers a modern, service-oriented language for the efficient development of different application types, including Web programs, database applications, Web services, and batch and high-performance servers for fast transaction processing. Thanks to the tightly knit integration in the IBM Rational tool chain, EGL development can be embedded in a professional development process or lifecycle -from requirements management to modeling and coding, to testing and deployment. EGL's ease of adoption helps facilitate the transformation of RPG applications. Because EGL is easy to learn, it enables RPG developers to transfer their valuable business know-how in just a fraction of the time it would take for those same developers to transfer to Java technology.

Where does it occur?
Some tasks can be performed off-site on secured servers - the initial DNA and actual code transformation. The actual code transformation is typically performed off-site on secured servers. An EGL Project or Projects would be delivered to the customer site for implementation and testing which can be performed by the application owner or a service provider. Other tasks must be performed on-site - Education & training, code remediation (if required), implementation and testing.

Who performs which tasks?
Depending on the legacy source code environment, IBM & IBM specific business partners will perform the analysis and code transformation. The code remediation (if required), implementation, testing and deployment can be performed by internal IT staff with or without assistance from IBM, IBM SI or IBM Business Partners.

None of this is trivial, but it is all doable. The best advice is to contact Ed Gondek at IBM Rational - egondek@us.ibm.com and start the discussion!

I am getting ready for RSDC 2008, where I will be showing off EGL Rich UI in the Rational Labs sessions at the exhibit floor, and presenting at session EM09. To organize my way around the conference, I wrote a conference scheduler with Joe Pluta, and together we showcase EGL being used end-to-end, starting at an IBM i box to WebSphere to a UI running on an iPhone.

See http://rsdc.plutabrothers.com:9081/RSDCScheduler/2008/Index



See you there...

Hi

I am the chief architect and inventor of the EGL programming language. I would like to use this blog to involve the community in issues that revolve around the language itself such as:

• Language design philosophy
• Who should use EGL and why
• Comparing EGL to other languages
• Language syntax and semantic issues
• Extending EGL
• Standards and open source efforts
• Relationship to the greater Model Driven Development approaches
• etc.

I fully expect the evolution of EGL to be heavily influenced by the larger community as we go forward. Thanks for visiting and I look forward to vibrant discussions (people do get animated when talking about programming languages ) in the coming weeks.

Tim W Wilson, STSM, EGL Chief Architect

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

As a a product manager, I’m often asked “what’s new or what’s coming?”., and the simple answer is : “Change” We have all heard the quote “Change is our friend”, although in many cases I’ve not been completely sure, but it is a fact: change is a trademark of the IT industry.

I started out as an IT professional developing CICS and COBOL applications. Even at that time change was underway… we were in the midst of changing from Macro to Command level CICS programming interfaces. That change was definitely good for both customers and IT. Customers got more, IT was able to deliver more easily.

Then came the client/server revolution. Certainly customers got beter ways to view and process - but it was unclear if IT was able to do more. I don’t think I would ever say that C and the Windows programming model and API’s were easy.

With the advent of the Web, it certainly was clear to me that users could get more information more readily to support better business decisions and business processes: all in all customers received lots more value. Phenomenal value. But it was also pretty clear that instead of doing more, with the proliferation of technical complexity , IT could be doing less. Not because IT staff wasn’t working harder –they were – but because of the growing number of artifacts, technologies,languages, and the fact that runtimes did less and code had to do more.

To compound the problem, as complexity grew, the economic climate and business demands increased the pressure on workers, who were expected to be more and more productive. On average between 3 and 6 percent more productive according to overall worker productivity economic estimates. I think you get the picture.

Then SOA and web services emerged. Really cool stuff that enabled transaction managers and platforms to seamlessly communicate. Again, customersgetting more. Like that. But some fairly good complexity built in as well : SOAP, XML, WSDL, WS-Security, WS-Transaction, WS splat, headers, payloads, and so forth…. Left me wondering why it all just couldn’t have been implemented in a simpler fashion.

Now it’s the time of Web 2 and Rich Internet Applications. With Web 2, we’re realizing the power of the Web by exponentially increasing the power the browser can deliver to the users. We’re also getting a simpler and cleaner programming model. Client side programming and application flow stays in the client tier, facilitated by client side scripting languages. Server side programming focuses on flows and processing of business logic and data. It’s clean, and separates concerns. The architect in me likes that. And customers that have standardized on business processing in J2EE, CICS, IMS and other transaction managers can continue leverage them for back-end (heck, whoever wanted those high valued business systems to be processing User Interfaces anyway?). Now we’ve certainly got something for the users with significant value , but what about IT?

That's where EGL comes in. It’s a simple common language for the various elements of the application. Both the UI as well as enabling integration – including Web Services – and all the way to back end business and data processing. EGL provides something for IT as well, it enable developers to deliver more with less effort, simplifying innovation.

I'm often asked what EGL stands for. Originally it stood for Enterprise Generation Language. And it does generate artifacts targeted at the various runtimes in modern applications. JavaScript, Java, COBOL, and SQL to name some of what’s generated. Similar in concept to the fact that Java generates bytecode, and COBOL generates assembler.

But most importantly it’s an Easy General Language. The idea here is that a standard language across application tiers makes developers more productive. And also hedges an organization's bets that the next great platform, runtime, language is coming. Let’s see – you ever hear that said about PHP, Groovy, etc. The point here is that EGL is an Extensible Generalized Language. Support for new runtimes, languages, frameworks and technologies continue to be added as needed. To net it out EGL applications are meant to be portable between runtimes and platforms, yet not be constrained by one specific architecture.

So does the world need another language? Whole heartedly I say yes. In fact we’ll see many many more new languages and runtimes over the next 20 years. What we don’t necessarily need is for IT to have to code in them all to accomplish a single business system. Think about the change from TV to HD. You get a converter box – everything just works.

Finally, I’m asked will EGL be a standard. If a technology having a set of processes, API's, extension points managed by an open community can be considered a "standard" then the answer is absolutely! The community is this one, the EGL community. We’ll shortly be implementing a process, accessible on this site, where all members of the community will be able to participate in the development and vision of the language. So you’ve heard it here first. The current target for the establishment of this process is late 2008, after the next major release of EGL and RBD.

I encourage everyone to become an active member of this growing community, so hit the EGL café “JOIN” button and let's talk EGL!