Developing Web 2.0 Applications with EGL for IBM i

by Joe Pluta

Overview

Targeting Web 2.0 IT professionals and developers, this important resource provides essential information on IBM’s Enterprise Generation Language (EGL) and the exciting new EGL Rich UI for the IBM i platform. The first half explains how the EGL Rich UI takes advantage of the powerful EGL syntax to provide increased flexibility while designing complex interactive user interfaces from the ground up. This can allow for building Rich Internet Applications that take advantage of popular frameworks such as Dojo and services from Google, all integrated together with EGL Rich UI’s built-in widget library. Following is an exploration into harnessing IBM i, the new open and advanced business application server, through EGL’s ability to make simple connections from rich clients to back end business services.

Product Details

ISBN-13:	9781583476901
Publisher:	Mc Press
Publication date:	03/01/2012
Sold by:	Barnes & Noble
Format:	eBook
Pages:	200
File size:	7 MB

About the Author

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. and has been writing about the IBM midrange since IBM System/3. He has written extensively on EGL as a blogger on IBM's EGL site, the EGL Cafe, and is the author of several books, including E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step. He lives in Palatine, Illinois.

Read an Excerpt

Developing Web 2.0 Applications with EGL for IBM i

---

By Joe Pluta

MC Press

Copyright © 2009 Joe Pluta
All rights reserved.
ISBN: 978-1-58347-690-1

---

CHAPTER 1

The Architecture of Multi-tiered Applications

A multi-tiered application is an application that separates the user interface from the business logic. At its simplest, the application consists of two tiers, as shown in Figure 1.1.

There's nothing particularly complex in this design, which has been around since roughly the time the second computer was turned on. More realistically, multiple tiers came into vogue about the same time that end users started demanding access to their data in forms other than printed reports.

The computing world continues to produce ever-more-complex architectures: three-tiered, n-tiered, distributed services, grid computing, cloud computing, and so on. The dividing lines between the various tiers provide fodder for endless discussions, and each design has its merits. Some, however, simply aren't applicable to this discussion, which focuses on designing rich graphical applications where the majority of your business logic is in native IBM i languages such as RPG or COBOL.

Although the original midrange applications were of the service-bureau type — enter data, massage it, run reports, print them, and send them back to the client — some of the first online applications were on the lowly System/3. In fact, it was the System/3 Model 15D with CCP that spawned some of the earliest green-screen applications, certainly the first in the line of what would be called IBM midrange computers.

The 3270, the First Multi-tiered Application

Starting the discussion of multi-tiered architectures with a look at the oldest green-screen applications makes a lot of sense, since they are the direct predecessors to a lot of what you'll be looking at in this book. In fact, it's fair to say that the original green-screen display, the 3270, was one of the first multi-tiered applications.

I know you're probably thinking I'm off my rocker, but if you really analyze it, this seemingly simple interface, shown in Figure 1.2, was the definition of the multi-tiered application. Think about it: the program on the host didn't have to actually paint the entire 1,920-character display or the individual pixels on it. Instead, it sent the screen using a series of messages — requests, if you will. These requests were meta-commands and included actions such as setting the buffer address and starting a field. It was entirely up to the 3270 terminal to manage all of those requests and create an interface for the end user.

The 3270 display station actually did quite a bit more. To reduce the traffic back and forth between the display and the host, the 3270 was tasked with keeping track of modified data, allowing access via command keys, and even providing basic editing and keystroke control. It was actually a pretty powerful computer in its own right, especially given the state of the microprocessor at that time. It did exactly what needed to be done: make it easy for users to enter data, while freeing up expensive CPU cycles on the host. Remember that concept; it's going to come up over and over again through this book.

The 5250

Those of us in the midrange marketplace are more familiar with the 3270's younger cousin, the 5250. While similar to the 3270, the 5250 was incompatible with it. That's another thing to keep in mind: the 3270 and the 5250 were both green-screen, block-oriented protocols, but you couldn't attach a 3270 terminal to a host that expected a 5250 device, since the message protocol between the two was quite different.

In the long run, the most important and enduring part of the architecture is the protocol. Think about it: IBM i developers are still writing applications for the 5250 protocol in shops where a physical 5250 device hasn't existed for years, if ever. Emulators such as iSeries Access or TN5250J (the open-source Java 5250 client) act as the client device, something they can do because they are written to respect the 5250 protocol. On the other end of the wire, programs can be written without regard to whether the device is an antique 5250, a modernized version, or an emulator running on Windows, Linux, or even a handheld. The important point, shown in Figure 1.3, is that protocol is king.

5250 Emulation

Today, of course, the old 5250 terminal after which the protocol is named is long gone, and even those monitors that emulate the 5250 are few and far between. Except in extreme environments such as factory floors, it's simply easier to have a cheap PC than a 5250 terminal. In most cases, then, we're talking about a PC emulator package, with an architecture something like Figure 1.4.

