All my bags are packed, I'm ready to go
I'm standin' here outside your door
I hate to wake you up to say goodbye
—"Leaving on a Jet Plane"
     Written by John Denver
     Originally recorded by Peter, Paul and Mary
     Sung by Chantal Kreviazuk

You know me, always trying to find quotes that really fit. Well, this song is appropriate to this article for a number of reasons. First, it's both old and new. The original was recorded in 1967, and it's been re-recorded dozens of times over the years. Each time, it gets a little something new added. Second, it's highly versatile. Versions range from the Peter, Paul and Mary song that most of us probably know to the very hip punk version by Me First and the Gimme Gimmes. And it seems it can just keep being used in new ways; my favorite is the Chantal Kreviazuk version from the movie Armageddon, but covers range from the aforementioned punk version to Arthur Fiedler and the Boston Pops. And finally, the song can be both beautifully delivered (e.g., Chantal's version) and horribly misused (let's just say that John Denver probably should have just left this song to others).

OK, you get the point. So where am I going with this? Well, I mentioned in my recent iApplication Developer article that I had created a new use for Asynchronous JavaScript and XML (AJAX), which is itself simply a "cover" of an older technology, XMLHttpRequest. AJAX is a wonderful technology that's incredibly popular today and being used in many ways—some good, some not so good. In this article, I'm going to present that new architecture in detail, and deftly switching metaphors, I'll show you why it could easily be the next major technological tool in your Web application tool belt.

Fasten your safety belts, and make sure your tray tables are in their upright and locked position, because we're about to take off....

The Concept

In my last article, I explained the concept of an interactive portal. This is a little different than the typical "portal" as presented in many discussions of Web design. In the common parlance, a portal is really little more than a browser page with a bunch of separate small panes. Each pane is independent of the others, sort of like a mini-browser. Your standard sites like MSN and CNN are good examples of that type of portal. You'll have a pane for news and a pane for weather and a pane for stocks, but they don't interact.

This is a reasonable use of the browser, but it's really not what I consider the best use. Personally, I prefer a more robust interface in which everybody is talking to everybody else and I'm getting my data at the speed of light. Here's my example:

Figure 1: This is how a business application portal should work! (Click images to enlarge.)

I start with a customer list in the upper left corner. I click on that, and I see the customer information for that customer in the lower left and the order history in the upper right. I click on an order there, and BOOM! the order detail shows in the lower right panel.

AIRPort does just that...and so easily you'll wonder what all the fuss was about.

Wait, What's AIRPort Again?

I'm hurt! You don't remember what AIRPort stands for? Well, the acronym specifically stands for AJAX Integrated Responses for Portals, but I also tried to create an acronym that would allow you to remember it just for its own sake.

AIRPort is simple in concept. You create an HTML page with a number of small sections that you then fill with HTML that is dynamically created by AJAX requests. In keeping with the AIRPort theme, I've coined a number of terms that can help you keep all this straight. But before I reveal them, I want to review a couple of today's most popular interfaces: the portal and the workbench.

The Portal and The Workbench

No, this is not another chapter in the Chronicles of Narnia. Instead, it's a simple comparison of two interfaces. The first is the standard portal interface. We see this on browsers all the time nowadays, even if we don't recognize it. The portal interface is generated in many ways, but the idea is always the same: a bunch of small windows that you can interact with.

Figure 2: This canned portal package is from a company called Zimbio.

The browser-based portal is typically a simple multi-framed application in which you can open or close the individual frames. In the original implementations, such activities required round trips to the server, but as browser code has gotten more sophisticated, you can typically do this interactively. Any information (such as positioning) that needs to be sent to the browser is done via an AJAX request, so it's transparent to the user.

Depending on the sophistication of the portal, you can move windows around, resize them, and even add or remove them as you see fit. The amount of desktop configuration available depends a lot upon the business purpose of the portal application; a news portal like CNN.com is a different thing than an order inquiry application.

Figure 3: With Eclipse/WDSC, you can switch between multiple stacked views in each panel.

The other type of interface is the workbench, a la Eclipse and WebSphere Development Studio Client for iSeries (WDSC). The workbench consists of multiple panels and each panel has one or more views. Note that Eclipse/WDSC doesn't really have a term "panel." It's my own term that simply stands for a rectangular part of the workbench that holds one or more views. There is typically a nice tab bar across the top of the panel that allows you to switch between the views. Figure 3 shows a workbench with three panels, each with multiple views. I circled the tab bars for each panel; these allow you to switch between the views in each panel. I find this interface incredibly powerful, especially when the different views interact with one another. For example, double-clicking on a source member in the Explorer view opens a new tab for that source in the editor panel. Similarly, clicking on a line in the Outline view positions the cursor to the matching line in the corresponding source view.

The Problem

The problem as I've seen it so far is that the portals require a lot of upfront configuration. In their eagerness to be a sort of one-size-fits-all interface, a lot of the application design issues have moved out of the hands of the application designer and into a separate "application administration" function. Typically, an entire infrastructure of code is required just to maintain the application.

Figure 4: This is the IBM WebSphere Portal administration interface.

Figure 4 displays the portal administration function in the IBM WebSphere Portal product. While its flexibility is unquestioned, I have a problem with the fact that you have to go through multiple administrative tasks just to create a simple Hello World. First, you have to write the portlet; then, you have to import/deploy the portlet; then, you have to configure the page to include the portlet; and then, you have to allow a user to see the page and the portlet. This all makes sense from the perspective of making sure that all application design and administration bases are covered. However, it tends to get in the way of the rapid design and development of an application.

AIRPort to the Rescue!

This is where AIRPort comes in. By taking advantage of AJAX and the Document Object Model (DOM) used by all professional browsers today, I was able to design a simple yet powerful interface to allow the rapid prototyping, development, and deployment of powerful interactive portal applications. This new architecture allows you to quickly create simple, focused chunks of business logic and easily pass data from one to the other, all without having to repaint the entire browser screen for each user interaction. The design is simple, elegant, and very fast.

As I mentioned earlier, I wanted to create a simple acronym that would stick in people's heads, hence the term AIRPort. And in keeping with that concept, I've also rebranded several of the UI components of a browser screen with "AIRPort-related" terminology as shown in Figure 5.

Figure 5: Terminals, gates, and planes: the primary objects of the AIRPort design.

The entire browser face is the terminal. That shouldn't be too terribly foreign; terminal is also a synonym for a computer monitor. The first step of an AIRPort deployment is to use some standard HTML to create sections of the terminal called "gates." Then, you write some simple JavaScript that fills those gates with data. (The AIRPort EAR file comes with a standard JavaScript file.) You do this by adding a "plane." This term stretches it a little: A plane is supposed to be roughly synonymous with a panel or a pane; it's the data that is inserted into the area on the screen defined by the gate.

I realize that using "cute" terms can sometimes detract from the overall professionalism of a concept, so feel free to use more normal terms. If, for example, you were trying to relate these terms to the terms you would use in Eclipse or WDSC, you might say this:

• Terminal = Perspective
• Gate = Panel
• Plane = View

In a standard portal, each panel has only one view; the only way you change the contents of the screen is by minimizing the views, so in that scenario, you would have one plane per gate. And in the interests of simplicity, the examples in this article currently stick with that one-plane-per-gate design.

Figure 6: Here's the AIRPort-enabled customer order inquiry...in Firefox!

By the way, when I say "simplicity," I mean it. I wrote the four-panel customer order inquiry portal that was outlined in Figure 1 in about an hour. The result is in Figure 6. Figure 7 shows the entire HTML required for the program. Figure 8 is the JavaServer Page (JSP) source for one panel:

Figure 7: This is a working AIRPort HTML file.

Figure 8: This is the entire listing for the customer list plane, Customers.jsp.

The HTML is almost negligible. It's a table with four cells, and each cell has a SPAN tag with the GATE attribute set to differentiate it from the others. The only non-HTML piece is the onload function of the BODY tag, which invokes the addPlane1 method, which is the JSP Model I version of the AIRPort UI mechanism. In it, you specify the exact URL that you wish to invoke to fill the gate. You'll notice that the invoked JSP, Customers.jsp, also includes some calls to addPlane1. In this case, a click on one line in the customer list will populate not one, but two separate gates. And that's really it. The work is done in the JavaScript file, airport.js, as well as in the COIApp class, but that's a little too detailed for this particular column.

The Two Primary Flavors

There are two primary implementation modes for AIRPort. The first is in keeping with the JSP Model I frameworks that many people are comfortable with; the primary interface is an HTML file that invokes JSPs to display the data. The customer order inquiry application uses this technique. You'll see from the source code that I've created sort of a hybrid approach; however, the first thing each JSP does is call an application method, which initializes the page. The application method keeps the state of the application and builds whatever Beans are needed for the page.

The other implementation is a standard JSP Model II implementation. I've created a servlet called Controller (sticking with those airport themes!) whose only purpose is to pass requests on to a session object called a Terminal. The Terminal object in turn passes those requests to an application object (which actually inherits from an interface called Application; I thought calling it a Plane was just a little too much). The application object is responsible for looking at request data, creating Beans, and finally forwarding to a JSP. I've included a second application, FlightStatus, to do that.

In both examples, I have no I/O. The "database," if you will, is simply a couple of hard-coded lists. But I think you can easily see from the design where the I/O operations would be written.

As Time Goes By

An initial question might be why I don't have all the goodies for being able to move gates around, minimize and maximize, add planes, and all that. Sure, it would be nice to be able to customize which panels go where so that users can create their own personalized interfaces. It would be nice to be able to maximize and minimize panes as needed and to be able to stack multiple data views in one pane, with an option to either tab through them or tile them as needed. But the problem with that stuff is the big, cumbersome administrative interface, which in turn makes it difficult to rapidly deploy business applications, and that is one of the main reasons you don't see a lot of portals in the SMB space. If you think about it, most business applications have a fixed interface, and in fact, they usually don't even have multiple panes. If AIRPort can quickly add the ability to provide multiple interactive panes, I think it can immediately be used to start building applications. That's another reason I want it to be open source; the project will add configuration capabilities as it goes along, but first we have to get some people using it. And that requires ease of implementation.

Another question might be this: Why, given my strong preference for JSP Model II, did I include the Model I approach? I did it for two reasons.

First, if you review the architecture, you'll see that there is nothing in the AIRPort Model I approach specific to JSP as opposed to RPG-CGI or PHP. In fact, you can easily use a combination of these techniques as needed (the only issue being sharing of persistent data). This is an absolutely unprecedented capability! It means I can use any Web application architecture I need for any part of the application! But to allow this flexibility, there can be no overarching architectural framework, so I need to stick with the less-sophisticated Model I approach in which all information for the request (including the target itself!) can be included in the UI. Thus, you'll notice that in my customer order inquiry, each JSP knows the names of the other JSPs that it triggers.

Second, most frameworks tend to be UI-centric. My next step with this architecture is to see how well it will interface with EGL, and I believe the JSP Model I framework will allow me to create a powerful system with little or no Java code. This is also why I kept any database I/O out of this version; it's my hope that I can soon have a template in which all I/O is done by RPG programs called directly from EGL—no Java needed.

However, I still included the AIRPort Model II framework because I believe the JSP Model II approach offers a number of benefits. It will be much easier, for example, to provide different versions of JSPs for different users, since the application specifies the names of the JSPs. This is extremely important for multi-tenant software, so it's a primary requirement for any implementation of Software as a Service (and one that few frameworks support cleanly).

In any event, the pre-release code is available for download from this Web site. It will soon be included in a SourceForge project under the Apache 2.0 license. I am including both an EAR file and a WAR file. Obviously, I can't test them on every configuration, but I've tested both the EAR and the WAR file in WDSC Version 6.0.1, running in both the WebSphere V6.0 and WebSphere V5.1 Express test environments. After you deploy the EAR/WAR file, you can launch the programs using the following URLs:

Flight Status: http://yourappserver/AirPort/airport/fs/FlightStatus.html
Customer Orders: http://yourappserver/AirPort/airport/coi/CustomerOrders.html

Hopefully, they're reasonably straightforward to use. More importantly, I want you to see how incredibly fast the interface is; responses are virtually instantaneous. As the AIRPort project team gets settled in (currently there are only two of us!), we'll include some better documentation with the SourceForge project, which you can find at the following URL:

http://sourceforge.net/projects/airport/

Please let me know what you think. If there's enough interest in the architecture, I can do a follow-up article with more details on both the JavaScript and the basic architecture, as well as whatever additional work we do on the configuration capabilities.

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been working in the field since the late 1970s and has made a career of extending the IBM midrange, starting back in the days of the IBM System/3. Joe has used WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. Joe is also the author of E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step, and is speaking at user groups around the country in May and June. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..