The client in the client/server model is the desktop workstation. Any workstation that is used by a single user is a client. The same workstation, when shared simultaneously by multiple users, is a
server. An Apple Macintosh SE, an IBM PS/2 Model 30, an ALR 386/220, a Compaq SystemPro, an NCD X-Terminal, a Sun Sparcstation, a DECstation 5000—all are used somewhere as a client workstation. There is no specific technological characteristic of a
client.
During the past 10 years, workstation performance improved dramatically. For the same cost, workstation CPU performance increased by 50 times, main memory has increased by 25 times, and permanent disk storage has increased by 30 times. This growth in
power allows much more sophisticated applications to be run from the desktop.
Communications and network speeds have improved equally in the last 10 years. In 1984, the performance and reliability of remote file, database, and print services were inadequate to support business applications. With the advent of high-speed local
and wide area networks (LANs and WANs), networking protocols, digital switches, and fiber-optic cabling, both performance and reliability improved substantially. It is now practical to use these remote services as part of a critical business application.
The client workstation may use the DOS, Windows, Windows NT, OS/2, MacOS (also referred to as System 7), or UNIX operating system. The client workstation frequently provides personal productivity functions, such as word processing, which use only the
hardware and software resident right on the workstation. When the client workstation is connected to a LAN, it has access to the services provided by the network operating system (NOS) in addition to those provided by the client workstation. The
workstation may load software and save word-processed documents from a server and therefore use the file server functions provided through the NOS. It also can print to a remote printer through the NOS. The client workstation may be used as a terminal to
access applications resident on a host minicomputer or mainframe processor. This enables the single workstation to replace the terminal, as well as provide client workstation functionality.
In a client/server application, functions are provided by a combination of resources using both the client workstation processor and the server processor. For example, a database server provides data in response to an SQL request issued by the client
application. Local processing by the client might calculate the invoice amount and format the response to the workstation screen.
Client workstations can provide business functions using a mixture of personal productivity products in conjunction with a custom application. For example, a document created by a word processor can include input from a spreadsheet program and the
invoice data created by the client/server application. The capability to cut and paste input from several different sources is one of the most powerful aspects of a client workstation. It provides the end user with tools to create new
applications—without the need to go to professional programmers for assistance.
In the client/server model, the client is primarily a consumer of services provided by one or more server processors. The model provides a clear separation of functions based on the idea of servers acting as service providers responding to requests
from clients. It is important to understand that a workstation can operate as a client in some instances while acting as a server in other instances. For example, in a LAN Manager environment, a workstation might act as a client for one user while
simultaneously acting as a print server for many users. This chapter discusses the client functions.
The client almost always provides presentation services. User input and final output, if any, are presented at the client workstation. Current technology provides cost effective support for a graphical user interface (GUI). This book recommends that
all new applications, with direct interaction by a human, be developed using a GUI. The windowing environment enables the client user to be involved in several simultaneous sessions. Such functions as word processing, spreadsheet, e-mail, and presentation
graphics—in addition to the custom applications built by the organization—can be active simultaneously. Windows 3.x and Mac System 7 do not support true multitasking; thus, only one task at a time can safely be engaged in a communications
session. Windows NT, OS/2, and UNIX are preemptive multitasking operating systems and thus will support any number of active communications sessions.
Facilities such as Dynamic Data Exchange (DDE), Object Level Embedding (OLE), and Communicating Object Request Broker Architecture (CORBA), which are discussed later in this chapter, provide support for cut-and-paste operations between word processors,
databases, spreadsheets, and graphics in a windowing environment. Beyond this, a selectable set of tasks may be performed at the client. In fact, the client workstation can be both client and server when all information and logic pertinent to a request is
resident and operates within the client workstation.
Software to support specific functions—for example, field edits, con-text-sensitive help, navigation, training, personal data storage, and manipulation—frequently executes on the client workstation. All these functions use the GUI and
windowing functionality. Additional business logic for calculations, selection, and analysis can reside on the client workstation.
A client workstation uses a local operating system to host both basic services and the network operating system interfaces. This operating system may be the same or different from that of the server. Most personal computer users today use DOS or
Windows 3.x as their client operating system, because current uses are primarily personal productivity applications—not ones requiring a client/server.
Those users running client/server applications from DOS or Windows typically run only a single business process at a time. However, the demand to use these familiar operating systems is driving the development of client/server tools such as
PowerBuilder for Windows, and new multitasking versions of Windows (such as Windows NT, Windows 4—expected to be available in late 1994—and Cairo, expected in late 1995). Fortunately, the advent of products such as Digitalk's Parts and Parc
Place's Visual Works provide development tools that are equally happy running in the Windows 3.x or OS/2, UNIX, and Windows NT worlds.
Because UNIX and OS/2 have lacked the familiar personal productivity tools such as word processors, e-mail, spreadsheets, presentation graphics, and database management systems, DOS and Windows have become the client operating systems of choice. Until
recently, few personal productivity applications for OS/2 and UNIX were in place, and client/server requirements that dictate OS/2 and UNIX were not evident. Now, improvements in the capability of these operating systems to run personal productivity
applications, and increased user needs for high reliability or for multitasking has increased the popularity of OS/2, X-Terminals, and UNIX. Native execution of Windows 3.1 applications under Windows NT, OS/2, and many UNIX implementations offers the best
of all worlds for the desktop user: reliability and functionality.
The current availability of OS/2 Version 2.1, UNIX, and Windows NT with integrated support for DOS, Windows 3.x, and X-Windows—as well as support for multitasking in a reliable environment—is a continuing reason for making these the client
operating systems the choice for developing business critical client/server applications. As noted, the dramatic reduction in processor and D-RAM costs make the extra resources required for OS/2, UNIX, and Windows NT minimal. Finally, the software
licensing costs for OS/2 2.x, UNIX from Sun and USL are comparable to that for DOS and Windows 3.x.
UNIX supports many of the most familiar personal computer app-lications, such as Lotus 1-2-3, WordPerfect, and dBASE IV. This fact—coupled with the availability of low-cost, high-performance RISC processors—is making UNIX a strong contender
as a client for client/server applications. During 1994-1995, it is expected that multitasking desktops provided by Windows NT, Windows 4.x, UNIX, and OS/2 will become the operating systems of choice for clients in a client/server environment. Selection
between Windows versions, UNIX, and OS/2 will be made on the basis of cost performance rather than functionality. Previously purchased PC limitations will encourage many organizations to remain with Windows 4 and OS/2 rather than Windows NT or UNIX, which
might require new hardware acquisitions. OSF/1 (a commercial-grade UNIX) is now available for the Intel platform and is causing organizations to reexamine the use of UNIX on the PC. The current licensing costs for OS/2 may give OS/2 the edge unless OSF/1
costs are much less than current UNIX licenses.
The Common Open Software Environment (COSE) group of UNIX kernel vendors has agreed on a common set of API's for most UNIX services. This allows application developers to build one application for all platforms. This will serve to expand the number of
applications that will run across the various UNIX platforms. In turn, this will increase the use of UNIX on the desktop and subsequently reduce the per-seat cost.
Windows 3.x is by far the dominant GUI and even with its single tasking limitations, it is a leading client operating system candidate for client/server applications. Microsoft's Windows 4, the planned upgrade for Windows 3.x, is discussed more fully
in Appendix B. It will provide a client platform that can better use the capabilities of the new generation of Intel processors while continuing to provide the GUI and API's of Windows 3.x. This operating system is likely to gain a significant share of the
client user base in 1995. The complexity and resource requirements of Windows NT suggest it will not displace many Windows desktops prior to the availability of Windows 4.
In terms of known "wild cards" for the client OS, IBM and Apple have formed an alliance with Motorola to develop a new client operating system in a venture known now as Taligent. This new OS is based on AIX, OS/2, and Mac System 7. The result
should be a client platform with the ease of use interface of Mac System 7, and the functionality and connectivity of AIX and OS/2. (This subject is discussed more fully in Chapter 10.) This initiative will bear fruit during 1994 and will compete during
1995 for the role of preferred client platform. Microsoft's competitor in this market, currently code named Cairo, will reach the market in late 1995 and will compete during 1996 for the multitasking desktop market.
With the uncertainty surrounding the operating system alternatives, it is important that all development be done with an SDE that isolates the operating system from the application. Then, if operating system changes are warranted the applications
should be able to port without any impact beyond recompilation.
The ideal client/server platform operates in an open systems environment using a requester-server discipline that is based on well-defined standards. This enables multiple hardware and software platforms to interact. When the standard requester-server
discipline is adhered to, servers may grow and change their operating system and hardware platforms without changing the client applications. Clients can be entry-level Intel 386SX machines or very powerful RISC-based workstations, and run the same
application issuing the same requests for service as long as the standard requester-server discipline is adhered to. Traditional host applications that use the client for presentation services operate only by sending and receiving a character data stream
to and from a server. All application logic resides on the server. This is the manner in which many organizations use workstation technology today. The expensive mainframe CPU is being used to handle functions that are much more economically provided by
the workstation.
First-generation client/server applications using software such as Easel enable the input and output data streams to be reformatted at the client without changes to the host applications. They use an API that defines the data stream format. Easel uses
the IBM-defined Extended High Level Language Application Program Interface (EHLLAPI). GUI front ends may add additional functionality, such as the capability to select items for input from a list, selectively use color, or merge other data into the
presentation without changing the host application.
An example of this form of client is an application developed for the emergency command and control services required by E911 dispatch applications. This computer application supports calls to the 911 emergency telephone number and dispatches fire,
police, ambulance, or emergency vehicles to an incident. This application traditionally has been implemented on a fault-tolerant minicomputer with access provided from a character mode dumb terminal. The information is displayed in list form, and the
operator can move the cursor to an item on the list for selection or rekey the data for input. Prior implementations of this application handled the address of the caller by displaying it on the screen as a text field.
In the client/server implementation of this system, the workstation user deals only with a GUI. The workstation plots this address onto a map that in turn displays the location of the fire. In addition, the locations of all fire stations and vehicles
are plotted on the map. The dispatch operator can see at a glance the entire status of fire support close to the fire. Previous implementations of this application displayed lists of optional fire vehicles. From this list, the operator keyed in a selected
vehicle. The GUI front end, however, enables the vehicles to be shown in a window and selected by using a mouse pointer. This not only reduces the cost of execution but can significantly reduce errors, increase productivity, and reduce stress experienced
by the dispatch operator.
GUIs enable users to be more productive with less training, because the interface is more intuitive. Several studies comparing the productivity and learning curve for users of GUI applications versus traditional character mode applications have
demonstrated improvements of greater than 200 percent.
The functionality of the client process can be further extended at the client by adding logic that is not implemented in the host server application. Local editing, automatic data entry, help capabilities, and other logic processes can be added in
front of the existing host server application. If many errors are detected at the client, or functions such as online help are completely off loaded, the workload of the host server decreases. There is an opportunity to provide extensive interactive help
and training integrated into a client/server application using only the services of the client workstation and NOS.
One example of this functionality is shown by an application developed for the state of Hawaii. To determine welfare eligibility, state employees conduct an extensive analysis of each applicant's personal situation. The process of capturing this
information is time-consuming and stressful for the case worker and the applicant. Hawaii addressed this requirement by using an "unattended" kiosk for the interview—an interactive video unit provides the questions and displays a set of
possible responses. Users enter responses on a touch screen and can respond to the questions at their own rate. The case worker is not tied up with the mechanics of filling out the questionnaire, and the state has the opportunity through the interactive
video to ensure that applicants are aware of all their rights and responsibilities. The case worker and applicant review the application after it is completed. The existing computer system captures and edits the data and performs the final eligibility
determination. A dramatically different and more effective user interface is provided while preserving much of the investment in existing computer systems.
Completion of multipart forms often involves redundant data entry into multiple computer systems or applications. Collecting this data at the source or into a common data entry function and distributing it to the other data entry functions can reduce
costs and errors. Ideally, the information is entered by the individual or process responsible for the data creation. This enables the individual with the knowledge to make corrections and to do so immediately. The workgroup LAN server captures the data
and stores it. When a business process defined to capture data from one copy of the form is invoked, the stored data is automatically merged into the form. This is updated, by the user, with additional data that is now available. In this manner, data is
keyed only once and every business process uses the same data. Information is made available immediately after capture and can be distributed electronically to all authorized users.
It is possible to make fundamental changes in the business process, using a Business Process Reengineering (BPR) methodology and client/server computing. One such example uses electronic imaging. Many firms have found that it pays to put a series of
steps that formerly involved different people handling each step, onto the shoulders of a single "case worker." One insurance company, for example, estimated that it took 22 days to approve a policy, during which time the papers were worked on
for only 17 minutes. The remainder of the time was spent shuffling papers between specialists—from credit-checkers to actuaries to salespeople and back. By enabling everyone in an organization to share information more or less instantly, new
technology highlights the fact that most insurance policies never need be seen by most of these specialists. As long as specialists can be consulted quickly when needed, the vast majority of policies can be handled by a single person. Mutual Benefit Life
used such a procedure to boost productivity among clerical staff by 60 percent.1
Another commonly used technique to leverage the power and ease of use of the workstation is provided by tools, such as Trinzic's Forest & Trees. These tools provide easy-to-use facilities to manipulate data either stored on the existing host
databases or downloaded to local servers. This technique of "data mining" through the use of powerful developer tools to provide rapid development of new management decision support functions, portends the future for systems development. Future
developers will be knowledge workers —technologists with an equally strong business understanding using tools that are intuitive and powerful. Data will be provided to the workstation user in a form consistent with his or her business
understanding.
Why is workstation technology so effective? It supports the new business paradigm of employee empowerment. It provides the windowing capabilities to simultaneously access and display all information necessary to complete the business process. The
capability of powerful workstation technology to recommend and make decisions based on historical precedent can dramatically reduce cost and improve service by shortening the decision-making cycle.
Client workstations request services from the attached server. Whether this server is in fact the same processor or a network processor, the application format of the request is the same. NOS software translates or adds the specifics required by the
targeted requester to the application request.
Interprocess communication (IPC) is the generic term used to describe communication between running processes. In the client/server model, these processes might be on the same computer, across the LAN, or across the WAN.
The most basic service provided by the NOS is redirection. This service intercepts client workstation operating system calls and redirects them to the server operating system. In this way, requests for disk directories, disk files, printers,
printer queues, serial devices, application programs, and named pipes are trapped by the redirection software and redirected (over the LAN) to the correct server location. It is still possible for some of these services to be provided by the client
workstation. The local disk drives may be labeled A: and C: and the remote drives labeled D:, E:, and F:.
How does redirection work?
Novell commercialized this redirector concept for the Intel and MS-DOS platforms, and it has been adopted by all NOS and UNIX network file system (NFS) vendors. The simplicity of executing standard calls to a virtual network of services is its main
advantage.
Over the years, good programmers have developed modular code using structured techniques and subroutine logic. Today, developers want subroutines to be stored as a named objects "somewhere" and made available to everyone with the right to use
them. Remote procedure calls (RPCs) provide this capability. RPCs standardize the way programmers must write calls, so that remote procedures can recognize and respond correctly.
If an application issues a functional request and this request is embedded in an RPC, the requested function can be located anywhere in the enterprise that the caller is authorized to access. The RPC facility provides for the invocation and execution
of requests from processors running different operating systems and using hardware platforms different from that of the caller. Many RPCs also provide data translation services. The call causes dynamic translation of data between processors with different
physical data storage formats. These standards are evolving and being adopted by the industry.
The NOS enables the client to generate print requests even when the printer is busy. These are redirected by the NOS redirector software and managed by the print server queue manager. The client workstation can view the status of the print queues at
any time. Many print servers notify the client workstation when the print request is completed. Fax services are made available in exactly the same manner as print servers, with the same requester server interface and notification made available.
A client workstation may have several windows open on-screen at any time. The capability to activate, view, move, size, or hide a particular window is provided by the window services of the client operating system. These services are essential in a
client/server implementation, because they interact with message services provided to notify the user of events that occur on a server. Application programs are written with no sensitivity to the windowing. Each application is written with the assumption
that it has a virtual screen. This virtual screen can be an arbitrary size and can even be larger than the physical screen.
The application, using GUI software, places data into the virtual screen, and the windowing services handle placement and manipulation of the application window. This greatly simplifies application development, because there is no need for the
developer to build or manage the windowing services. The client user is totally in control of his or her desktop and can give priority to the most important tasks at hand simply by positioning the window of interest to the "front and center." The
NOS provides software on the client workstation to manage the creation of pop-up windows that display alerts generated from remote servers. E-mail receipt, print complete, Fax available, and application termination are examples of alerts that might
generate a pop-up window to notify the client user.
Some applications operate well on workstations without any local disk storage; X-terminals and workstations used in secure locations are examples. The client workstation must provide sufficient software burned into erasable programmable read-only
memory (E-PROM) to start the initial program load (IPL)—that is, boot—process. E-PROM is included in all workstations to hold the Basic Input/Output System (BIOS) services. This mini-operating system is powerful enough to load the remote software
that provides the remaining services and applications functions to the client workstation or X-terminal.
Applications can be invoked from the client to execute remotely on a server. Backup services are an example of services that might be remotely invoked from a client workstation. Business functions such as downloading data from a host or checking a list
of stock prices might also be invoked locally to run remotely. Software is provided by the NOS to run on the client workstation to initiate these remote applications.
Mobile computing is increasingly being used to remain functional while out of the office. With appropriate architectural forethought, applications can be built to operate effectively from the office LAN or the remote laptop. Current technology supports
full-powered workstations with the capability for GUI applications consistent with the desktop implementation. The IPC protocol of choice for mobile access is TCP/IP based.
The operating system provides local functions such as copy, move, edit, compare, and help that execute on the client workstation.
Messages can be sent and received synchronously to or from the network. The message services provide the buffering, scheduling, and arbitration services to support this function.
The client workstation communicates with the network through a set of services and APIs that create, send, receive, and format network messages. These services provide support for communications protocols, such as NetBIOS, IPX, TCP/IP, APPC, Ethernet,
Token Ring, FDDI, X.25, and SNA. These are more fully described in Chapter 5, "Components of Client/Server Applications—Connectivity."
In addition to the remote execution services that the NOS provides, custom applications will use their own APIs embedded in an RPC to invoke specialized services from a remote server.
Database requests are made using the SQL syntax. SQL is an industry standard language supported by many vendors. Because the language uses a standard form, the same application may be run on multiple platforms. There are syntactical differences and
product extensions available from most vendors. These are provided to improve developer productivity and system performance and should be carefully evaluated to determine whether their uses are worth the incompatibility implied by using proprietary
components. Using unique features may prevent the use of another vendor's products in a larger or smaller site. Certain extensions, such as stored procedures, are evolving into de facto standards.
The use of stored procedures is often a way of avoiding programmer use of proprietary extensions needed for performance. A clear understanding, by the technical architects on the project, of where the standards are going is an important component of
the SDE standards for the project.
Most network interface cards (NICs) can generate alerts to signify detected errors and perhaps to signify messages sent and received. These alerts are valuable in remote LAN management to enable early detection of failures. Because many errors are
transient at first, simple remote detection may allow problems to be resolved before they become critical. Applications may also generate alerts to signify real or potential problems. Certain error conditions indicate that important procedures are not
being followed. Application program failure may occur because current versions of software are not being used.
Support for a remote client workstation may be greatly simplified if alerts are generated by the applications. This should be part of every standard SDE. Many alert situations can be generated automatically from standard code without the involvement of
the application developer. A more complete discussion of network management issues is included in the communications section of Chapter 5.
DDE is a feature of Windows 3.x and OS/2 Presentation Manager that enables users to pass data between applications from different vendors through support for common APIs. For example, a charting package can be linked to a database to provide the latest
chart data whenever the chart is referenced.
OLE is an extension to DDE that enables objects to be created with the object components software aware. Aware means that a reference to the object or one of its components automatically launches the appropriate software to manipulate the data.
For example, a document created with a word processor may include an image created by a graphics package. The image can be converted to the internal graphics form of the word processor, such as WPG form for WordPerfect. With OLE, the image can be included
in its original form within the document object; whenever the image is selected or highlighted, the graphics package will take control to manipulate the image. Activation of the software is totally transparent to the users as they navigate through the
document.
Currently with OLE, one software package accesses data created from another through the use of a viewer or launcher. These viewers and launchers must be custom built for every application. With the viewer, users can see data from one
software package while they are running another package. Launchers invoke the software package that created the data and thus provide the full functionality of the launched software.
Both these techniques require the user to be aware of the difference between data sources. DDE and OLE provide a substantial advantage: any DDE- or OLE-enabled application can use any software that supports these data interchange APIs. An e-mail
application will be able to attach any number of components into the mail object without the need to provide custom viewers or launchers.
Not all Windows applications support OLE, but Microsoft has released its OLE 2.0 software development kit (SDK). The toolkit greatly simplifies OLE integration into third-party, developed applications. Organizations wanting to create a consistent
desktop are beginning to use the OLE SDK as part of custom applications.
OLE 2.0 extends OLE capabilities to enable a group of data to be defined as an object and saved into a database. This object can then be dragged and dropped into other applications and edited without the need to switch back to the application which
created it. This provides a more seamless interface for the user. In OLE 1.x, double-clicking a Lotus 1-2-3 for Windows spreadsheet embedded in a Microsoft Word for Windows document launches 1-2-3 and opens the document in a 1-2-3 window. Under OLE 2.0,
the active window (Word's) menu and toolbar change to that of 1-2-3. The user deals only with the object, with no need to be aware of the multiple software being loaded.
CORBA is a specification from the Object Management Group (OMG), a UNIX vendor consortium. OLE focuses on data sharing between applications on a single desktop, and CORBA addresses cross-platform data transfer and the process of moving objects over
networks. CORBA support enables Windows and UNIX clients to share objects. A word processor operating on a Windows desktop can include graphics generated from a UNIX workstation.
It is important for application designers and developers to understand and remember that the user view of the system is through the client workstation. Whatever technological miracles are performed at the server, a poor design or implementation at the
client on the desktop still result in unfavorable user perception of the entire application!
1"Reinventing Companies," The Economist 321, NO. 7728 (October 12, 1991), pp. 67-68.