Client/server computing has simmered as a hot topic for a few years now. Clearly, the use of this technology has had mixed results. Although a few traditional RPG shops have jumped in and implemented client/server solutions, the vast majority of them have taken a wait-and-see approach. Like most topics in the realm of technology, the term client/server has numerous interpretations. For purposes of this article, client/server is defined as a software application that delivers a graphical, PC-based interface to data or logic on an AS/400. Much of the momentum behind this push for GUI applications has come from software users themselves. It is now common for typical corporate users to have more powerful PCs at home than they have at work, and they usually have more modern software, too. Driven by powerful interactive software such as Microsoft Office and the availability of increasingly dynamic Web content, the tremendous explosion of home computing has made the traditional AS/400 green-screen application seem prehistoric by comparison.

Unfortunately, few people outside the data center appreciate the fact that AS/400 applications never experience the common errors and downtime that plague the PC platform. Client/server solutions allow you to strike a bargain with these users. With client/server computing, they can have their intuitive point-and-click interface, and you can sleep well at night knowing you’ve secured your critical processes and data on your AS/400. This article explains the components that compose a client/server solution and provides steps to help traditional RPG shops on the path to client/server development.

Anatomy of a Client/Server Application

Client/server applications comprise three critical components: a front-end client, a back-end server, and hardware and software that connects the two.

The Front-end Client

The front-end client is the component of client/server computing that causes the highest level of anxiety for the traditional AS/400 professional. Clearly, the client side of development, which in most cases means learning a graphical, PC-based language,

presents new and sometimes painful challenges. For most AS/400 veterans, the idea of learning a whole new development language can seem overwhelming.

The Back-end Server

How important is a slick front-end if your organization’s data and business processes aren’t safe and secure? As an AS/400 shop, you already have a safe and reliable environment for your data and processes, so you have no reason to change your back-end processing and put your organization at risk. To design an effective client/server application, edits that protect the rules of your business should remain on the AS/400. If you limit your PC client applications to user presentation, which they do best, your organization will feel more secure about pursuing client/server solutions.

The Connection

How the front-end client works with the back-end server is especially critical in client/server applications. Because this conduit for your application must not cause a bottleneck in the flow of information between client and server, you should consider numerous options when selecting a connectivity method. A poor choice of connectivity methods can undermine your efforts by delivering poor performance to your users.

Six Steps to Client/Server

The traditional AS/400 development shop faces many challenges along the path to implementing client/server solutions. Consequently, some shops are more successful at implementing their solutions than are others. You can increase your chances of making a successful transition by following these six basic steps:
• Obtain senior management support.
• Do your homework.
• Get everyone involved.
• Develop standards.
• Focus on fundamentals.
• Start small.

Obtaining Senior Management Support

The first and most critical step toward client/server development has nothing to do with technology: You have to promote the idea of client/server development and sell it to corporate senior management, especially those with input into the prioritization of IS projects. In general, client/server projects take significantly more time to design, develop, and test than traditional green-screen projects. It is imperative to your success that senior management be continually prepared for the impact the learning curve has on programmer productivity.

Doing Your Homework

Just as you don’t build a house without detailed plans, it is equally important to have a detailed client/server plan. There are things to decide, such as what client language and connectivity method to use. These are major decisions that require a great deal of careful research and consideration. It may help you to talk with others who have already switched from traditional green-screen to client/server development. In addition, group gatherings such as COMMON and IBM technical conferences are ideal places to meet people who have also made that journey.

Choosing the right client language is probably the most difficult issue you face. Each language you consider has its proponents and its detractors. You can divide the most commonly used client languages into two broad categories: open languages and proprietary

Rapid Application Development (RAD) tools. Figure 1 lists a few of the more common options to consider.

Open languages can be described as languages designed to run on more than one type of platform. They have a recognized standard and are supported by more than one vendor. If your organization needs or wants to support clients running an operating system other than Windows, such as UNIX, an open language such as Java or C may be a good choice. Open languages afford you tremendous flexibility and protect your investment should your environment or requirements change, but expect the learning curve for these languages to be significant.

