Thin-Client Computing, Coming Full Circle, Part 1

In the first article of this two-part series, the foundation of thin-client computing is explored, as well as a brief overview of its history, a look at the relationship of Microsoft and Citrix, and the basis of a thin-client computing solution.

• 09/01/1999

Thin-client computing brings to mind many clichés, such as "been there, done that;" "the more things change, the more they stay the same;" "what goes around, comes around;" and "back to the future" … or is it back to the past? This is because thin-client computing, in short, represents a return to the mainframe and time-sharing days of yore. In this first part of a two-part article, we’ll lay the foundation for thin-client computing, covering its history, the relationship of Microsoft and Citrix, and the basics of the solution.

If you are familiar with marketing of high-tech, then you may have read the book Crossing the Chasm by Geoffrey Moore. It is "must" reading for all marketers. The book’s major premise is that adoption (i.e., sales) of high-tech products follows the same acceptance curve. Innovators and early adopters, who constantly want the latest gizmo no matter what the cost or effort, are the first to buy the solution. Then sales dry up – the chasm – until adopted by the majority (pragmatic as well as conservative) buyers, followed eventually by the buying laggards. Individuals fall into one of these categories and, therefore, so do corporations’ purchasing behaviors. The book is devoted to how to cross that chasm.

One of the sidebars in Crossing the Chasm is a discussion on continuous and discontinuous innovations. Examples of continuous innovations are larger-capacity disk drives, fuel-efficient cars (as opposed to gas-guzzlers) and portable radios (versus floor standing or countertop). Each shares the (inherited) characteristics of its "parent." They are all well understood (such as how to set them up), have widespread use and have an existing infrastructure. Infrastructure refers to, in the examples, places to buy gas, places to get repairs done, many shows to listen to, etc. The consumer does not have to change the way things are done to take advantage of continuous innovations.

Examples of discontinuous innovations include the introduction of the first computer and PC, diesel- and propane-powered cars, the first radio and the first cellular telephone. These, too, share similar properties, such as they are not well understood, none of my friends own one of these yet, and they lack a support infrastructure. Discontinuous innovations can be difficult to describe and, even, name. They also require changes to the infrastructure and require significant changes by the consumer.

Owning a product that lacks a support infrastructure implies that the individual or company must themselves take on the tasks normally already provided, along with the implied risks. Examples include developing applications for the PC yourself (as opposed to having available and using commercially developed applications) planning where you will buy fuel for your vehicle, having available only a very limited number of radio stations and having a cellular telephone call drop its connection in the middle of a call.

On the other hand, with a discontinuous innovation, the benefits often outweigh the risks. Consider these examples: automating paper processes to increase productivity, reducing pollution, gaining bragging rights, and having instant and mobile communication, albeit with a limited audience.

Discontinuous innovations also catch people, even famous people, not in tune or asleep at the helm. Coming immediately to mind:

• Microsoft almost missing the Internet explosion and letting Netscape (temporarily) eat their lunch.

• Thomas Watson, former chairman of IBM, stating that there is a worldwide market for maybe five computers.

• Ken Olson, founder of Digital Equipment Corporation, stating that there is no reason anyone would want a computer in their home.

What in the world, you may ask, does all of this chasm and innovation stuff have to do with thin-client computing? Thin-client computing can be described in terms of these characteristics. For example, thin client is a throwback to a centralized computing model. Does that make thin client a continuous or discontinuous innovation?

Keep these ideas in mind as you read this article. You will gain some insight into how quickly thin client is or is not being adopted, as well as insight into your own and your organization’s motivations. We will revisit this topic at the end.

A common perception, or perhaps misperception, of thin-client computing is one of a sweeping, corporatewide replacement of desktop PCs with Windows-based "dumb" terminals, and of individuals struggling to keep their full-function PCs. Immediately what comes to mind are the many announcements concerning these dumb terminals. The promise was to reduce their selling price to under $500 and ultimately sound the death knell for desktop PCs.

Many companies tried to achieve this goal, including companies like Oracle, Sun and IBM. All of their client systems promised "thinner" client-side resource demands. The designs being proposed ranged from entirely new technologies, based on Java network computers (NCs), to pure display and user input devices.

The network computer phenomenon was largely a reaction to the high total cost of desktop ownership (read: desktop as PC). However, the promised price reduction of NCs was never quite enough. About that time, the price of PCs began to spiral downward as the major PC manufacturers fought to prevent market-share erosion by reducing prices. Perhaps, the final nail in the NC coffin resulted from lackluster system performance and a scarcity of popular applications written in Java.

These events created headlines and the perception that thin client is not ready for prime time, because the thin-client desktop was so closely linked to the thin-client computing model. Nonetheless, various studies state that around one-third of all organizations are using modern thin clients.

While wholesale replacement of desktops can certainly be done, thin-client computing, sometimes referred to as server-based or fat-server computing, is much more than that. Just to give a few examples, which we will revisit in part two, thin-client computing can be used to:

