If you have you heard about Web 2.0, you're probably interested in learning more about this new technology. Lots of information is available on this subject. I found something titled Mastering Ajax, Part 2: Make asynchronous requests with JavaScript and Ajax that gives a nice description (thanks Brett McLaughlin):
|
When you hear the term Web 2.0, you should first ask, "What's Web 1.0?" Although you'll rarely hear Web 1.0, it is meant to refer to the traditional Web where you have a very distinct request and response model. For example, go to Amazon.com and click a button or enter a search term. A request is made to a server and then a response comes back to your browser. That request has a lot more than just a list of books and titles, though; it's actually another complete HTML page. As a result, you probably get some flashing or flickering as your Web browser's screen is redrawn with this new HTML page. In fact, you can clearly see the request and response, delineated by each new page you see The Web 2.0 dispenses with this very visible back-and-forth (to a large degree). As an example, visit a site like Google Maps or Flickr. On Google Maps, for example, you can drag the map around and zoom in and zoom out with very little redrawing. Of course, requests and responses do go on here, but all behind the scenes. As a user, the experience is much more pleasant and feels a lot like a desktop application. This new feel and paradigm is what you see when someone refers to Web 2.0. What you should care about then is how to make these new interactions possible. Obviously, you've still got to make requests and field responses, but it's the redrawing of the HTML for every request/response interaction that gives the perception of a slow, clunky Web interface. So clearly you need an approach that allows you to make requests and receive responses that include only the data you need, rather than an entire HTML page as well. The only time you want to get a whole new HTML page is when ... well ... when you want the user to see a new page. But most interactions add details or change body text or overlay data on the existing pages. In all of these cases, Ajax and a Web 2.0 approach make it possible to send and receive data without updating an entire HTML page. And to any frequent Web surfer, this ability will make your application feel faster, more responsive, and bring them back over and over again. |
The best way to understand what this new technology is all about is to go try Web sites that are using it. You might be surprised to see how the performance is typically much better and how it looks like you are using another interface rather than just a Web page.
The name “Web 2.0,” then, is a way to encompass a new level of existing technologies that improves the user interaction with the Web. Since Web 2.0 technology makes your Web site more attractive, adopting it could be considered a competitive advantage. All Web applications should consider applying Web 2.0 to keep users interested.
Existing languages like Java™ or COBOL are not enough to provide the required technology to write Web applications for Web 2.0. Of course, we all know that new technologies bring new challenges. Usually, we want to know:
- What is the learning curve?
- What is my productivity using this new technology?
- How much of the existing technology will change in the future?
Remember when Enterprise JavaBeans™ (EJB) came along? How much of EJB version 1.0 technology is still alive? You always face run risk of starting with a new technology that changes fast and end up with quickly outdated code.
- Will this technology survive in the next two years?
There is always the chance of adopting a technology that will go away. Remember Betamax vs. VHS, or more recently HD DVD vs. Blu-ray? What happened to users who bought the underdog technology? (Of course, both Betamax and VHS eventually became obsolete with the advent of digital technology, but I still have a lot of VHS tapes at home, as well players that use them -- but I’m not going to buy a new VCR.
- How easy will it be to maintain the code for the applications you write with the new technology?
Every organization probably find additional challenges of their own, but the universal question is: how can you make these challenges less painful.
EGL and Web 2.0 Enterprise Generation Language (EGL) is a new language that IBM® is adopting for a variety of applications. You can compare EGL to what COBOL did in the '60s: make it easy to code applications that were originally written in Assembler language.
By using this single language, business logic can be executed in diverse runtime environments, such as native COBOL on System z™, Java on WebSphere® Application Server, or even on System i™. The user interface can be executed as a rich client inside a Web browser using modern techniques, such as Ajax and other Web 2.0 features. Applications can access relational data from a server and match up the result in a browser in a unique and declarative approach.
The current version of EGL implements applications as Java or COBOL, but EGL will potentially be able to implement applications using other technologies, including Web 2.0. A technical preview of IBM Rational® EGL Rich Web Support is currently available on IBM alphaWorks, where you can download it and try it out right now.
EGL will help make Web 2.0 implementations easier and help resolve other issues mentioned above, like:
- Learning curve
EGL is easy to learn. Java and COBOL developers will see similarities in the language syntax. My experience is that developers can start coding EGL after a week of basic training.
One very important point about this: You only need to learn one language. EGL will be deployed as a Rich User Interface (Web 2.0), with the server code in Java, COBOL or Web services or REST services architecture. You will not need to understand each different implementation, such as CICS®, IMS™, Web services or JavaScript. For example, even if I don’t have any skills with JavaScript or Ajax, I can still write a simple Web application that will invoke Web services using Web 2.0 controls, using just EGL. Sounds easier already, doesn’t it?
- Productivity
Since EGL is a language based on frameworks and high-level specifications, it makes the language very productive with very good runtime performance. EGL will provide some Web 2.0 controls that are easily written with minimum lines of code, compared to Ajax or other implementations.
- Future changes
This is probably the most important challenge. I know customers who have developed very sophisticated applications using Java and EJB version 1.0 technology. They have experienced difficulties because they have had to migrate to newer EJB versions, since the code stopped working on modern application servers. It could have been even more difficult had there not been a migration path.
Since Web 2.0 is still evolving, there is a risk in implementing it using low level code, should Ajax and Web 2.0 become obsolete. When EGL produces the code, it will do so depending on the existing technology. The idea, then, is that users will not have to worry about the migration, since the language used will be EGL rather than the low level implemented code.
- Will Web 2.0 survive?
Who knows? But again, EGL addresses this. If the current Web 2.0 technology goes away, IBM will likely deploy the code using whatever existing technology is available. Since EGL is a language based on specifications, the implementation will be the existing technology.
You might now be asking: What if EGL itself goes away? Perhaps you see this as a risk also, but IBM has been providing migration paths for similar technologies for almost 30 years. For example, applications written with the old CSP (Cross System Product) language can be migrated to EGL following a migration path, so even those applications do not need to be rewritten. This is the consistent approach I have witnessed in my 35 of years working at IBM.
- Maintenance
This is one of the greatest advantages of using EGL for writing Web 2.0 applications over other existing languages. EGL is easy to maintain and very well structured. When Rational Business Developer and its wizards are used to produce EGL code, it does so in a consistent manner so that any programmer should be able to easily maintain code -- even if it was written by someone else. Also, you write less, so you have less code to maintain.
Example of an EGL and Web 2.0 implementation
Let’s look at some EGL examples that are available in the technical preview.
Figure 1, shows how EGL can write Web 2.0 controls. For example, changing the name to “Column number 0” is reflected in the new picture. Other controls can be changed in the same way. There is no need to code JavaScript to produce this, because all JavaScript is generated automatically, and a preview of your controls is displayed.
Figure 1. Dojo grid bindings offered by EGL Rich Use Interface
Using components like the one shown in Figure 1, you can easily create an application like the one shown in the Figure 2. In this example, which is all written with EGL, you can invoke Web services that were deployed in different locations using different operating systems. For example, the Mortgage Calculator function (on the right in the figure) invokes a Web service that was deployed onto a mainframe and runs using CICS Web services. Another function that performs the search invokes a Web service that is deployed on another server that requires a database retrieval.
Figure 2. Application example written with EGL Web 2.0
The service that maps the house location is provided by an external service provider using Google Maps. Figure 3 shows how this component is written with EGL.
Figure 3. Google Maps component written with EGL
For a live example of such an implementation, check out the conference scheduler for the Rational Software Development Conference 2008. This scheduler was written entirely in EGL and RPG accessing Web services deployed on System i.
I have heard this question many times. In fact, this question was asked by C++ and SmallTalk programmers when the new Java language came along. I also heard this question a lot in the '60s during the battle between Assembler and COBOL.
Why not continue with COBOL and Java? Because COBOL and Java do not have elements that help in the Web 2.0 world. And why not use Java only? This one is easy. Because Java does not help with writing Web 2.0 interfaces, you will need to learn new languages and technologies anyway. Since this is the case, why not just learn EGL?
Everything in life has advantages and disadvantages. We should never say no to a new technology like EGL without understanding it first. If we did, then languages like Java would never have happened and Assembler would still reign as the programming language of choice. When adopting a programming language, the most important thing to consider is the developer’s skills. It is typically more important for a commercial organization to maintain their developers’ business skills rather than having to constantly train them in new technologies. Developers skilled in EGL will be better able to implement new technologies without having to deal with their complexities. Furthermore, when Web 3.0 arises (yikes!), these developers might still be able to code in EGL, if it is improved and deployed as I expect it will be over time.
EGL and Web 2.0 technology are new and so they have long lives ahead of them. They are ready to be adopted and get to work on fast deployments. Are you?
Learn
-
Mastering Ajax, Part 2: Make asynchronous requests with JavaScript and Ajax
-
IBM Rational
Business Developer product information
-
IBM Rational
Developer for System i for SOA Construction product information
Get products and technologies
Discuss

Reginaldo W. Barosa is an IBM Executive IT Specialist. He provides sales support, helping customers with enterprise modernization solutions and development tools, such as Rational Developer for System z. Before joining IBM U.S. more than eight years ago, Reginaldo worked for 27 years for IBM Brazil. He has co-authored IBM Redbooks and has written two books, as well as other articles and tutorials for IBM developerWorks. He holds a degree in electrical engineering from Instituto Maua de Tecnologia, Sao Paulo, Brazil
Comments (Undergoing maintenance)