Unlike open languages, RAD tools are designed primarily for a specific platform or group of platforms. They consist of a programming language surrounded by a development environment supplied by a single vendor. Not surprisingly, the predominant proprietary RAD languages include Microsoft offerings such as Visual Basic and Visual J++. This means that the future of the tools rests with a single vendor. In this scenario, the tool is designed to enforce the provider’s corporate agenda. For example, tools like Visual Basic are designed around Microsoft standards such as ActiveX. However, the learning curve for RAD tools compares favorably with that of open languages, so if you are standardized on a Windows platform and desire a reduced learning curve, a RAD tool may be a good choice for you.

Getting Everyone Involved

To be successful in your client/server effort, you need the support and cooperation of your entire staff, but a question to consider is whether you have the staff necessary to learn the new concepts. If your budget allows it, you may want to hire a programmer with the experience you desire to help you get started. You especially want to consider potential programmers’ personalities because you will expect them to share their personal expertise with the other staff members.

Introducing a totally new technology into an existing IS shop presents interesting challenges. In a small- or medium-sized shop, one programmer typically leads the way. Although this is necessary to get the ball rolling and build momentum within the department, it can also lead to resource problems if the majority of your staff doesn’t come up to speed. Expect programmers on staff to react differently to new concepts. Some will get excited about the challenge and spend weekends and evenings learning on their own, but other programmers will resist jumping in for fear of failure. Murphy’s Law will ensure that if only one person on staff becomes your specialist, your systems will fail when that person is on vacation.

Staff training can be formal or informal. Training classes in the language you choose can be an effective way to get your staff started, but there is no substitute for hands- on practice. You may want to consider allocating some time out of the production schedule to assign specific practice exercises to each programmer.

Developing Standards

Programmers accustomed to green-screen development are simply not prepared to face the new visual design aspect that constitutes a major part of client/server front-end development. Nothing in their background has prepared them for this challenge. Graphical design requires numerous decisions concerning the size and placement of each screen element. In addition, fonts, colors, and other graphical elements further complicate your design effort. The point is that, if you allow each programmer to design without a set of guidelines, you will end up with a hodgepodge of inconsistent applications. Developing and enforcing standards can be difficult and time-consuming, but a good approach is to choose an interface you find effective, such as Windows 98, and use it as a pattern to emulate.

Focusing on Fundamentals

Where does all the time go? You’d be amazed at how much time you can spend tinkering with the design of a graphical front-end. This underscores the need to put extra emphasis on fundamental project management. Setting frequent project milestones with specific deadlines can assist you in keeping things from getting bogged down.

Because client/server applications have more points of potential failure than do typical green-screen applications, their testing requires additional attention and planning. Scripting a formal test plan for client/server projects is a good way to ensure the application is thoroughly tested.

When first presented with the challenge of client/server development, programmers naturally tend to focus on underlying technology. Details such as connectivity methods and visual appearance can dominate a programmer’s attention, but it is important not to overlook fundamentals such as identifying and analyzing the needs of the user. Users have little appreciation for underlying technology and have no problem discarding an application that doesn’t meet their basic needs, regardless of how attractive it looks.

Starting Small

Do you remember the first program you wrote on the AS/400 in RPG or COBOL? It was probably just a simple report or a few lines of maintenance to get your feet wet but not overwhelm you. It is equally important to bring along your programmers’ client/server skills slowly. Too many shops wait until a large, mission-critical project builds momentum within the organization for their programmers to learn client/server skills. They start with a huge budget, a tight deadline, and no clue where to begin. This is a recipe for disaster. Having each programmer create simple programs, such as file transfer utilities or data reports, allows them to develop their skills on harmless yet useful applications. It is important to start developing your staff’s skills now, before the organization clamors for a mission-critical client/server application.

The Payoff

With all the cautionary words I’ve used in this article, you may wonder whether moving to client/server development is a risk worth taking. If implemented slowly as part of a well- researched plan, client/server development can revolutionize your department. The bottom line is that you can greatly expand the services your department can offer, making you all the more valuable to your organization.

Open Programming Languages Rapid Application Development

(RAD) Tools

C Visual Basic

C++ Visual J++

Java Powerbuilder

Delphi

Figure 1: These are some of the most common open languages and RAD tools