|
|
The terminal server concept does not follow the usual approach to operating systems at Microsoft. It does not fit the notion of a “rich client” with local applications integrated into a network of high-performance servers that use a massive amount of resources. Neither does a terminal server match the typical environment of .NET- connected applications with components running on different platforms. On the other hand, the terminal server does support the concept of “server-based computing.” It is based on a centralized, well-equipped server—which we could call the host—which many users log on to simultaneously to work interactively with the applications installed on that server. All the application components run exclusively on the server. The server is accessed via the network from low-maintenance clients equipped with basic functions only. These clients are also called terminals, which is how the term terminal server came about. The clients merely provide visual access to applications and a means to interact with them by keyboard and mouse. Depending on the clients’ characteristics, additional input and output devices can be added.
If this brings the world of mainframe computers to mind, you are not far from the mark. The terminal-host concept is not new and is now enjoying a revival in the terminal server. The basic idea was simply set on a new, state-of-the-art foundation, thus enabling access to modern, graphics-oriented applications without the need for modifications.
Even if terms such as terminal and host are often associated with it, the terminal server remains a special variant of the pure client/server environment. In a client/server architecture, certain resource-intensive tasks such as user authentication, printing, e-mail administration, database operations, or applications execution are limited to the server (the supplier). The clients (the customers) are linked to the server and provide a conduit for requesting services from the server. As a result, network traffic is usually quite low compared to other types of architectures. However, the server often demands high-end processing power, hard-drive capacity, main memory, and data throughput.
There are different levels of client/server options. They vary in their handling of the distributed application and data management, which in turn affects the efficiency of the server or client.
Remote presentation Remote presentation corresponds to a thin client having little native intelligence that depends directly on its server. The server is responsible for running all applications and managing data, whereas the client handles display, keyboard and mouse connections. X terminals, “green terminals” on mainframe computers, or terminal server clients are examples of this type of client. You could also include a Web browser that displays HTML pages in this category because all the “intelligence” needed to create these pages resides on the Web server.
Distributed application The concept of a distributed application is realized in many network systems where the client needs a certain amount of native intelligence to optimize the processing of complex tasks. For instance, database requests are created on the client to be run on a database server. Seldom- used or computation-bound components of a client application can be transferred to a server. The latter option exploits the strengths and available resources of both the client and the server. However, due to their high degree of distribution, these applications often require a major human effort to develop and maintain, such as SQL databases or Siebel systems. A Web browser also falls into this category if, in addition to HTML pages, it runs local scripts that transfer specific application logic to the client. These scripts can be loaded with the HTML data stream and are usually based on Visual Basic Script or JScript (or JavaScript).
Remote data management Remote data management is used by many companies that have a PC infrastructure: all the application programs are found locally on the client, and only data is saved in a central location. This permits simple strategies for backing up and managing user data, thus requiring a less complex server structure. One clear disadvantage, however, is the level of management required to install and administer applications. Experienced users and developers favor this model because they in large part retain control over their clients.
Distributed data management The distributed data management model is every central administrator’s nightmare. Not only are applications stored on the client, but also some data as well, which makes it very difficult to manage and secure. Even though the user retains most control over the client computer, he or she would be at a loss in the event of a hardware or software error. The loss of a local hard drive could cause damage to the company due to un-recoverable data. The connected servers are only used for occasional data archiving and perhaps accessing e-mail or the Internet.
A terminal server requires the integration of thin client software, thin clients, or terminals. It corresponds to the first of the client/server options (remote presentation) mentioned earlier and therefore has the advantage of central administration. The other client/server options can be associated with different popular computing concepts as well, which helps classify them. For example, a PC in a local area network (LAN) falls under remote data management, whereas a classic client/server solution is a distributed application.
Nevertheless, a bi-level client/server model is inadequate and falls short of reality. Most of the time real environments have several layers. A client accesses an application or the Web server on the intranet, which in turn accesses a file server, a print server, a database server, or an e-mail server. In this way, the multilevel model meets the not-so-new requirement for complex application programs: the separation of presentation/interaction, program logic, and data management.
The real challenge for system administrators lies in providing and controlling such a complex environment. The reason is that often several client/server models are combined in corporate terminal server environments. For instance, Microsoft Outlook, a client application, accesses an Exchange server which is a distributed application. If, however, Outlook is not installed directly on the client PC but on the terminal server, this model would resemble a remote presentation. The processing logic for the Exchange data in Outlook is separate from its display on the terminal server client. Even though it seems awkward at first, this method has definite advantages over other models.
|
|
