That's it. The gloves are off. It's time to make a stand here. No more beating around the bush or mollycoddling. I've spent enough time pussyfooting around the issue and using mealy-mouthed phrases like "in my opinion" and "for many applications" and "depending on your business goals." After hearing the political doublespeak that passes for debate at the highest level in this country, I suddenly realized that we have been doing the same thing in the iSeries community when we talk about architectures and application design. I reviewed a few conversations in forums and mailing lists, and it was clear that the facts were lost amid a blizzard of pseudo-scientific rhetoric, and this was why we had people--smart, seasoned people who you think would know better--actually wondering whether a Windows server farm might actually be a reasonable replacement for their iSeries.

No more. I'm putting an end to this nonsense here and now. In this article, I'm going to take a specific stand on a topic, and then I'm going to explain why we don't take stands anymore. I'm going to talk about client/server architecture--what it is, what it does, and how it is best implemented on the iSeries. Notice the word "best." There will be no fraternizing with the enemy, no politically correct phraseology. There are such things as right and wrong, and it's time we remembered that. Years ago, entire evenings could be spent arguing the merits of various architectures, and never once did we worry about things like "platform independence" and "open standards." Not that these things are bad in and of themselves, but we managed to get some pretty good code written without them.

So, in this article, I will...

• Explain the merits of client/server design
• Lay out the best architecture for iSeries business applications
• Explain what has happened in our online communities

Message-Based Client/Server Design

The design that is head and shoulders above any other in the world of multi-tiered, multi-language development is the message-based client/server design. The basic architecture is deceptively simple, yet variants exist that can embrace just about any business problem imaginable.

One of the things I love about client/server is that it really is very basic. In its simplest form, a client sends a message to a server and receives a message in return. Almost immediately, you begin to run into issues such as message size and structure. At the highest level, there are two basic designs: fixed-format and delimited. Neither one is necessarily simpler than the other. Electronic data interchange (EDI) messages are essentially very complex fixed-format messages, while comma-delimited files can be very simple. But in general, fixed-format messages require less processing than delimited messages.

Figure 1: This is a simple client/server design. (Click images to enlarge.)

This sort of client/server design shown in Figure 1 is so basic that it can be applied almost anywhere. A call to a Java method is a client/server relationship, as is a call to an RPG program. Anytime you encapsulate a bit of logic in an object that has no knowledge of the caller (except through parameters), you have created a client/server design.

The next variety of client/server involves queues. Queues allow nearly unlimited data to be passed between client and server. The queuing can be unidirectional--pass the request to the server via a parameter and receive the results via data queue--or bidirectional, when the data to the server is of arbitrary size. Queues are also used for stateless servers, an issue I'll address shortly.

Figure 2: In a queued client/server design, messages can be longer and more complex.

Finally, you can create a multiple-layer framework in which one tier invokes a server but tells it to send data to a different tier. Figure 3 shows a modified Model-View-Controller (MVC) design in which servers feed the view. To be more precise, the view would communicate with a model, and the model would read the response queue. But in the interest of simplicity, the illustration is fine.

Figure 3: In the more complex architectures, objects in one tier direct servers to send data to objects in other tiers.

In this last variant, you can see that the application is completely broken up into separate tiers. The server tier is dedicated to business logic and database access. In a perfect world, nothing gets into or out of the database except through those servers. But the world is rarely perfect, and Enterprise Information Management tools may make it necessary to allow less structured access to your database. While I accept the necessity of this sort of access for inquiries, I absolutely forbid update access. People who allow unfettered updates to their databases, even with constraints and triggers in place, are simply asking for trouble.

The controller decides what happens next. Technically, the design is rather complex. While the controller does direct the servers to send their results to the view, the completion status is returned to the controller, which uses that information to determine which panel to display (e.g., which JavaServer Page). This implies that the controller also sends some data directly to the view; namely, the ID of the next page to display. But despite those little issues, Figure 3 is reasonably accurate. The user action (e.g., data entered into fields or the ID of which button was pressed) is indeed sent to the controller, which uses that information to figure out the next step in the process.

Statefulness

Statefulness is an interesting issue. You can write your servers so that they are completely independent of the client and there is no knowledge of previous transactions in any session. These are stateless sessions, and their best claim to fame is that they scale relatively easily, because theoretically you don't care which machine any one transaction runs on, since any machines in a high availability set are supposed to be mirrors of one another.

Stateful sessions, however, have lots of benefits. First, much less data needs to be transmitted each time. Basic information such as user and company can be cached. This is especially helpful in database applications, since you can implement before and after image processing by caching the before image in the server. The beauty of a good design, though, is that it can support either stateful or stateless servers.

Languages

Which language is each bit written in? That depends, and in fact it's not even relevant to the design. A properly designed architecture is language agnostic; language is a business decision based on skill sets and performance. The platform independence folks need to understand that any architecture that is not language agnostic is not platform-independent; things like .NET and J2EE almost immediately lock you into some sort of platform or language decision, and that's just plain wrong.

In Figure 3, the server can be written in Java using JDBC, the controller can be written in PHP, and the client can be a Visual Basic thick client. I wouldn't ever write a system that way, but I could.

So Which Architecture Is the Best?

This last design technique is one that my clients are beginning to use with fantastic success. The controller and the server are both written in RPG, while the view is a simple servlet that converts EBCDIC data to Java objects and then displays a JSP. Servers are stateful, which means that getting the next page of data is as simple as performing a READ on the appropriate file. No constant mucking about with cursors and positioning. With this technique, users are seeing not only sub-second response time, but also response times indistinguishable from those of green-screens. There is very little logic in the view other than the conversion code, and that gets quickly optimized by the Just-In-Time (JIT) compiler of the Java Virtual Machine (JVM), so the overhead typical of Java applications is almost entirely negated.

