Client/server is commonly defined as a little box (the client) and a bigger box (the server) mysteriously working together via some sort of communications link. In reality, client/server has nothing to do with boxes-a fine client/server application can take place on one machine. Further, the distinction between client and server becomes blurred when each component makes requests of the other. Which is the client, and which is the server?

Client/server components are independent of the hardware on which they run. The big box isn't necessarily the server, and the little box isn't necessarily the client. Each component in the cooperative client/server effort is placed on the system where it makes the most sense. The design process should be unencumbered by hardware restrictions. True, you have to work with the hardware you have, but don't let the idea of big and little boxes restrict your client/server design.

The term client represents the program that interacts with the user and makes most of the requests for data and processing from another component. The term server represents the programs that enforce the rules of business and fill requests for the client.

Client/server applications are designed around generally accepted techniques called models (conceptual design ideals to be used as examples).

The logical participants in client/server applications are called tiers. The user's interface with the application is a tier, as is the server's database capability. Tiers are independent of the hardware scheme. You can have one, two, or even three tiers of a client/server application on one computer.

The two-tier client/server model uses two components: the database tier and the user interface tier. The database tier is a database server. The AS/400's ability to deliver data to an application by way of physicals, logicals, joins, selects, and omits qualifies it as a database server or tier. The user interface tier (the program running at the client) does all of the data formatting, user input editing, and business logic and transaction processing.

Although widely used, the two-tier model is inadequate for most business applications. Placing all processing responsibility on the client requires excessive PC programming, and there is no component in place to enforce the rules of business.

What are the rules of business? They are those rules that are particular to your company's day-today operations. For example, suppose that a rule of business within your company states that each invoice must have at least one line item. You can't have an invoice without a line item, so if you delete the last line item on an invoice, the invoice itself must be deleted.

The three-tier model for developing a client/server application is a vast improvement over the two-tier model-and it actually makes application development easier.

The three-tier model places a third component-the business rules tier-between the user interface tier and the database tier. With the business rules tier, you have a place to put complex processing particular to your application. Beyond that, the business rules tier in an AS/400 client/server application can (and should) be written in your accustomed high-level AS/400 language (like RPG or COBOL) and run on the AS/400.

Once the three-tier client/server model is adopted, you can achieve optimal client/server performance, because the excess overhead inherent in the two-tier model has been removed. High efficiency is achieved, because the client/server link is being used to send and receive only significant data in a concise format. No waste.

As an additional benefit, adopting the three-tier client/server model with the business rules tier located on the AS/400 places the most difficult tasks on the most familiar ground. By doing this, you can develop applications faster, and your IS department benefits from not having to support so much unfamiliar code.

You should use a client language to interface with the user, to present a nice graphic interface, and to provide the ease of use that users expect from a Windows application. You don't have to perform complex processing across a dozen or so AS/400 files from a PC-you have a very capable AS/400 language for that.

The three-tier client/server model, as implemented on an AS/400, is shown in Figure 1. The database and business rules tiers reside on the AS/400. Notice that both the server program and the client program are written by the applications programmer. In this manner, optimal performance is achieved within a client/server relationship.

The three-tier model allows you to write both the client program and its transaction server program. The client program is written in a visual PC language, such as Microsoft's Visual Basic or Visual C++, and the server program is written in your shop's customary HLL, like RPG or COBOL. The client and server programs are connected by a general data transport mechanism, such as data queues or an APPC conversation. The data transport capability of data queues or an APPC conversation represents a high speed "shuttle" you can use to move data between client and server.

You can place data into the shuttle in any manner you like, because you control both ends of the transaction. Your AS/400 partner program can assemble the data elements from AS/400 files or other sources and concisely place only the important data into an efficiently sized data transport

compartment and, in a single transmission, completely fill the client's request.

For certain applications, client/server performance may be improved by sending blocks of records between client and server. For example, suppose your client application has requested sales history information. The request will be filled by multiple sets of sales history data elements. Your AS/400 partner program assembles these data elements from various files and other sources. Suppose the set of data elements is 250 bytes long. Instead of sending a single set per transmission in a 250-byte compartment, you can send, say, four sets in a 1,000-byte compartment, thereby reducing overall overhead.

With these techniques you can achieve subsecond response times within large client/server applications.

To get your arms around large, mission-critical client/server applications, treat the PC as a sophisticated display station, capable of advanced data presentation and editing and easy user input. Use the three-tier client/server model and write a server program on the AS/400 that is much like a traditional green-screen display file program.

Think of how you might develop the application if it were on the more familiar 5250 platform. What would the RPG/COBOL program do for the user? What would the program flow be? What rules of business would come into play? What would the green-screen interface look like? How many screens would you have? What would be on each screen? Answer these questions, using your experience as a programmer, and you may be able to feel your fingers touch on the far side of a large project.

