Building your client-side

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Introduction

This chapter compares and contrasts traditional and Web-based client-server development. Traditional client-server here means following a non-Web development methodology where there is client development, server development, and possibly multiple application tiers. There are many choices, so many that making a rational decision may seem impossible.

Traditional Client-Server Approach

The “traditional” client-server application is database centric. Most client-server development tools are oriented in that direction. So, let’s start at the top. The basic client-server model can be depicted as:

This diagram is used as a starting point for discussions in this section.

Client-server development requires a great deal of upfront planning and analysis; even more than normal software development projects. There are many issues and decisions that must be made either prior to starting development or as part of the initial analysis phase. Several client issues should be addressed at this point, including:

Hardware platform
Implementation language
DLLs
Thin or fat
Deployment

The Client

The following illustration depicts the primary client issues to consider.

Hardware Platform

The hardware/software for the client is a chicken and egg question. In some cases, the software will determine the client hardware, and in others, the hardware selection influences the software. Two primary hardware considerations are processing power (MIPS) and network bandwidth.

In today’s computing world, consider a 100mz Pentium with 16MB of memory and ethernet a minimum Intel-based client configuration for normal users. Developers need high-end machines such as 200mz Pentium Pros with 32 or 64MB of memory, large (2GB+) hard drives, and large (17 inch or larger) monitors. Fast developer systems usually pay for themselves several times over during the course of a project. Recycling existing computers for clients is often done, especially at the start of a project. Resist the temptation to use 386-based PCs or 68k-based Macintoshes. In general, they just don’t have the necessary speed or hardware resources. Hindering users with slow client hardware will only make users frustrated and raise resistance level to the new system.

Several tools, such as PowerBuilder, are multi-platform and can work in mixed client environments. Multi-platform tools may allow the hardware decision to be driven by considerations other than just the hardware required by a particular software development package. The most common solution is simply selecting the client hardware based on the current organizational infrastructure. Organizations that use PCs will probably choose PC-based clients, while Macintosh- or workstation-based shops are likely to stick with the client hardware they know best.

Implementation Language

The choice of client implementation language or tool is likely to strongly influence hardware selection. It is also a relatively complex issue that must be weighed by the developer organization. Factors include:

Developer experience
Tool cost, both for developer license and training
Hardware
Software selected for other portions of the system
Whether the client will be thin or thick

Project vision also comes into play to a certain extent as well. Visual Basic might be chosen for a relatively small, minimal functionality system with limited growth potential. If you know up front that the client is a starting point that eventually will expand to every desktop in the organization, then a more robust and faster compiled language such as Delphi or Visual C++ might fill the bill in the long run better.

Developer experience should also enter into the language selection equation. Never choose a language that no developers have any experience with. Even one experienced developer will significantly shorten the learning curve for the whole staff. Plan on training when a new programming language or tool is used.

One last point on choosing a client implementation language; choosing a language or tool ties you to that vendor for the life of the project. Choosing Visual Basic means dealing, either directly or indirectly, with Microsoft. Choosing PowerBuilder ties you to Powersoft, etc.

DLLs

Dynamic Link Libraries (DLLs) issues only apply when the client is Windows (either Windows 3.1, Windows For Workgroups, Windows 95, or Windows NT). The proliferation of system DLLs over the past few years has made DLL selection an important issue in the client selection equation.

DLLs typically contain generic system libraries, such as the Visual Basic runtime module. Application programs generally distribute the DLLs they need to run. Frequently distributed DLLs include:

Visual Basic runtime
ODBC drivers
Winsock
Graphics conversion library
Application modules

The problem is one of configuration management and user support. Assume a user’s PC functions properly. Suppose a new package is loaded with a newer ODBC driver. The updated DLL overwrites the existing ODBC driver used by another program. Now, some of the old applications no longer work because of DLL differences. DLLs often are not completely backward compatible. Applications may work in conjunction with a DLL bug and often do not work when the bug is corrected in the driver. There also may be subtle differences between driver DLLs from different vendors which may also affect an application.

There is not a great deal that can be done about the multiple DLL version problem beyond being aware the potential for problems exists. The knowledge will provide some hope of identifying such a problem when it happens. Working with vendors is often necessary to solve DLL incompatibility problems. Keeping Windows applications up to date tends to minimize this type of problem.

Thin or Fat

The thin or fat client issue keeps surfacing. The decision must be made early on because it influences tool selection. The thinner the client, the less critical speed and memory considerations become. Rapid application development (RAD) is often traded for performance. Interpreted Visual Basic falls into this category of tool. (Visual Basic 5.0, with code compilation, should be available by the time this is published.)

The fatter the client, the more critical speed and memory usage become. The tradeoffs of RAD and performance swing in favor of performance. Client-server tools are evolving to provide both RAD and performance.

Factors that affect the thin versus fat client quesion include:

The client hardware; low-end client hardware points to thin client software
The network; a heavily loaded network favors the fat client

Whatever the client makeup, it is important to at least plan the approach up front so the client decisions can be factored into other development decisions.

Deployment

Thinking about application deployment may seem strange during initial planning, but is very important especially when a large number of users are involved:

How much installation is required?
How are updates handled?
Is there a standard client hardware configuration and what is it?
What is the standard client software configuration?
Are there known DLL incompatibilities?
Can client installation be staggered?

The list of development related questions goes on and on.

Automated client installation is practical. Many installation utilities are available today that can be used for any size application. Another possibility to consider is network installation. Fat clients may also require control or table files that require frequent update. Again, knowing the client makeup plan up front can prevent much pain later during application development.

Summary

The point is not necessarily to answer every development question up front. Some of the answers will be obvious; some are tough. Asking the question makes people think about the issues. Some issues about other project areas may have different solutions when deployment issues are considered than when the issues are totally ignored.

About the author:

Norman E. Smith has 25 years programming experience and is a senior systems analyst and programmer for Science Applications International Corp., in Oak Ridge, Tennessee. He is the author of the highly successful Practical Guide To SGML Filters and the Practical Guide to Intranet Client-Server Applications Using The Web (Wordware). Smith has been developing WWW applications since 1993 for SAI and has developed several Intranet applications using Web-based tools.