• Implement a single project using thin-client technology, to extend desktops’ lives by providing access to applications that cannot physically be run on the desktop due to disk, memory or processing speed requirements.

• Replace 3270-style, text-based terminals with Windows-graphics-capable terminals to provide access to e-mail, intranet, Windows applications, etc.

• Reduce network traffic to improve response times and postpone the need for extensive and expensive network upgrades.

• Ease remote-access-user dial-up-line bandwidth requirements to improve performance.

• Ease desktop management and application distribution issues.

With traditional client/server applications, the application executes on the client’s desktop and accesses files and databases on a server. A mainstream example is PeopleSoft. Similarly, Microsoft Office components (Word, Excel, etc.) execute on the client system and access files on the desktop or on a Microsoft Windows NT server. The clients in these environments are called "fat" clients, since all or the vast majority of the application logic resides on the client system.

Microsoft Windows NT Server, when operating in its traditional mode, functions as the server in a conventional client/server network. Without enhancement, NT Server could not operate in the following contrasting environment.

Consider a traditional mainframe. In this case, the entire application and database/files reside on the host, and the client systems accessing the application are dumb terminals or, nowadays, PCs running a dumb-terminal emulator. In today’s vernacular, these dumb terminals are called "thin" clients, since there is no, or very minimal, application logic residing on the client system. This, then, is the thin-client computing model.

To enable Windows NT Server to behave as a multi-user operating system – as if it were a timesharing mainframe – fundamental changes to the NT operating system were required.

In the beginning, there was Citrix only. Citrix Systems Inc., based in Fort Lauderdale, Fla., was founded in 1989, and provides system software for server-based computing. It is a publicly traded company, part of the Nasdaq-Amex Market Group "100 Index" and the Standard & Poor’s MidCap 400 Index in the Computers (Software and Services) Industry Group.

Microsoft licensed its Windows NT Server source code to Citrix, a very exclusive club. Citrix produced the WinFrame product. There is a popular misconception that once you install Windows NT, you then install the Citrix WinFrame product on top of NT. Actually, WinFrame is a complete replacement for the Windows NT operating system and is installed in place of NT. WinFrame allows an NT server to execute multiple instances of one or more applications directly on the server. Through this means, applications can be deployed, managed, supported and executed completely on the server.

When using WinFrame, multiple client systems connect to the multitasking, multi-user server executing the applications. Each connection creates a session on the server. The client systems act as display devices for the sessions. This allows older PCs to remain in place, executing only a very "thin" piece of client software that enables interaction with the server, while allowing them to continue to operate in their previous roles. Newly added clients can be thin, requiring only display, keyboard and network capability.

With traditional client/server, files, database records and even entire databases are transmitted over the network, from the server to the client system and back again after updating. In thin-client computing, both the application and database/files reside on the server. Thus, only display information, keystrokes, and mouse movements and clicks are transmitted over the network.

In a thin-client architecture, all information related to the user is stored on the server, including the user’s profile data, preferred desktop layout, application icons and so on. Because of this, users are no longer "chained" to a specific system, being able to access their desktop from any access portal (thin-client device).

While this brings us full circle, from mainframes to client/server systems and back to the mainframe model – something that has been available for years with mainframes – it really represents a new computing paradigm for Windows NT Server and PCs.

One day in late February 1997, in a major decision not untypical of Microsoft, Microsoft announced it had decided to include terminal server capability in Windows NT 4. On that day, Citrix stock crashed, dropping from $26 per share to $10. After protracted and persuasive discussions and arguments, the stock recovered in May that year when Citrix and Microsoft reached an agreement. As part of the agreement, Citrix licensed its multi-user kernel software technology to Microsoft.

The two companies defined how they would work together, and how and what portions of Citrix functionality would operate with planned Microsoft Windows NT server functionality – who does what to whom.

The Microsoft project was called Hydra, and its name evolved into the Microsoft Windows NT Server, Terminal Server Edition. It was released in June 1998. The corresponding Citrix project was called pICAsso, capitalizing on the ICA protocol name (defined later). Citrix officially released pICAsso as MetaFrame.

Prior to Microsoft entering the terminal server market, Citrix Systems was having great success. However, truly encompassing acceptance of the thin-client computing paradigm did not occur until Microsoft entered the market, throwing its considerable weight and market influence behind thin client. This action adds much-needed legitimacy to a fledgling multi-user NT market.

Terminal Server is a significant enhancement to Windows NT Server. In standard NT, the NT server is permitted only one interactive user, and the client on the desktop handles the actual user session. With Terminal Server, multiple users can share a single copy of each application, with each user having his or her own "virtual" and protected session. This is critically important, because it makes users’ experiences with Terminal Server appear the same as if they had their own local copy of the software.

Terminal Server provides Windows NT application access for Windows 3.1, Windows 95, Windows NT and DOS workstations. It has four pieces:

• The server side of Terminal Server is the host for multiple client sessions. Most Windows-based applications do not require modification to run on Terminal Server. The standard Windows NT management infrastructure and technologies can be used to manage the connected client systems.