Implementing the design becomes clearer when you know what is expected of each component. You know that the PC will have to do certain things and that the AS/400 is going to do the rest. The data is going to stay on the AS/400 and be served up to the PC in concise data element sets. The rules of business will be enforced by the AS/400 and presented to the user by the PC. IS management will remain the same as it is, with centralized data and security.

Performance within AS/400 client/server applications is determined largely by the design method used to build the application. Much of the uncertainty in choosing a client/server design model comes from unfamiliarity with the various methods available. Today, a half dozen or so client/server programming methods are in use-each with its own strengths and weaknesses. Of these, three are particularly popular-the ODBC driver, data queues, and the WinAPPC API. Other methods-such as Distributed Program Call (DPC), stored procedures, and DB/2 with triggers-are used to a lesser extent, while client/server programming using middleware is on the rise.

Which method best fits a given requirement? With ODBC, data queues, and the WinAPPC API, you can fill any client/server requirement you're likely to encounter. Each of these three, however, has inherent qualities that determine its performance potential and its viability for a particular application. The summary chart in Figure 2 shows the relative strengths and shortcomings of each.

Unfortunately, when many AS/400 programmers hear "client/server," they think of the ODBC driver or its replacement technology, OLE DB-and those technologies are, by nature, the poorest performers because they have to accommodate the unknown. They have to interpret and process

a request for data at the moment it's needed, with no foreknowledge of the database. When you make an SQL request of the ODBC driver, before the processing can take place, the database's attributes must be examined, and mechanisms to service the request must be established. Further, the processing itself is encumbered by the extra baggage attendant to a "do all" mechanism.

The AS/400 treats as a separate job each distinct file in independent use by a client application through an ODBC connection. For example, suppose you need to create a Microsoft Access report using the data from one AS/400 file. You can attach an AS/400 file to Access and produce the report easily and fairly reliably using ODBC/OLE DB. You can also attach an AS/400 file to a client program and process it as if it were a local file, using ODBC/OLE DB.

Any more than a few concurrent file attachments made this way will not be workable, though, because each open file connection is an active job within the AS/400 and, as such, consumes AS/400 resources. Imagine, for example, a production-quality application with 15 ODBC/OLE DB file connections in use at each of 10 client workstations. That's 150 active jobs on the AS/400.

And finally, ODBC/OLE DB is slow. Very slow.

Despite these shortcomings, ODBC/OLE DB is a good fit for low-volume, simple applications that use only a few AS/400 files. And it's the easiest client/server method to set up and use.

The data queue method of AS/400 client/server programming is one of the best performers available. Some accomplished client/server programmers consider data queues the preferred method for business-level client/server applications.

AS/400 client/server programming with data queues is best suited for asynchronous applications (applications in which the client and server do not directly communicate with each other). The client places entries on an AS/400 data queue, and they wait there until an AS/400 server program picks them up. The client can wait for a response to arrive on another data queue or continue with other things.

This asynchronous arrangement frees the client from the server. Take, for instance, a situation in which transactions are created at around-the-clock sales outlets. The transactions are placed on an AS/400 data queue for back-office processing by an AS/400 server program. However, the AS/400 server program is not available at night because of internal processing requirements and system backup, but the data queue is. Under this scenario, life goes on as usual for the user at the client, because there is no direct tie to an AS/400 server program. When the AS/400 server program starts in the morning, it processes the transactions waiting on the data queue.

For most business-level requirements, data queues offer enough functionality, flexibility, and performance.

The WinAPPC API offers the ultimate in reliability, flexibility, and performance. Why? Because all other forms of data communications and cooperative processing between client and server are implementations of APPC programming. For instance, the ODBC driver is really two APPC programs-one on the PC and one on the AS/400-that communicate and pass data over an APPC session. APPC is the programming convention and verb standard used over SNA links (including SNA over TCP/IP connections.)

Further, you can maintain total control over the mechanism of the router itself. For example, you can establish an application that transfers a block of records to the PC and then requests a confirmation that all data in the block was received correctly. Similarly, you can control the various states that the router can be in.