Let nobody say that I am anti-Java! I love Java, properly used. I just think that RPG is a much better language for encoding the vagaries of business rules. And in fact, another group of folks who push the client/server envelope are indeed trying to develop a purely Java- and JDBC-based client/server environment, only in this case with the ability to plug in iSeries-specific optimizations when appropriate. This is the sort of design that the open standards folks don't get: With a properly designed business object class, you can bury your persistence layer in the implementation of the object and then optimize it as necessary. In any case, I'm looking forward to seeing how that works. I doubt it will be quite as fast as the RPG-dominated design in the previous paragraph, but it should still perform reasonably well.

One last issue before I close, and that's about message formats. I believe that your primary goal should be to have your messages as lean as possible. While XML is a nice tool, it's not the be all and end all of communications. In fact, the way some people use it, it's really not much more than EDI using tags. I shudder when I read about people who have decided it makes sense to store all their data as XML, avoiding relational databases altogether. At the same time, I recognize the fact that XML can be a great inter-platform mediator, so in that perfect world I talk about (but never seem to get to), I would like an XML-based handshake that could then quickly be negotiated to a faster fixed-format messaging system. But I'll talk about that in more detail another day. Today, I want to talk about why we don't dare actually make statements anymore, why common sense has gone out of vogue.

The Rise of Technological Thuggery

This overly litigious Politically Correct society has made us so frightened of getting someone angry that we no longer state facts as facts. Everything we say has to be couched in conditional phrases, lest we offend somebody else's sensibilities (regardless of the fact that they're spewing utter nonsense). This Caspar Milquetoast-esque behavior on the part of smart, well-meaning people has given rise to a new phenomenon, the Technological Thug. This is someone who knows enough buzzwords to drown out common sense in rhetoric and who isn't afraid to figuratively pound the desk in order to shout down any opposing viewpoint. These people absolutely adore certain types of online communities.

Online communities come in a wide variety. You can categorize them in many ways, but one of the easiest is by level of moderation. While the simple breakdown is moderated and unmoderated, it's a little more complex than that. The moderated forums have different levels of moderation, so you really see a spectrum of moderation, from the totally unmoderated to the heavily moderated. And the results are rather interesting.

Totally unmoderated forums such as Usenet tend to develop their own social structure in which no one person can really run amok. With no rules, an unmoderated forum is the Old West of the online world, and the quickest gun wins. Technological Thugs are usually louder than they are smart and tend not to last long in an unmoderated society. Pure volume eventually gets trashed by wit, and it's often not a pretty sight. Troll roadkill: not for the squeamish.

On the other end of the spectrum, you have heavily moderated forums. Heavily moderated communities live and die by the moderator. For example, David Gibbs' communities at www.midrange.com thrive because David brooks no nonsense and metes out his judgments with an even hand. No favoritism and little slack. Technological Thugs typically get shown the door rather quickly. That is not to say that all heavily moderated forums are adverse to Thuggery. In some forums, the moderators clearly play favorites, the rules are arbitrary and stupid, and Thugs are given free rein as long as they agree with the boss. Those forums generally die, and while the death can be slow and painful, heavily moderated Thug's Dens tend to be self-limiting.

Finally, some forums are in the middle, with some moderation but not a lot. Typically, they allow just about anything except for blatant personal attacks and obscene language. Those forums oddly enough are the ones that seem to prompt the most noise, primarily because they become the home of Technological Thugs. These trolls typically pick an untenable position and then shout it at the top of their lungs. They thrive in minimally moderated environments because the moderation usually serves only to discourage good people from taking them to task. As long as they don't post egregious personal attacks, they can generally get away with murder when it comes to obfuscation and technical misinformation.

How Do We Stop This?

Part of this is our own fault, since we as a community no longer seem to be willing to do the basic footwork of comparing different designs and seeing what actually works. Technology is moving so fast that we don't think we can spend the time required to perform feasibility studies and proofs of concept, yet if we don't, we are prey to the Thugs who merrily insist that "Java is faster than RPG" and "SQL performs as well as native I/O." There was a time when such nonsense would be countered with a simple "Prove it!" It seems, though, that we allow anyone to say anything these days, mostly because nobody has done the necessary work to refute even the most outrageous of claims.

However, I've found a simple tool to use against the Thugs: facts. Facts tend to shut up the Thugs quicker than anything. Here's a perfect example: Since I've started the IAAI and published my first native I/O vs. SQL benchmarks, not one person has insisted that SQL is faster than native I/O. Nobody has argued on my Web site, nobody has challenged one of my columns, nobody has accosted me in a mailing list. You see, once you have true facts, the soft answers like "when using set-based processing" or "I/O is primarily wait time" start to fall apart. Facts are great levelers: They play no favorites.

So it's up to us to start doing the kind of things we used to do: testing various techniques and determining the best one. And I am going to start today by going on record with my choice for the best architecture for iSeries business applications.

Conclusions

So what am I saying here? A couple of things. First, I am going on record today as saying that a client/server architecture, using an RPG controller and an RPG server framework, communicating with a simple JSP user interface, is the fastest and best-performing architecture for web-based iSeries applications. I challenge anyone to prove me wrong. Second, we need to stop the Technological Thugs, and the only way to do that is to pound them with facts. Whenever someone says something that just doesn't make sense, call them on it and make them back up their position. And if all else fails, come to the IAAI and help us build our list of benchmarks.

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. You can reach him at This e-mail address is being protected from spam bots, you need JavaScript enabled to view it .