The environment in Figure 1.4 is the one targeted in this book because, let's face it, if you have nothing but 5250 terminals in your shop, there's little you can do in the way of application modernization. Well, that's not strictly true. Things like standardizing screen layouts, using colors correctly, and re-architecting your applications to use advanced RPG features are available to you, even in the traditional green screen. For the type of UI modernization handled in this book, though, you need to be on a PC.

Screen Scrapers

I have another reason for taking you down this path; it's to address one of the oldest versions of application modernization for the 5250 environment, the screen scraper. As you can see in Figure 1.5, the idea of a screen scraper is relatively simple: put a graphical wrapper around the 5250 protocol.

Screen scraping can be done in a number of ways, from a simple ad hoc reformatting to a more customized approach that "mashes" screens together and performs the navigation between screens under the cover. In the end, however, you still have the same limitation: the 5250 data stream. As long as your program thinks it is talking to a 5250 device, the application has inherent limitations. You need to break out of that 24-by-80 box to get to the next level of application design.

The Thick Client

Another early attempt at multi-tiered applications was the thick client. I did a lot of work with this particular paradigm back in the 1980s and early 1990s, when the PC was first introduced. Whether the operating system was Windows or OS/2, the idea was the same: create a graphical application that ran on the workstation and communicated with the host, as shown in Figure 1.6.

Thick-client applications were distinguished by the fact that the code that ran on the PC contained business logic, or at the very least was so tied to the business logic that when that logic changed, the client code changed as well. One reason for this tight binding was that the protocol between the two was very specific to the application. In fact, back in those days, a significant part of the application-development process was simply designing the protocol to be shared between the two tiers. Even a modestly sized application requires dozens, if not hundreds, of specific message formats.

The other aspect of these applications was that the GUI programming was grueling. Developers had to design each window and widget, and often had to use very primitive APIs to build them. A good multi-tiered developer became something of a wizard at the complex, event-driven programming required to handle every keystroke and mouse movement in the brave new graphical world. When even the slightest change to the interface was needed, you had a multiple-phase project: change the business logic on the host or the workstation (depending on where it lay), change the messaging protocol, and finally rework the API.

The straw that broke the camel's back, though, was deployment. Once you made a change on the host, you needed to deploy the corresponding change on the workstation to every PC in your network. Trying to coordinate this in a small shop with a few users was bad enough; trying to implement the same change across multiple sites and time zones was a feat of staggering proportions, and one you wouldn't even attempt in today's anonymous Internet environment. Note that this particular pain point applies to some screen scrapers as well, generally those that have screen-specific custom code that runs on the PC and must be updated whenever a change is made to the underlying green-screen program.

The Thin Client (Browser)

Today, much of the work of creating graphical desktop applications has been removed by tooling, but the architecture is still rendered somewhat less effective by the issues of custom protocol and, more importantly, the redeployment of new code required whenever business rules change. Thick-client code is most effective for power users who need tight integration to desktop software already in place. Day-to-day business-application users, and particularly Internet users, don't need that level of integration, however. That explains the explosive rise of the browser-based thin-client application, shown in Figure 1.7.

As you can see in Figure 1.7, the browser-based architecture has two points of communication. The most important one is the communication between the browser and the web application server. This communication is done via HTML. It is the basis for what you could call "Web 1.0," although it was never really called that. Not until the advent of Web 2.0 (also known as "rich Internet applications" or "rich web clients") did it become clear that thin client was a generation unto itself.

I've omitted the rich web client communication from Figure 1.7 because I'll address it separately in a moment. I'm also purposely reducing the complexity of the thin-client landscape. For example, I'm assuming a web application server (something like WebSphere or Tomcat), and I'm including in the web application server's box the HTTP server that goes along with it (typically Apache, although others exist).

Other thin-client architectures exist; for example, scripting languages such as Perl or PHP run as interpreters and are directly invoked by the HTTP server. In fact, dozens of programming possibilities are available, including writing everything in RPG from the ground up. This book focuses specifically on the web application server route via EGL and RPG, all of which is bundled with the IBM i, and all of which can be programmed, debugged, and deployed using RDi-SOA.

JSP 2.0 and MVC

The JavaServer Pages (JSP) thin-client route has matured quite a bit over the 10 years or so that it's been available. JSP 2.0 fully embraced the model-view-controller (MVC) architecture. JSP is also quite friendly with JavaScript, and specifically with AJAX, making thin client a very flexible interface.

While I don't want to spend a lot of time on thin-client interfaces here, I think every green-screen programmer should know that JSP 2.0 is almost exactly equivalent to 5250, as shown in Figure 1.8. The page-oriented nature of the browser makes it a one-for-one replacement for just about any 5250 application, with the addition of fonts, colors, images, and some really nifty additional capabilities that can be applied through simple JavaScript. In fact, I'd say that 80 to 90 percent of traditional green-screen applications could be directly modeled to thin-client applications.