Since all other forms of communication over a Client Access/NetSoft/RUMBA router are implementations of APPC, raw APPC programming will produce the best performance. You can tailor the factors that determine throughput in a client/server application and render optimum performance. (See the OS/400 APPC Programming and the ICF Programmer's Guide for more information on APPC programming.) With the WinAPPC API, it's not unusual to experience client/server performance at a level with green-screen applications.

Use of APPC programming between client and server implies that the two will be in direct, dependent, and constant contact. In other words, the client program must be able to contact the server program in order for the application to run. This sort of synchronized relationship is well- suited for real-time applications that require interrogatory access to the AS/400's data.

For example, consider an order entry application that requires up-to-the-minute, quantity-on- hand information. Customer, order, credit, and inventory information must be available. Inventory quantities must be updated from sales and receiving in real-time in a central database. Further, an application that interacts with customers like this requires subsecond response time.

In this situation, the client/server application must maintain constant contact between client and server, much like in a display file program. The application would be an AS/400 server program that can collect data from 20 or 30 files and render a logical data element set. A client/server application built on APPC programming is best suited to this situation.

Of course, alternatives to these three client/server methods exist. You could use any of the following methods:

o Run an SQL stored procedure on the AS/400 to collect data from multiple sources and send it back to the PC.

o Build an AS/400 transaction file with triggers to invoke processing when an ODBC connection places a record in the file.

o Use the Distributed Program Call API to invoke a program on the AS/400 and pass data back and forth as a parameter.

o Connect a data queue to an AS/400 display file to funnel transactions or updates to standard AS/400 processing mechanisms (like an automatically updated reservation display).

o Buy third-party "middleware" to facilitate the transaction passing process. Several products are available, including IBM's Lightning SDK.

If you have a particular circumstance to be considered, one of these methods may be better suited to you than ODBC/OLE DB, data queues, or APPC. If you are already familiar with SQL, you may want to explore the stored procedures approach. If you are a strong PC programmer and don't pale in the face of complex memory handling and locking, you may do well with the

Distributed Program Call API. If you'd rather not get involved in client/server at its lowest level, look into the line of middleware products available. These utilities generally include a communications gateway that hides complex layers of interaction and a code generator or ActiveX controls that work with the gateway.

Further, the relative performance merits of one method as compared to another may not be as important as how well a particular tool fits into your existing programming environment. The best method may be the one that you can implement and maintain most easily in your shop while providing adequate performance.

Chris Peters is co-owner of Evergreen Interactive Systems, a software development company specializing in AS/400 client/server applications. He is author of MC technical books AS/400 Client/Server Programming with Visual Basic 5.0 and Peer Networking on the AS/400. Chris also teaches AS/400 client/server programming with Visual Basic and Java.

In many AS/400 installations that have adopted client/server processing, the effort has been halfhearted. That is, client/server technology has been used only for simple and inconsequential "side" applications where there is little risk or for situations in which there is no other choice.

Sometimes, client/server applications are considered only for applications that never get out of the IS department-little utilities such as a programming request tracking system or a help desk application. Why is that? Why are AS/400 professionals unwilling to bet the farm on client/server? Because it's too much of a plunge. Too much new stuff. Too much technology. Too many mysteries.

An AS/400 client/server design worthy of taking on a mission-critical role within a business must be conceivable and manageable. It must fit within the bounds of existing IS development and support capability. And it must be worth the effort.

Often, it is felt that the company in general and the IS department in particular are best served by adopting an AS/400 client/server design in which the role of the client is restricted to user interface tasks:

o Providing an easy-to-use, Windows-compliant interface

o Performing front-end editing of user input

o Providing enhanced formatting of system data for display

o Interfacing with other Windows applications

Conspicuous in their absence are processes like the following:

o Interacting with the database

o Enforcing business rules

o Interfacing with other server applications

These processes belong on the AS/400.

The ambitious reader may think "Isn't this short-stepping the popular client/server conception that the AS/400 is like a giant NT server? Does this mean a change in the traditional roles of the AS/400 and AS/400 programmers?"

The fact that few AS/400 shops have gotten off the client/server dime is proof enough that the traditional role of the AS/400 has a secure future-running the business.

Within a real business, A/R is still A/R, A/P is still A/P, and G/L is still G/L. The business keeps running on the same rules and operations that it ran on before client/server. Client/server technology wasn't developed to fill some new or highly beneficial need. It was developed as an outgrowth of PC technology and effective marketing.

The goal of client/server programming is to provide users with the benefits of working on a PC while providing the company with the benefits of running on an AS/400. -CP

Figure 1: An AS/400 client/server application built on the three-tier model

Figure 2: The three most viable client/server methods

Chris Peters has 32 years of experience with IBM midrange and PC platforms. Chris is president of Evergreen Interactive Systems, a software development firm and creators of the iSeries Report Downloader. Chris is the author of i5/OS and Microsoft Office Integration Handbook, AS/400 TCP/IP Handbook, AS/400 Client/Server Programming with Visual Basic, and Peer Networking on the AS/400. He is also a nationally recognized seminar instructor and a lecturer in the Computer Science department at Eastern Washington University. Chris can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..

---

MC Press books written by Chris Peters available now on the MC Press Bookstore.

		i5/OS and Microsoft Office Integration Handbook Harness the power of Office while exploiting the i5/iSeries database. List Price $79.95 Now On Sale

Also Read

TD/OMS and Gravity “Milestone 1” Enhancements Streamline Efficiency and Advance Application Development Potential for Re...

Now Let’s Consider Vendor Maintenance

Know Where Your Maintenance Stands