• RDP is the remote desktop protocol that provides client-to-server communications.

• The Terminal Server Client is a piece of software that runs on a client system to handle the presentation layer and control the connection to the Terminal Server. It is analogous to traditional terminal emulation software used to connect PCs to mainframe systems. The client provides connection for PCs running Windows 95/98, Windows for Workgroups and Windows NT Workstation. The newer Windows-based terminals come equipped with the client embedded by the manufacturer.

• The standard Windows NT administration tools can be used, and Terminal Server supplements them with Terminal Server License Manager, Terminal Server Client Creator, Terminal Server Client Connection Configuration and Terminal Server Administration tools for managing the client sessions.

MetaFrame is closely integrated with Terminal Server and requires Terminal Server to operate. MetaFrame extends Terminal Server by providing:

• Load balancing between multiple servers in a farm (MetaFrame options)

• Simplified cluster management

• Performance analysis and tuning tools

• Fault tolerance, should a server fail

• Reduction in screen painting requirements

• Pre-configuration of the ICA client

• End-to-end encryption, called Secure ICA (MetaFrame options)

• Easy application "publishing"

• Integration of non-Windows applications

• Session shadowing to allow an administrator to track a user’s session for support, diagnosis and training

The Citrix WinFrame product was designed to operate as a Windows NT 3.5.1 operating system, and its support stops with that NT release level. Terminal Server and MetaFrame operate only with NT 4.0.

There are licensing differences between Terminal Server and MetaFrame. While MetaFrame is licensed with how many concurrent users will be using it (i.e., the maximum number of users that will simultaneously access services on the server), Terminal Server is licensed similar to Windows NT Server, requiring a license for each individual desktop.

One of the most important pieces of WinFrame/MetaFrame and Terminal Server is the mechanism they use to communicate from the server to the client, and vice versa. This is important from a connectivity issue (types of clients permitted), from a speed of communication perspective (protocol efficiency) and a communication medium.

The original WinFrame product communicates using the ICA (independent computing architecture) protocol. The ICA protocol allows for not only Windows PCs (Windows for Workgroups, Windows 95/98, Windows NT Workstation, Windows CE) to connect to a WinFrame or Terminal Server/MetaFrame server, but also Unix workstations, OS/2 and Apple Macintosh operating systems, Java-based systems, and older PCs running 16-bit Windows 3.x and DOS. From a hardware perspective, ICA supports 286, 386 and 486, and Pentium PCs, Windows-based terminals, network computers, wireless devices, ICA-based information appliances, Macintosh systems, UNIX-based computers and X-based devices.

ICA is also connection-ambivalent. It can operate over standard telephone lines, WAN links (T1, T3, 56Kb and X.25), broadband connections (ISDN, frame relay, ATM), wireless and Internet-style connections.

ICA is optimized for transmission of screen information and the user interactions of keystrokes and mouse movements and clicks between the server and client systems. ICA also uses compression over WAN and modem connections. These optimizations keep resource requirements to a minimum and allow ICA to be efficient even when running over something as slow as a 28.8 Kb modem. Furthermore, ICA supports industry-standard protocols such as TCP/IP, NetBIOS and IPX/SPX.

With the evolution of WinFrame into the Terminal Server and MetaFrame product set, the selection of protocols also changed. The protocol used by Microsoft for Terminal Server is RDP (remote desktop protocol), and Citrix MetaFrame continues to provide the ICA protocol. The RDP protocol allows Windows-based PCs to communicate with the server, including Windows 95/98, Windows NT Workstation and Windows for Workgroups.

ICA continues to provide connectivity to the Windows and non-Windows clients named previously. ICA and RDP can coexist on the same network and same server. They complement each other.

A thin-client architecture supported by Terminal Server and MetaFrame can have its quirks, although there aren’t many. Here are a few examples. Printing to a local printer works fine for a PC using the client software. However, to print to a printer attached to a Windows-based terminal or non-Windows client system requires MetaFrame. Similarly, cutting and pasting text between sessions requires MetaFrame. Only MetaFrame supports 16-bit wav audio. And there can be complexities associated with certain locally attached devices.

Thin-client computing can be used for a remote-access user who needs to access a client/server application across a dial-up line. Instead of records and entire databases being transferred across the line, which requires high bandwidth, only the user actions and display updates are transferred. This often results in the perception of a significant performance improvement for the end user.

By connecting to a thin-client server over even a slow modem, the remote thin-client user’s previous-generation desktop or laptop can achieve performance on the order of the latest and most powerful servers. This is because the application is actually executing on an enterprise-class NT server running Terminal Server software.

Due to the independent nature of laptops, which are often operated independently of a telephone or LAN connection, the advantages of thin-client computing must be examined closely to determine if using a thin-client architecture for every laptop application makes sense.

About the Author: Charlie Young is Director of U.S. Network Enable solution programs in the Global Customer Services (GCS) organization for Unisys. He can be reached at charlie.young@unisys.com.