20
Thu, Jun
3 New Articles

Client/Server Architecture

Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

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.

http://www.mcpressonline.com/articles/images/2002/041014%20-%20Client-Server%20ArchitectureV6--10250400.jpg

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.

http://www.mcpressonline.com/articles/images/2002/041014%20-%20Client-Server%20ArchitectureV6--10250401.jpg

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.

http://www.mcpressonline.com/articles/images/2002/041014%20-%20Client-Server%20ArchitectureV6--10250402.jpg

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 email address is being protected from spambots. You need JavaScript enabled to view it..

Joe Pluta

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been extending the IBM midrange since the days of the IBM System/3. Joe uses 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. He has written several books, including Developing Web 2.0 Applications with EGL for IBM i, E-Deployment: The Fastest Path to the Web, Eclipse: Step by Step, and WDSC: Step by Step. Joe performs onsite mentoring and speaks at user groups around the country. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..


MC Press books written by Joe Pluta available now on the MC Press Bookstore.

Developing Web 2.0 Applications with EGL for IBM i Developing Web 2.0 Applications with EGL for IBM i
Joe Pluta introduces you to EGL Rich UI and IBM’s Rational Developer for the IBM i platform.
List Price $39.95

Now On Sale

WDSC: Step by Step WDSC: Step by Step
Discover incredibly powerful WDSC with this easy-to-understand yet thorough introduction.
List Price $74.95

Now On Sale

Eclipse: Step by Step Eclipse: Step by Step
Quickly get up to speed and productivity using Eclipse.
List Price $59.00

Now On Sale

BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$0.00 Raised:
$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now!  Request Now.

  • SB HelpSystems ROBOT GenericForms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn: