Thin Clients Case Study
It is generally accepted that in 1993 Tim Negroes coined the phrase “Thin Client” in response to Larry Ellison’s request to differentiate the server centric model of Oracle from the desktop centric model prevalent at the time.
Since then the technology has evolved from a concept to a reality with the introduction of a variety of hardware devices, network protocols and server centric brutalized environments. The Thin Client model offers users the ability to access centralized resources using full graphical desktops from remotely located, low cost, stateless devices.
While there is sufficient literature in support of Thin Clients and their deployment, the strategies employed are not often well documented. To demonstrate the critical importance of how Thin Clients perform in relation to user acceptance this paper presents a series of case studies highlighting key points to be addressed in order to ensure a successful deployment. II.
A. Statement of the Problem rhea aim of this research has been to identify a successful strategy for Thin Client acceptance within an educational institute.
There is sufficient literature which cuisses the benefits of Thin Client adoption, and while this was referenced it was not central to the aims of this research as the barrier to obtaining these benefits was seen to be acceptance of the technology. Over a four year period, three Thin Client case studies were run within the Dublin Institute of Technology with the explicit aim of determining the success factors in obtaining user satisfaction. The following data criteria were used to evaluate each case study in addition to redirecting Universal Theory of User Acceptance Testing (TAUT) 1) Login events on the Thin Clients.
Reservation of the Thin Client facility. 3) The cost of maintaining the service. B. Facts surrounding the case rhea history of Thin Clients is marked by a number of overly optimistic predictions that it was about to become the dominant model of desktop computing. In spite of this there have been a number of marked developments in this history along with those of desktop computing in general which are worth reviewing to set the context for examining the user acceptance of this technology.
Thin Clients have established a role in desktop computing although not quite the dominant one initially predicted.
Hose developments have usually been driven by increases in processing power (and reductions in the processor costs) in line with Moor’s law, but the improvements in bandwidth and storage capacity are having an increasing effect on desktop computing and on Thin Client computing driving the move towards more powerful lower cost desktops but also the possibilities of server fertilization and Thin Client computing with the ability to run Thin Clients over WANTS.
The first wave of computing Nas one where centralized mainframe computers provided the computing power as hared resource which users accessed using dumb terminals which provided basic text based input and output and then limited graphics as they became graphics terminals. These mainframes were expensive to purchase and were administered by specialists in managed environments and mostly used for specific tasks such as performing scientific calculations and running highly specialized bespoke payroll systems.
The next wave was that of personal computing, whereby users administered their own systems which provided a platform for their personal applications, such as games, word-processor, mail and personal data. Since then the personal computer has undergone a number of significant changes, but the one of most interest was the nature of the interface provided to the user which has grown into a rich Graphical User Interface where the Personal Computer became a gateway to the Internet with the Web browser evolving into a platform for delivery of rich media content, such as audio and video.
This move from a mainframe centralized computing model to a PC distributed one resulted in a number of cost issues related to administration. This issue was of particular concern for corporate organizations, in relation to licensing, ATA security, maintenance and system upgrades. For these cost reasons and the potential for greater mobility for users, the use of Thin Clients is often put forward as way to reduce costs using the centralized model of the Thin Client architecture.
This also offers lower purchase costs and reduces the consumption of energy. rhea challenge faced by Thin Client technology is to deliver on these lower costs and mobility, while continuing to provide a similarly rich GUI user experience to that provided by the desktop machine (a challenge helped by improved bandwidth, but latency is still oaten a limiting tactic) and the tillable y Witt regard to applications they have on their desktop.
Typically, current Thin Client systems have an application on a server (generally Windows or Linux) which encodes the data to be rendered into remote display protocol.
This encoded data is sent over a network to a Thin Client application running on a PC or a dedicated Thin Client device to be decoded and displayed. The Thin Client will send user input such as keystrokes to the application on the server. The key point is that the Thin Client does not run the code for the user’s application, but only the code required to support the remote display protocol.
Nile the term Thin Client was not used for dumb terminals attached to mainframes in the sass’s, the mainframe model shared many of the attributes of Thin Client computing. It was centralized, the mainframe ran the software application and held the data (or was attached to the data storage) and the terminal could be shared by users as it did not retain personal data or applications, but displayed content on the screen as sent to it by the mainframe. From a desktop point of view, the sass’s were dominated by the introduction and adoption of the Personal Computer.
Other users squiring higher performance and graphics used Unix Workstations from companies like Apollo and Sun Microsystems. The X Window System was used on many Importations and X terminals were developed as a display and input terminal and provided a lower cost alternative to a Unix Workstation, with the X terminal connecting to a central machine running an X display manager. As such, they shared some of the characteristics of a Thin Client system, although the X terminal ran an X Server making it more complicated than Thin Client devices.
The sass’s saw the introduction of several remote display protocols, such as Cicatrix’s IAC Microsoft‘s RID ND AT&T’s VON for UNIX that took advantage of the increasing bandwidth available on a LANA to provide a remote desktop to users.
Terminal Services was introduced as part of Windows ANT. O in 1996 and it offered support for the Remote Desktop Protocol (RID) allowing access to Windows applications running on the Server, giving users access to a desktop on the Server using an RID client on their PC.
RID is now offered on a range of Windows platforms. Wise and vendors such as Computing launched terminals, which didn’t run the Windows operating system, but accessed Endows applications on a Windows Server using RID, which is probably still the nominate role of dedicated hardware Thin Clients. Similarly VON is available on many Linux and UNIX distributions and is commonly used to provide remote access to a user’s desktop.
These remote display protocols face increasing demands for more desktop functionality and richer media content, with ongoing work required in how, Inhere and when display updates are encoded, compressed or cached. Newer remote display protocols such as THING have been designed with the aim of improving these capabilities. In 1999, Sun Microsystems took the Thin Client model further with the SunRay, which was a simple network appliance, using its own remote display protocol called ALP.
Unlike some of the other Thin Clients which ran their own operating system, SunRay emphasized its completely stateless nature. This stateless nature meant that no session information or data was held or even cached (not even fonts) on the appliance itself and enabled its session mobility feature, whereby a smart card was used to identify a user with a session so that with the smarted the user could login from any SunRay connected to the session’s server and receive the Lesotho as it was previously.
Many tot these existing players nave since touched on improving their remote desktop protocols and support for multimedia or creating new hardware platforms. There have also been some newer arrivals like Piano Logic and Triadic who have developed specific client hardware to create “zero” clients, Ninth supporting server fertilization to render the remote display protocols. Also, there are a number of managed virtual desktops hosted in a data centre now being offered.
One of the drivers behind Thin Client Technology, particularly when combined with a dedicated hardware device, is to reduce the cost of the client by educing the processing requirement to that of simply rendering content, but a second driver (and arguably more important one) is to gain a level of universality by simplifying the variations in the client side environment. This has been met in a number of new ways using Virtual Machine players and USB memory in Microsoft’s research project “Desktop on a Keynesian” (DOG) and also the Monika product, allowing the mobility (and security) benefits attributed to Thin Clients.
This can be enhanced Ninth the use of network storage to cache session information. It can be seen that Thin Clients have evolved along with other desktop computing approaches, often driven by the same factors of increasing processing power, storage capacity and bandwidth. However, newer trends that are emerging with regard to fertilization, internet and browser technologies, together with local storage, present new challenges and opportunities for Thin Client technology to win user acceptance. As Wiser said in 1999 in this new era, “hundreds or thousands of computers do our bidding.
The relationship is the inverse of the mainframe era: the people get the air conditioning owe, and the nice floors, and the computers live out in cyberspace and sit there Uniting eagerly to do something for us”. Z.
THE CASE FOR THIN CLIENTS There are many stated benefits for Thin Clients all of which are well documented. Nile there is no single definitive list, potential system designers may have different aims when considering Thin Clients, these benefits should be clearly understood prior to embarking on any deployment and are discussed below.
Reduced cost of software maintenance rhea administrative cost benefit of the Thin Client model, according to Jeer is based on he simple observation that there are fewer desktop images to manage. With the combination of fertilization environments and Windows Terminal Service (WTLS) systems it would not be uncommon for twenty five or more desktop environments to be supported from a single installation and configuration. This reduces the number of upgrades and customizations required for desktop images in computer laboratories where the aim is to provide a consistent service from all systems.
Kessler and Hoyt remind us that the “creative use of Thin Client technology can decrease both management complexity and IT staff time.
In particular they chose Thin Client technology to reduce the complexity of managing a large number of kiosks and quick- access stations in their new thirty three million dollar library. They have also deployed Thin Client devices in a range of other roles throughout Valparaiso University in Indiana. Click on the other hand suggests that the potential benefits of Thin Client approach include the lower mean time to repair ( R) and lower distribution costs.
It is interesting to note that he does suggest that the potential cost savings for hardware are a myth, but that administration savings still make a impelling case for using Thin Client technology. Enhanced Security Speers and Angelic suggest that security concerns should be a major factor in the decision to adopt Thin Client systems and this becomes more apparent when referencing the Garner Thin Client classification model.
The Thin Client approach ensures that data is stored and controlled at the data-centre hosting the Thin Client devices.
It is easy to argue that the user can retain the mobility of laptops but with enhanced security and the data is not mobile, Just the access point. The argument is even easier to make when we consider recent high-profile cases of the theft of encrypted laptops containing sensitive medical or financial records. The freedom conferred on users of corporate desktop and laptop PC’s undermines the corporation’s obligations in relation to data privacy and security.
Steps taken to protect sensitive data on user devices are often too little and too late.
Strongman states that the most frequent use of a personal computer is for accessing web applications and states that the Thin Client model demonstrates significantly lower security risks for the corporation. Five security Justifications for adopting the Thin Client model were proposed. . Zombie Prevention 2. Theft Dodging 3. File Management 4.
Software Control 5.
Personal Use Limitations Strongman concedes that Thin Clients are not necessarily best for every enterprise and every class of user, but for enterprises with a large number of stationary “non- power” users, “Thin Clients may present the best option in terms of security, cost effectiveness and ease of management. ” User Mobility User mobility can refer to the ability of a user to use any device, typically within the corporation’s intranet, as a desktop where the user will see a consistent view of the yester, for example, SunRay hot-disking.
While user profiles in Microsoft Windows support this, it is often only partially implemented. Session mobility can be viewed as the facility for users to temporarily suspend or disconnect their desktop session and to have it re-appear, at their request, on a different device at a later time. This facility removes the need for users to log-out or to boot-up a desktop system each time they Knish to log-in.
Both of these potential features of Thin Client technologies help to break the sense of personal ownership that users often feel for their desktop or opt computers.
It is this sense tot personal ownership which makes the maintenance and replacement of corporate PC’s a difficult task, and this feeling of ownership and control is often a reason why users resist the adoption of a centrally controlled Thin Client to replace their desktop, whereas this is exactly why IT management may want to adopt it. Environmental Costs In the article “An Inefficient Truth” Plan reveals a series of “truths” supported by a number of case studies directed at the growing costs of Information and Communication Technologies.
One such case study is of Reed Managed Services Inhere 4,500 PC’s were replaced with Thin Clients, and a centralized blade server providing server based brutalized desktops. Savings are reported as follows: 1 5.
4 million skew reduction, 2. ) 2,800 tones of CO saved annually 3. ) Servers reduced by a factor of 20 4. ) IT budget cut by a fifth Indeed there are many deployments focused on obtaining energy savings through the use of Thin Clients.
In a case study where SunRay systems were introduced into Sparked a public German Bank, Bruno-Bruit reports that the savings in electricity costs alone were enormous.
The University of Oxford has deployed SunRay Thin Client devices in their libraries citing the cooler and quieter operation as factors in their decision. These devices, having no local hard disk and no fan operate at a lower temperature and more quietly than traditional PC’s. This characteristic has environmental implications from noise, cooling and power consumption perspectives.
Summary of Benefits In summary, we can extract the benefits observed within literature and case studies as follows: 1) Increased security as data maintained centrally 2) Reduced cost of hardware deployment and management and faster MATT 3) Reduced administration support costs ) Environmental costs savings 5) Reduced cost of software maintenance 5) Reduced cost of software distribution 7) Zero cost of local software support 3) The ability to leverage existing desktop hardware and software 9) Interface portability and session mobility 10) Enhanced Capacity planning 1) Centralized Usage Tracking and Capacity Planning Rhine Clients vs..
Fat Clients Rhine Client technology has evolved in sophistication and capability since the middle of the sass, however the “thickness” (the amount of software and administration required on the access device) of the client is a source of distinction for many enders.
Regardless of “thickness”, Thin Clients require less configuration and support when compared to Fat Clients (your typical PC). In the early sass Garner provided a client-server reference design shown in Figure 1 .
This design provides clarity for the terms “thin” and “fat” clients by viewing applications in terms of the degree of data access, application and presentation logic present on the server and client sides of the network. The demand for network based services such as email, social networking and the World Wide Web has driven bandwidth and connectivity acquirement to higher and higher levels of reliability and performance.
As we progress to an “always on” Network infrastructure the arguments focused against Rhine Clients based on requiring an offline mode of usage are less relevant. The move from Fat Client to Thin Client is however often resisted as individuals find themselves uncomfortable with the lack of choice provided when the transition is made, as Observed by Wong et al.
Figure 1: Garner Group Client/Server Reference Design CASE STUDIES No matter how well documented the benefits of Thin Clients may be, there is still an issue of acceptance to be addressed.
While it may be tempting to assume that the Implementation of technology is a technical issue and that simply by building solutions a problem is effectively solved, evidence would point to the contrary. As there can often be a disparity between what is built and what is required or needed. ROR often requirements gathering, specification definition and user consultation are forgotten in the rush to provide new services which are believed to be essential.
In essence the notion of “if we build it they will come” is adopted, inevitably causing confusion and frustration for both service provider and the user. For example, during Sun Microsystems’ internal deployment of its own SunRay Thin Client solution many groups and functions sought exemptions from the deployment as they believed that their requirements were sufficiently different to the “generic user” to warrant exclusion from the project.
The same arguments still exist today and it is often those with a more technical understanding of the technology who are the agents of that technology demise.
By providing interesting and often creative edge cases which identify the limitations of a technology, they can, by implication, tarnish t as an incomplete and flawed technology. In the case of Thin Clients, it should be accepted that there are tradeoffs to be made. One of the appealing aspects of the Fat client is its ability to be highly flexible which facilitates extensive customization. However not every user will require that flexibility and customization.
Thin Clients are not going to be a silver bullet addressing all users needs all of the time.
All three case studies were evaluated under the tolling headings in order to allow a direct comparison between each. These criteria were selected to ensure that there was a lance between the user acceptance of the technology and the technical success of each deployment. 1) Login events on the Thin Clients 2) Reservation of the Thin Client facility 3) The cost of maintaining the service Figure 2: Case Study 1 DID case study 1 In 2005 the DID introduced the SunRay Thin Client technology into the School of Computing.
In a similar approach to many other technology deployments the strengths of the technology were reviewed and seen as the major selling points of the deployment.
In the case of SunRay there was a cheap appliance available which Mould provide the service of graphical based Unix desktops. Centralized administration ensured that the support costs would be low and the replacement requirements for systems for the next five years would be negligible. In essence the technological and administrative advantages were the focus of this deployment.
Few of the services offered within the existing PC infrastructure were included in the deployment. This deployment sought to offer new services to students and Introduced Thin Clients for the first time to both students and staff.
Design A single laboratory was identified for deploying the SunRay systems and all PC in that lab were replaced with SunRay 1 50 devices. A private network interconnect was built Inch ensured that all data sent from the clients traversed a private network to the SunRay server.
The initial design of this case study is shown in Figure 2 and it allowed students within this new Thin Client lab access to the latest version of Solaris using a full screen graphical environment as opposed to an SSH command-line Unix shell which was the traditional method still used from existing computing laboratories. A new authentication system was introduced based on LDAP which required students to have a new surname and password combination which was efferent to the credentials already in use within the Active Directory domain used for the existing PC network.
The reason for this alternative authentication process Nas due to the difficulty of authenticating on a UNIX system using Active Directory.
Once the server was running, the Thin Client laboratory was ready to provide graphical based UNIX login sessions at a considerable reduced price when compared to an investment of UNIX workstations for each desk. In total 25 Thin Client devices Newer installed which were all connected too single Solaris server. In summary the eye components within the design were as follows 1 . ) The service was on a private network 2. New authentication process was introduced 3. ) New storage mechanism was introduced 4.
) Devices were all in the same location 5. ) Service provided was a CEDE desktop on Solaris ) Graphical desktops running on Linux servers also accessible Results rhea login events are a measure of the general activity of the devices themselves and Newer considered to be a reasonable benchmark for comparison with existing laboratories within the institute. One interesting point is that the comparison of acclivities is not necessarily relevant when the facilities provide different services.
Due to the fact that UNIX instead of Windows was provided meant that, with the exception of those taking courses involving UNIX, the majority of students were unfamiliar with the technology and did not seek to use the systems. Login events on the Thin Clients: rhea login events were extracted from the Solaris server by parsing the output of the last command which displays the login and logout information for users which it extracts from the /vary/Adam/wetter file.
The number of login events per day was lactated and plotted in the graph shown in Fig. 3.
Immediately obvious was the low use of the system. Given that the nature of the service did not significantly change over the course of the three years that the system was in place with the exception of semester activity in line with student presence in the institute, it is clear that there Nas low utilization of the service. The graph shows raw data plotted, where login events were less than 10 per day. Figure 3: User Login Events Reservation of the Thin Client Facility: Each laboratory may be reserved by staff for the delivery of tutorial sessions and exercises.
The hourly reservations for this laboratory were reduced as a result of the introduction of Thin Clients with only 1 to 2 hours being reserved per day. One of the primary reasons for the reduction in the use of this facility was the fact that it had now become special purpose and the bookings for the room were limited to the courses which could be taught within it. rhea Cost of Maintaining the Service: A detailed analysis of cost savings associated with the introduction of Thin Clients Nothing our institute and specifically the costs associated with this case study was performed by Reynolds and Gleeson, [30].
In their study they presented evidence of savings in relation to the cost of support, the cost of deployment and a basic analysis of the power consumption costs. They review both the system and the software distribution steps associated with Thin Clients and PC systems and present a point of quantifiable comparison between the two. Key findings of this analysis were as follows: 1) Time spent performing system upgrades and hardware maintenance was reduced to virtually zero as no hardware or software upgrades were required.
) A single software image was maintained at the central server location and changes were add available instantly to all users. 3 No upgrade costs were incurred on the T Clients or server hardware. All systems have remained in place throughout both case studies. The devices in this lab are now 8 years old and are fulfilling the same role today as they did when first installed. 4) The Thin Client lab is a low power consumption environment due to the inherent energy efficiency of the Thin Client hardware over existing PC’s.
This can provide up to 95% energy savings when compared to traditional PC’s.
Analysis There has been extensive research in the area of user acceptance of technology, but reaps the most relevant work in this area is the Unified Theory of Acceptance and Use of Technology (TAUT) which identifies four primary constructs or factors a) Performance Expectancy b) Effort Expectancy z) Social Influence d) Facilitating Conditions Nile there are additional factors such as Gender, Age and Experience, within the student populations these are for the most part reasonably consistent and will be moored.
It should be stressed that although the TAUT was developed for an industry based environment it is easily adapted for our purposes. It was felt that this del serves as a relevant reference point when discussing the performance of the case studies. Clearly Case Study 1 failed to gain acceptance despite belief that it Mould in fact be highly successful at its inception. We review the case study under the four TAUT headings to identify the source of the user rejection of the Thin Clients.
) Performance Expectancy This factor is concerned with the degree to which the technology will assist in enhancing a users own performance. Clearly however the services provided an advantage to those students who wished to use UNIX systems. Since the majority of rouses are based on the Windows operating system it would be reasonable to assume that there was no perceived advantage in using a system which was not 100% compatible with the productivity applications used as part of the majority of courses. ) Effort Expectancy Irish factor is concerned with the degree of ease associated with the use of the system. One of the clear outcomes of Case Study 1 was that students rejected the UNIX systems as it was seen to be a highly complex system, requiring additional authentication beyond what was currently used in traditional laboratories c) Social Influence This is defined as the degree to which there is a perception of how others will view or judge them based on their use of the system.
Clearly by isolating the devices and having it associated with specialized courses, there was no social imperative to use the labs. UNIX as a desktop was relatively uncommon in the School at the time of the case study and there would have been a moderate to strong elitist view of those who Newer technical enough to use the systems. D) Facilitating Conditions This is defined as the degree to which an individual believes in the support for a