RDi-SOA provides all the tools to build those applications as fast, if not faster, than your old green-screen applications. Why is RDi-SOA faster? Because you have a drag-and-drop WYSIWYG designer. Try that with SDA!

Having a drag-and-drop WYSIWYG designer means you don't have to spend a ton of development time on the simple stuff: the file maintenance, data entry, and batch submission tasks that make up the backbone of any enterprise application suite. Let's be honest; no matter what you do, you're going to have to maintain your item master file, and that's not something that needs to have the latest Web 2.0 geegaws. Instead, you want to be able to define your data, drop it onto a screen, and call your business logic. With the thin-client EGL tooling in RDi-SOA, you can do just that.

Rich Client

What about those situations that do require a more graphical interface? That's where the rich client comes into play, shown in Figure 1.9.

As you view Figure 1.9, you might notice that I expanded the browser part, and removed the PC from the left side. I did this to make two things clear. First, the PC is no longer a given; browsers are becoming more and more ubiquitous, running in not only traditional PCs but also handheld devices, phones, game consoles, and more. The common denominator is no longer the PC or the operating system. Instead, it is the browser itself.

Rich Web Client Messaging

The second thing I want to make absolutely clear is that rich web clients require an entirely different architecture. In thin-client Web 1.0 applications, HTML pages are the primary communication vehicle. These pages might have snippets of embedded JavaScript, or even make use of an entire JavaScript framework to dynamically alter the page, but for the most part, the interface is still page-oriented. This, I think, is the primary downfall of the portal architecture; at the end of the day, most portal architectures combine chunks of HTML into a single page that is sent to the user. Inevitably, that leads to inefficiencies.

With rich Web 2.0 applications, the focus is entirely different. You don't send HTML to the browser, except perhaps at the very beginning of the application. Instead, you send what is effectively an entire application program, written in JavaScript. That program then runs inside the browser, on whatever client device the end user is using. The JavaScript application first dynamically creates all the widgets required for the application, and then begins communicating with the host using a semi-custom protocol to get dynamic data in response to user events.

I say "semi-custom" because the exchanges between the rich web client and the host typically contain application-specific data wrapped in some sort of standard protocol. In the earliest days of Web 2.0, most of this was done through Simple Object Access Protocol (SOAP) and its rather heavy XML wrappings. This architecture is still relatively well-suited to inter-company transactions such as those envisioned by the original designers of things like the Universal Description Discovery and Integration (UDDI) registry. However, the thinner requirements of multi-tiered applications weigh more toward the lightweight Representational State Transfer (REST) protocol, using JavaScript Object Notation (JSON) as the communication layer.

Without going into a lot of detail, a JSON or REST message contains a lot less metadata to describe the message. This makes sense in a multi-tiered application because the tier that executes in the browser originates on the host anyway, and so the host has complete control over both tiers. This is different from a distributed architecture, where completely independent applications on disparate machines must communicate with one another. In that case, the extra overhead and, perhaps more importantly, the application-independent validation provided by the XML standards can be invaluable in the development stages and in troubleshooting, especially the ability to use a schema to validate messages even before they are sent.

Summary

This first chapter reviewed various levels of application architecture, starting with the simplest two-tier design and working up to the latest Web 2.0 architecture. The most important point to take away from this chapter is that the Web 2.0 architecture is completely different from any of the server-side architectures, despite any superficial similarities. Even JSP Model 2, which affords a very interactive style of thin-client interface, is still modeled on a page-at-a-time request/response cycle, in which any change to the user interface requires a round trip to the host. In contrast, a Web 2.0 application can interact directly with the user without communicating with the host, and can even combine information from multiple host applications. It is this ability that drives the new generation of applications such as "dashboard mashups," applications that can fundamentally change the way users interact with business logic.

Since this book is designed to teach you to use RDi-SOA to develop these applications for the IBM i, the focus is on using EGL Rich UI technology for the user interface, EGL services technology for the middleware, and RPG business logic on the host. Technically, you could call this a three-tiered design. You'll see exactly what that means in the next chapter.

(Continues...)

---

Excerpted from Developing Web 2.0 Applications with EGL for IBM i by Joe Pluta. Copyright © 2009 Joe Pluta. Excerpted by permission of MC Press.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

---

Table of Contents

Contents

Title Page,
Copyright Page,
Dedication,
Acknowledgements,
Introduction,
Chapter 1 - The Architecture of Multi-tiered Applications,
Chapter 2 - Bridging the Tiers with IBM Rational and EGL,
Chapter 3 - Introducing the WYSIWYG Designer,
Chapter 4 - Establishing the Framework,
Chapter 5 - The Thin Client Comes Along for the Ride,
Chapter 6 - Enabling the "S" in "SOA",
Chapter 7 - Building an EGL Rich UI Application,
Chapter 8 - Implementing the Business Logic Tier,
Chapter 9 - Error Handling, Logging, and Debugging,
Chapter 10 - The Future of EGL Rich UI,