thinban
Thin Client Computing:
The IBM Network Station in Retail Banking
A white paper
November 16, 1999
Paul Olson
IBM Certified I/T Specialist - Banking, Finance and Securities Industry
IBM Corporation
Charlotte, NC
-1-
Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Total Cost of Ownership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Purpose and scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Thin client computing standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Overview of the IBM Network Station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Network Station Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
NSM Features and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
WorkSpace on Demand (WSOD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Positioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Theory of operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Configuring and managing Network Stations and users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Characteristics of suitable applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Key benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Applications in retail banking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Branch banking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Call centers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Back office . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Key technical considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
I/O device support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
WinTel application considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Application re-engineering - Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Server location and administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Standalone operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Case study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Future . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Summary and conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
-2-
Introduction
Total Cost of Ownership
When The Gartner Group and other I/T industry consultants began focusing on the subject of Total Cost
of Ownership (TCO) some years ago, businesses that had invested heavily in PC client / server
computing were, for the most part, not taken by surprise. Based on growing I/T budgets, they already
knew - at least qualitatively - that the productivity benefits of PC desktops were being offset by the costs
of supporting them. What the consultants did provide, though, were models that attempted to quantify
costs of owning and using PC systems in the course of running a business. While debates continue
about the "real" costs of owning PC's, there seems little argument that acquisition costs (the cost of
buying hardware and software) are, over time, dwarfed by support costs. And the difference between
acquisition and support costs has continued to grow wider, as the cost of buying or leasing a typical PC
desktop system has declined dramatically, but support costs have not.
The TCO problem has received enormous attention from users and suppliers of computing solutions,
and for good reason. While not always well understood, businesses know that TCO costs are real, and
suppliers are eager to rush solutions to market, hoping to offer that tool or service that solves the
problem. So it is no surprise to find a multitude of solutions and strategies directed at the TCO issue.
The solutions for TCO reduction fall into two broad categories:
Ÿ
Enhance traditional PC client systems with management and administrative functions and tools
in hardware and software. Many examples of such enhancements have been - and continue to be
- introduced by nearly all of the major PC hardware and software suppliers, ranging from
individual programs designed to solve one specific problem, to full-fledged PC management
architectures.
Ÿ
Employ a more centralized model of client computing, using so-called "thin clients" instead of
traditional PCs ("fat clients"). The term "thin client" is rather vaguely defined, but generally refers
to a client system that requires a minimal amount of local compute power, storage and
(especially) configuration, relying heavily on one or more networked server systems to provide
complete functionality. "Thin client" does not necessarily equate to "limited capability", however.
The user may actually have more computing power at their disposal - it just happens to be
located in networks and servers instead of their client system. Also, PC's can be configured as
somewhat "thinner" clients. One approach to this is to remove the hard drive and diskette drive,
and configure the system to boot from a network server (RIPL).
-3-
It should be noted that the two approaches are not at all mutually exclusive. Advocates of thin client
computing recognize that thin clients are not appropriate for every user's needs, and will therefore not
completely displace the need for traditional client / server computing.
Purpose and scope
The thin client model has numerous implementations. This paper will focus on a type of thin client often
referred to as a network computer or NC, and specifically, the current NC offerings from IBM called the
IBM Network Station and its application in retail banking. A great deal of information has been
published on the subject of TCO and thin client computing, and it is not the intent of this paper to
duplicate what is already available. For further information, web sites and consultant reports are good
places to start. Two examples are:
IBM's Network Station (http://www.pc.ibm.com/us/networkstation/index.html)
Thinworld (http://www.thinworld.com)
Thin client computing standards
The introduction of network computers quickly gave rise to the need for standardization. In 1996, five
major computing companies (IBM, Sun, Apple, Netscape and Oracle) collaborated to produce a set of
standards, which came to be known as the Network Computer Reference Profile. Later, The Open Group
(http://www.opengroup.org/nc/brand/ncbrand.htm) established the Network Computer Brand Program,
which builds on the NC Reference Profile. Microsoft Corporation has established specifications for a
thin client called the Windows Based Terminal (WBT). The WBT is specifically intended for access to
WinTel applications running on multi-user Windows servers - Windows NT 4.0 Terminal Server Edition
and Windows 2000 Server. IBM Network Stations comply with the Open Group's Network Computer
specification and, while not designed to be WBT's, have a superset of WBT capabilities, including
delivery of WinTel applications running on multi-user Windows servers.
Overview of the IBM Network Station
This section is not intended to provide a detailed review of the IBM Network Station. Instead, a
summary of its capabilities, theory of operation, and key benefits will be discussed. Further information
can be found at http://www.pc.ibm.com/us/networkstation/index.html.
Hardware
-4-
The IBM Network Station is offered in four basic versions: Series 300, Series 2200, Series 1000 and
Series 2800. Each series has models for ethernet or token ring connectivity. The primary differentiators
are physical size, performance and options. The following table summarizes the major differences:
Attribute
Series 300
Series 2200
Series 1000
Series 2800
Size (inches)
10.5 x 1.2 x 7.5
10.8 x 1.5 x 8.0
11.5 x 2.0 x 8.9
13.6 x 2.8 x 11.4
Processor
32 bit Power
PC403 66MHz
32 bit X86 233
MHz
32 bit Power
PC603 200 MHz
32 bit X86/MMX
266 MHz
Memory (RAM) std/max
16MB / 64MB EDO
32MB / 288MB
SDRAM
32MB / 64MB EDO
64MB / 256MB
SDRAM
Video memory std/max
1MB / 2MB
4MB / 4MB
2MB / 2MB
4MB / 4MB
L2 Cache - std/max
N/A
N/A
0KB / 512KB
512KB / 512KB
Audio support
8 bit internal
speaker
16 bit with input /
output jacks
16 bit with input /
output jacks
16 bit with input /
output jacks
Warranty
One year
Three years
One year
Three years
Each IBM Network Station comes standard with:
Ÿ
Ÿ
Ÿ
Built-in LAN adapter with RJ45 connector (for 10/100BaseT ethernet or 16/4 auto token-ring)*
Display connector (DB15) for PC compatible monitor (VGA or higher)
Keyboard and two button mouse
* On the Series 300, ethernet is supported at 10BaseT only. The Series 300 also offers a twinax
version for connection to AS/400 legacy wiring.
All systems use industry standard memory (SIMMs / DIMMs).
The systems also differ in their ability to attach external devices. The following table summarizes the
hardware differences. (The capabilities for attaching external devices is also affected by the software
environment. This will be discussed in detail later).
Ports
Series 300
Series 2200
Series 1000
Parallel
1
0*
1
Series
2800
1
Serial (std)
1**
0*
1**
2***
USB
0
2*
0
2
-5-
* The Series 2200 system has two USB ports. One is used for the keyboard / mouse. Using converter
cables, the other USB port can be used to attach a parallel or serial device.
** The Series 300 and 1000 systems have a PCMCIA slot (standard on Series 300, optional on Series
1000), where a PCMCIA serial port expansion adapter can be used. Up to four additional (five total)
serial ports can be configured.
*** The Series 2800 system includes two internal PCI slots which can accommodate serial port
expansion adapters. Up to 16 additional (18 total) serial ports can be configured using optional PCI
serial port adapters.
IBM Network Stations are physically small systems, and consume less power than a typical desktop PC.
Their small size makes them ideal systems where space is at a premium - e.g. teller counters in bank
branches.
Network Station Manager
IBM's Network Station Manager (NSM) is a collection of integrated programs with client-side
components (software that runs in the Network Stations) and server-side components (software that runs
in servers that support the Network Station). IBM offers two versions of NSM, V1R3 and V2R1.
Here are some of the important distinguishing characteristics for V1R3 vs. V2R1:
1. Client hardware support
Ÿ
Ÿ
V1R3 - supports the Series 300 and 1000 only
V2R1 - supports all Network Stations
2. Server platform support
Ÿ
Ÿ
V1R3 is offered for: NT 4.0 TSE, AIX, OS/2 Warp, OS/400, VM/ESA, OS/390, and SCO.
V2R1 is offered for NT 4.0 TSE, AIX and OS/400.
(Consult the Network Station product documentation for specific NSM software prerequisites)..
3. Licensing fees
Ÿ
Ÿ
Ÿ
V1R3 is provided free of charge to purchasers of Series 300 and 1000 systems.
V2R1 is provided free of charge to purchasers of Series 2200 and 2800 systems (but a
one-time, one dollar administrative fee per user is required).
There is a one-time $50 per system license fee to use V2R1 with Series 300 or 1000 systems.
NSM Features and Functions
-6-
This section summarizes the features and functions of the client-side components of NSM.
1. Kernel
Both V1R3 and V2R1 include a multi-tasking kernel which is loaded when the Network Station
boots. The kernel includes all operating system-related functions including networking functions
(LAN and TCP/IP related services), since the Network Station requires network connectivity to be
a fully functioning client system.
2. Graphical desktop
V1R3 - After logon, V1R3 presents a graphical desktop to the user, with these basic features:
§
A taskbar which contains buttons to:
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
§
The presence of the taskbar is optional. It's usage is defined by administrators.
.
Windowing controls
Ÿ
Ÿ
§
launch programs - buttons to launch programs are defined by administrators using the
server-side programs of NSM. Administrators can
defined the program and text label for any number of buttons they wish. Each user
can have a different set of buttons defined.
logoff - logs the user off and reverts back to the logon screen.
lockup - locks the system. A password is required to unlock.
show/hide - controls whether the taskbar is always present or hidden
top/bottom - controls the location of the taskbar on the screen
move, resize, minimize, maximize and restore windows.
minimized windows appear as icons on the desktop.
Configurable bitmaps for:
Ÿ
Ÿ
wallpaper
screen saver
V2R1 - The V2R1 graphical desktop is more robust as compared to the V1R3 version:
§
Launch bar - The V2R1 launch bar is vertically oriented and located on the left side of the
screen. It offers numerous functions:
Ÿ
Icons with animation - Users launch applications by clicking on icons on the launch
bar.
-7-
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Pulldown menus - The launch bar icons can be configured to display a list of iconified
choices in a pulldown menu. For example, a "Host access" icon could be clicked to
display a list of host (emulator or ICA) sessions represented by icons.
Digital clock - The clock is located near the bottom of the launch bar.
"Extras" - This pulldown icon on the launch bar presents the user with a list of native
applications supplied with V2R1:
Text editor (NC Text)
Paint (drawing) program (NC Draw)
Calendar
Calculator
File manager
Audio player
Video player
RealPlayer
Tool Kit - This pulldown icon on the launch bar contains three diagnostic and service
tools:
Calibration tools - used for calibrating touch screen and light pen devices
Advanced diagnostics - provides a command interface for executing the arp,
iostat, netstat, nfsstat, pstat, traceroute and vmstatcommands
Print monitor - Provides print queue / job monitoring and canceling.
Controls - Launch bar controls include:
Iconify / Restore desktop (hides / unhides the launch bar)
Scroll up / down
Lock / unlock the system (password required)
Exit (logoff)
Memory indicator - Provides a simple, graphical indication of how much memory is
being used.
§
"Windows-like" decorations - The windows controls in V2R1 look like those used in MS
Windows 95.
§
Wallpaper - Backgound bitmaps definable at the user level.
§
Help System - Provides user help for navigating the V2R1 graphical desktop.
§
An integrated internet browser (Netscape Communicator 4.5) which can be used as the
desktop. From within the browser, the user can launch any client application on their
Network Station. This effectively makes the browser the user's desktop.
Note that for both NSM V1R3 and V2R1, the use of the graphical desktop is optional. In
those instances where the user only runs one program, no "desktop" is necessary. It could be
more desirable to directly launch the required program (full screen) directly upon logon. This
can be taken one step further, bypassing the server logon altogether, so that the system boots
-8-
immediately to the desired application (called "Kiosk" mode). This can be configured by
administrators using NSM's server side programs.
3. Terminal emulation ("green screen")
Both V1R3 and V2R1 provide several terminal emulators:
Ÿ
Ÿ
Ÿ
3270 for access to mainframe applications
5250 for access to AS/400 applications
VTxxx for access to Unix and other applications
The attributes of each terminal emulation session can be individually configured by administrators
and (if granted permission) by users. Keyboard mapping, fonts, colors and other parameters are
set to specified system-wide or group level defaults, which can be optionally overridden at the
user level. The server that authenticates users (more on this later) retains the individual settings for
each user, so the user's preferences are restored every time they log on to any Network Station
and start a session. Terminal sessions can be configured to start automatically when the system is
booted and the user authenticated, or launched by users when a button or icon is clicked. Since
the Network Stations only support IP-based communications (no SNA), 3270 and 5250 emulation
is done using telnet emulation (TN3270 and TN5250). The 3270 and 5250 emulators support print
screen functions to locally attached printers and network printers (Postscript, PCL or ASCII).
Printing from the VTxxx emulator is supported in V2R1 only.
The V2R1 versions of the emulators provide some enhancements compared to the V1R3 versions:
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Full-screen (non-windowed) capability
Scalable fonts
Password/ID encryption
Editable macros
Convergence toward more standard interfaces (look more like PC emulator sessions)
4. ICA Client
Access to WinTel applications is provided through the Network Station's native ICA client,
enabling communication with servers running Citrix MetaFrame with either Microsoft's NT Server
4.0 Terminal Server Edition or Windows 2000 Server.
Citrix MetaFrame is a licensed product from Citrix, Inc. that adds ICA support and other
functions to multi-user Windows. A scaled-down version of MetaFrame, called Citrix Device
Services (CDS) is available free of charge. CDS has some important limitations as compared to
the full MetaFrame product, e.g. it does not provide any load balancing capability and it only
supports certain network computers (including the IBM Network Stations) as clients (PC clients
-9-
are not supported). But CDS does provide ICA protocol support and I/O redirection, so it may be
sufficient for small, single-server implementations (e.g. a small, remote office such as a bank
branch) where network computers are the only clients needing access to the server via ICA.
The ICA client supports printing using any printer driver (queue) set up on the Citrix server (local
or remote), including printers attached to Network Station parallel or serial ports (and USB with a
converter cable on the Series 2200).
The V2R1 version of the ICA Client is enhanced compared to the V1R3 version
Ÿ
Ÿ
Ÿ
Ÿ
Improved performance
Improved security options - support for Secure ICA
16 bit audio
Remote Application Manager - allows users to choose from a list of Windows servers
to connect to.
5. X-Windows Server
The IBM Network Station can function as a full-fledged X-Station using the X-Windows protocol
common in Unix systems. Using this capability, the Network Station can also access WinTel
applications running on NT and Windows 2000 servers with multi-user and X-Windows client
extensions.
As with all programs, X-Windows server and ICA client sessions can be configured to autostart
when the system is booted and the user is authenticated, or launched by the user when an
appropriately configured button or icon on the desktop is clicked.
6. Internet browser
V1R3 - Included with NSM V1R3 is the NC Navigator 3.04 internet browser, a port of Netscape
Navigator version 3. It supports:
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
HTML 3.2
JavaScript 1.1
GIF and JPEG images
e-mail (SMTP and POP3) and news (NNTP)
Java (via the external JVM 1.1.4 in V1R3) Note: Plug-ins and helper apps are not
supported.
V2R1 - NSM V2R1 features Netscape Communicator 4.5 with support for:
Ÿ
Ÿ
Ÿ
Dynamic HTML
JavaScript 1.3
GIF, JPEG and PNG images
- 10 -
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Messenger e-mail (SMTP, POP3 and IMAP4) and news (NNTP with SSL) including
LDAP directory services and HTML formatting
Enhanced Netscape Java Virtual Machine (JVM) 1.1
Tuned for thin client environment
Euro currency support
Netscape security model (signed applets, etc.)
Plug-ins and helper apps
§ PDF 1.2 viewer (Acrobat 3)
§ RealPlayer 5.0 (plays streaming audio and video)
§ NC player (similar to Apple QuickTime 2 - plays audio and video (au, wav, aiff, etc.)
§ Java plug-in (allows choice of JVM - Netscape internal, or NSM external)
More translations and code pages vs. NC Navigator 3.04
Application launcher - This feature allows the browser to be the user's desktop. From the
browser's GUI, the user can launch any application (emulator session, ICA client, Java
program, etc.).
Note: Netscape Composer, used for creating HTML pages, is not included in the V2R1
version of Netscape Communicator. Likewise, AOL Instant Messanger and SmartUpdate are
not applicable and therefore not supported.
For both V1R3 and V2R1, storage of user bookmarks and user-defined preferences is done at the
server where the user is authenticated. Through system-wide or user-based settings in the server,
home pages, TCP ports, proxy firewalls, etc. are specified. To change most settings, users must
have the appropriate privilege level at the server.
Both browsers (V1R3 and V2R1) support printing to Postscript printers. Printing is supported to
locally attached printers on parallel or serial ports (and USB with converter cable on the Series
2200), and to TCP/IP addressable printers, using the LPR/LPD standard.
7. Java programs
Using the server-side programs of NSM, Java applications can be configured to load and run
automatically at logon at the Network Station, or when the user clicks a button or icon on the
desktop.
V1R3 includes a Java Virtual Machine (JVM) compliant with JDK version 1.1.4. The NC
Navigator browser uses this JVM to process applets embedded in web pages.
V2R1 includes a JVM compliant with JDK 1.1.8 which:
§
§
supports multiple, concurrent Java programs
includes the javax.comm interfaces (API's) which enhance and simplify Java programs'
access to serial and parallel devices.
- 11 -
§
§
includes full support for smart card readers, including a serial-attached GCR410 reader by
the OpenCard Consortium on all models of the Network Station, and the internal smart
card reader on the Series 1000.
provides Postscript printing support on local and remote printers.
The Netscape Communicator browser in V2R1 can be configured to use the NSM JVM or its
own (Netscape's) JVM. Both JVM's can run concurrently.
8. Local (flash) boot
Network Stations do not contain diskette or disk drives for booting. They are designed to boot
from the network, obtaining all operational software from servers. This key attribute helps lower
TCO by centralizing software management at far fewer and more secure locations.
In some cases, however, it is desirable to have a solution where the Network Station can boot and
load its software locally, but with more control over the software than is provided by traditional
data storage media (hard drives). To satisfy this requirement, IBM offers the ability to add local
boot using flash memory technology. (Remember that, even with local boot, all user data and files
are stored remotely on servers). The flash boot option makes the most sense in situations where:
Ÿ
Ÿ
Ÿ
Network boot time is too slow
Reboots are expected to be frequent
The client software image (kernel and applications) is expected to be stable.
Flash boot capabilities differ significantly between V1R3 and V2R1:
V1R3 - QuickOn option
In V1R3, flash boot is supported using PCMCIA flash memory cards, up to 40MB. In
practice, this is really only practical on the Series 300, because the 40MB limitation restricts
the number and type of applications that can be loaded along with the kernel. For all practical
purposes, local boot in V1R3 is limited to supporting terminal emulation, X-Windows and
ICA client. With such restrictions, it does not really make sense to use Series 1000 systems there is no need for that level of processing power. Also, the PCMCIA adapter is optional on
the Series 1000, but standard on the Series 300.
Having said this, the V1R3 flash boot option can be attractive on the Series 300 for specific
situations. IBM offers a flash boot option called “QuickOn" for the Series 300. It is a
PCMCIA flash card pre-configured with V1R3 and the ICA Client. With this option, a Series
300 system is powered up and booted locally (and quickly!) from the flash memory card,
ready for logon to a multi-user Windows server for running WinTel applications.
V2R1 - V2R1 offers greatly enhanced capabilities for flash boot, particularly for the Series 2200
and Series 2800 systems:
- 12 -
Compact ATA flash memory technology is used, with capacities currently around 100MB
and growing. The memory plugs into an internal IDE connector. V1R2 server-side NSM
provides for centrally managed flash images. GUI utilities are provided for system
administrators to quickly define and create multiple flash images. Administrators also use
NSM utilities to automatically cause selected clients to update their flash images when
directed to do so. These functions are key to effective software management, so that the
benefits of lower TCO can still be realized when local boot via flash memory is used.
9. LPR/LPD service
The Line Printer Requester (LPR) and Line Printer Daemon (LPD) services implement the TCP/IP
client/server printing standard. These programs run in the background and are not visible to the
user. The LPR service allows print requests from local programs (e.g. a 3270 print screen) to be
routed to available LPD print servers in the network. The LPD service allows the local Network
Station to function as a print server, using printers attached to the native ports. ASCII, PCL and
Postscript printers are supported. The amount of system RAM to set aside for the print buffer is
configurable, as are the permissions of users and systems allowed to send print jobs to it.
10. Background programs
Ÿ
Ÿ
Ÿ
telnet daemon
SNMP daemon
diagnostics daemon
These programs are not visible to the user. The telnet daemon allows support personnel to
remotely login to the Network Station and obtain access to configuration information and
diagnostic logs to aid in problem determination and debugging. The SNMP (Simple Network
Management Protocol) daemon implements a standard SNMP client that can forward events to
SNMP servers. The diagnostics daemon maintains a dynamic event log that aids in debugging.
The NSM software is available on CDROM and downloadable from web sites.
WorkSpace on Demand (WSOD)
IBM's WorkSpace on Demand (WSOD) is a unique offering supported on the Series 2800 Network
Station. WSOD works in conjunction with a server running OS/2 Warp Server 4.0, with WorkSpace on
Demand Manager installed. It includes server-side NSM for management of the Series 2800.
- 13 -
With WSOD, instead of booting the client-side V2R1 NSM environment, the Series 2800 Network
Station boots the WSOD environment from the server. This includes a complete and robust operating
system with advanced GUI, high performance JVM (compliant with JDK 1.1.7), and support for native
OS/2, DOS, and Windows 3.1 applications. IBM's full-featured PCOMM emulator is included. For
internet browsing, Netscape Communicator 4.04 is supported, with updates via download. OS/2
supported parallel and serial devices can be attached to the Series 2800. Windows 95/98 and NT/2000
applications can be accessed via the ICA Client.
User desktop configuration and profile, as well as all user data and files, are stored on the server.
WSOD is especially attractive to businesses that have OS/2 workstation requirements and want to take
advantage of the small size and low TCO of network computers. It offers a great migration path to Java.
It is an intriguing option for many financial institutions, since OS/2 has been a popular platform in the
industry, and
many banks have begun to plan and implement a Java strategy.
Positioning
The different versions of the Network Stations are intended for different environments and applications,
based on size, functional and performance requirements. Here are some general guidelines:
Ÿ
All models are suitable for terminal emulation, X-windows server, and ICA client. V2R1 offers
some improvements in emulation and ICA which may be important in some cases.
Ÿ
Native internet browser performance may or may not be satisfactory on the Series 300,
depending on the usage. If used for browsing (or if used at all with V2R1), the Series 300 requires
a memory upgrade. If heavy internet usage is required, one of the other models is recommended.
Ÿ
The Series 1000 and Series 2800 offer superior operation with Java programs. V2R1 should be
considered for the Series 1000 and Java in order to have JDK 1.1.8 support. The Series 300 is not
designed for Java-intensive usage.
Ÿ
All models except the Series 300 meet the requirement for high speed ethernet (100BaseT).
Ÿ
The Series 2200, Series 1000 and Series 2800 offer 16 bit audio support with stereo output and
mono input jacks. The Series 300 is not designed for multi-media applications.
Ÿ
If local boot of V1R3 is required, the Series 300 is the choice.
Ÿ
If local boot of V2R1 is required, the Series 2200 and 2800 are the two choices.
- 14 -
Ÿ
For I/O attachment, the Series 2200 is the most limited (one device, serial or parallel) and the
Series 2800 is the most flexible (up to 18 serial ports, plus parallel and USB).
Ÿ
For WSOD, the choice is the Series 2800.
Theory of operation
Without a network and server, the IBM Network Station doesn't do much. It contains a some nonvolatile
memory (NVRAM) to conduct a power-on self test (POST), preserve certain system settings, implement
a sufficient TCP/IP stack to begin the startup process, and run a system configuration utility. The startup
and
utility programs are contained in an NVRAM memory module, which can be updated from servers when
IBM releases new versions. NVRAM updates are processed automatically, with no local intervention
required other than rebooting the system. Rebooting can be forced remotely using tools provided by
IBM. The NVRAM / flash boot PROM (Programmable Read Only Memory) capability of the Network
Station is analogous to the CMOS / BIOS capability of modern PC's. To minimize expense and the
possibility of user error as much as possible, it would be nice to have a client system that you could
receive from the manufacturer and deploy directly to the end user without needing any local
configuration or customization. And it is entirely possible to do exactly that with the IBM Network
Station. Two industry standard technologies make this possible:
1. DDC (Dynamic Display Control)
Nearly all PC monitors manufactured since 1992 implement the DDC standard. When DDC is
enabled, during bootup the system will negotiate with the monitor attached to it, to set the
resolution and refresh rate to the highest possible settings supported by both the system and
monitor. The resolution is negotiated first, then the refresh rate. By default, IBM Network Stations
are configured to use DDC. If desired, this setting can be easily overridden using the built-in setup
utility. There may be cases where a different resolution is desired than the maximum one possible,
e.g. a user may want 800 x 600 even though the system and monitor can support 1024 x 768. The
entry level Series 300 Network Station with standard VRAM can support a resolution of up to
1024x768 with 256 colors. All other systems (and the Series 300 with optional VRAM) support
higher resolutions and many more colors.
2. DHCP (Dynamic Host Configuration Protocol)
Configuring network parameters on client systems can be one of the most time consuming and
error prone tasks. Yet, in today's connected world it is also one of the most critical. DHCP
provides a way for a client system, having just one network parameter available (its factory-set
LAN MAC address), to get everything it needs to be fully and correctly networked, from a server.
- 15 -
All LAN adapters, including those in IBM Network Stations, are given a unique MAC (Media
Access Control) address by the manufacturer. The MAC address, also sometimes referred to as
the Universally Administered Address (UAA) or Burned In Address (BIA), conforms to industry
standards for ethernet or token-ring.
With DHCP, the client simply broadcasts its MAC address on the LAN, waiting for a DHCP
server to respond. When a DHCP server does respond, it provides the client with all the necessary
networking information it needs such as IP address, subnet mask and gateway.
DHCP offers numerous advantages:
Ÿ
Simplified administration. Admin tasks are centralized at DHCP servers. This also greatly
reduces the chance that users will accidentally corrupt their client system's network
configuration.
Ÿ
Improved security. DHCP servers can be configured to ignore unrecognized MAC
addresses requesting network startup information.
Ÿ
Conserved IP addresses. Many organizations have a shortage of IP addresses available.
With DHCP, IP addresses can be pooled. When a client requests an IP address, the DHCP
server can "lease" one to the client. It will then poll the client periodically to see if the IP
address is still needed. If so, the lease is renewed. If not, the lease is terminated and the IP
address is reclaimed and put back in the pool.
The factory configuration for IBM Network Stations is to use DHCP. It can, however, be
overridden. The configuration utility allows users to choose network settings stored in NVRAM
rather than using DHCP. At a minimum, the following settings are generally required to be
entered into NVRAM, if DHCP is not used:
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Network Station IP address
Boot host IP address (up to three boot hosts can be specified)
Subnet mask
Gateway IP address
Boot protocol (TFTP or NFS)
Boot file name
Boot file path
Configuration file name
Configuration file path
Using DHCP eliminates the need to specify any of this on the client.
The combination of DDC and DHCP makes real "plug and play" from the factory possible. Only
servers need to be configured.
- 16 -
When the IBM Network Station is powered on, it first performs a power on self test (POST). POST tests
for errors in the processor, system or video memory, or if the keyboard or mouse are not attached. After
POST is successfully complete, the Network Station will enter the LAN and attempt to contact a DHCP
server. Once the DHCP server has been contacted and the needed information received, the Network
Station will attempt to contact the boot host specified by the DHCP server. If not using DHCP, the
Network Station will attempt to contact the boot host specified in NVRAM. At this point, up to two
servers have been needed: the DHCP server and the boot host. In practice, these can be, and often are,
the same system.
The boot host provides the Network Station with its operating system (kernel), as well as all java
components, fonts, libraries, and other modules that run in the Network Station. Some of these programs
are loaded at boot time, others loaded on demand. For example, the 3270 emulator module would be
downloaded from the boot server to the Network Station when needed (e.g. when the user starts a 3270
session).
As noted earlier, Network Stations can boot locally, using a properly built memory card inserted into
either a PCMCIA slot (Series 300 and 1000), or IDE connector (Compact ATA memory card - Series
2200 and 2800). While this is desirable for certain situations, local boot of network computers is the
exception rather than the rule, because of the additional expense and administrative overhead. The
majority of systems deployed are set up to boot from network servers.
To complete the boot process, two additional servers will be needed: a configuration server and an
authentication server. In practice, these servers may be implemented on the same system, or they may be
unique systems, or either one or both may be implemented on the same system as the boot server. It is
certainly
possible, and not uncommon, to have all of the servers - DHCP server, boot server, configuration server
and authentication server - all implemented on the same system.
But it may be desirable to segment the servers also, for numerous reasons. The configuration server
contains system-wide (not user unique) configuration data for booting systems. For example, if you
have one domain name server that you want all systems to use, the configuration server can specify and
enforce that. In practice, though, it is most common to combine the configuration server and
authentication server, since both provide configuration data to the system. Decisions about segmenting
the various servers call for careful consideration of many variables, and an in-depth discussion of this
subject is beyond the scope of this paper. However, a few important items should be noted:
Ÿ
Since DHCP requests are broadcast, most networks do not route them, as this could potentially
flood the network. Therefore, IP routers are normally configured to not forward DHCP requests,
confining them to the local LAN segment. So, usually, at least one DHCP server needs to be
located on the LAN segment where Network Stations are issuing DHCP requests. Servicing
- 17 -
DHCP requests is a fairly low demand function (unless one server has to service many requests
simultaneously), so little server and LAN capacity is needed for DHCP only.
Ÿ
Servicing boot requests is a potentially high demand function involving a significant amount of
data, although only in relatively short bursts. Boot servers do not necessarily need to be located
on the same LAN segment as the Network Stations they service, however, they should be
connected with sufficient bandwidth in order to keep boot time reasonable. The V1R3 the boot
kernel size is in excess of 2MB, and the native internet browsers are even larger. In most cases,
users keep their network computers constantly powered on, and rebooting is infrequently
needed.
Ÿ
Servicing configuration and authentication requests is a low demand function. These are the
servers that it may make sense to consolidate, in order to centralize user management to a small
number of servers. Also, if users travel from one location to another, they can access any local
Network Station and use the "Roam" capability to logon. The system will then prompt them to
enter their authentication server. When logon is complete, their desktop will appear as usual, no
matter where they logon. Although authentication takes little bandwidth, network reliability
should be high, or users will not be able to use their Network Computers, even if the DHCP and
boot servers are working fine.
The Network Station boots to an authentication screen, which prompts the user for a userid and
password. These are passed to the authentication server. If the supplied credentials are OK, the user is
logged on and their desktop appears, with any applications specified auto started and the taskbar or
launch bar present (if so configured). Every user can have a different desktop, with access to applications
that they need. One user may only have 3270 and 5250 sessions available, another may have an internet
browser and ICA client session. Yet another may have an enterprise java application autostarted. These
are just a few of many possible examples. The authentication server uses the profile set up for each user
to determine what that user sees and has access to.
The Network Station's user logon process takes advantage of the standard, native user management
facilities of the server platform being used to authenticate users. For example, if the authentication
server is a Windows NT server, the logon process uses users created and managed by NT's User
Manager for Domains. If it is an AIX server, it users are set up by SMIT. If an AS/400 is being used to
authenticate users, the user administration tools of OS/400 are used, and so on for the other supported
server platforms.
As a side note, there are situations where no authentication server is required. A business may have users
that always need access to exactly the same thing, with no need for user unique preferences or data to be
stored at the authentication server. For example, if all that was needed was an ICA client session, no user
authentication would be needed, because the session requires the user to logon to the Windows server
anyway. In such situations, the IBM Network Station supports what is called "kiosk" mode, where the
- 18 -
normal server authentication (logon) step is bypassed. Kiosk mode operation, if appropriate, further
simplifies setup and administration of servers.
Configuring and managing Network Stations and users
Numerous references have already been made to the fact the Network Station receives configuration data
from various servers during the boot and authentication processes. The natural question is, how are these
servers configured?
IBM supports many different server platforms in support of the Network Station: PC's (running NT
Server or OS/2), RS/6000, SCO, AS/400, and S/390. Each can fulfill any and all server roles: DHCP,
Boot, configuration and authentication.
Depending on the platform, various DHCP servers are available. In the case of NT Server, for example,
Microsoft provides a DHCP server and IBM also provides one with features specifically designed to
support the Network Station. Either one can be used. Configuration of DHCP servers is relatively
straightforward. When
using MAC address authentication with DHCP, these servers must be configured with the MAC address
of every client they support. Thus, if a Network Station is added to a subnet support by a DHCP server,
the server must be updated with the new client's MAC address. This simple task can normally be done
remotely in just a few minutes by administrators, using a text editor, GUI utility, or command line
interface to update the DHCP configuration file.
Boot servers use either the TFTP or NFS protocols to download files to the Network Station. IBM
provides all supporting code that runs on the Network Station, and server code required to get it there.
For example, since NT Server does not have TFTP and NFS servers as standard components, IBM
provides them as part of the Network Station supporting software for the NT Server platform. The code
is downloaded from an IBM web site, or received on CDROM, for the desired server platform and
installed using instructions provided. The installation of programs to configure a boot server is not
complex. However, it is best done by someone that has a good understanding of the server platform.
Authentication and configuration servers are generally implemented together, on the same server. It is on
this server where the IBM Network Station Manager (NSM) software is installed. The server-side
programs of NSM are powerful, browser-based applications that control the specific configuration and
usage of Network Stations. Because it is browser-based, NSM must run on a web (HTTP) server. Many
web server platforms are supported (e.g. Apache, MS Internet Information Server, etc.). Administrators
use NSM to configure system-wide defaults, group-level and individual user settings and access to
applications. NSM is also used to create and maintain local boot images. Users may also be permitted to
use a subset of NSM functions to control their environment (e.g., set the idle time for their screen saver).
- 19 -
To use the server-side NSM programs, all that is needed is a Java Script capable browser. The NC
Navigator and Netscape Communicator browsers supplied with NSM for the Network Station can be
used, as well as PC browsers such Netscape Communicator or Internet Explorer. NSM's server-side
administration utilities
are very easy to use. System-wide, group-level and individual user settings are specified very quickly.
Adding an application to the taskbar or launch bar, for example, can take less than a minute. Most
updates are seen immediately by users, only requiring that they log off and log back on. A few changes
require a reboot of the Network Station to take effect.
Being browser-based, administrators and users can access NSM from any client that supports a suitable
browser. For example, an administrator in San Francisco could access an NSM server in New York to
update and configure settings on a server there.
Characteristics of suitable applications
The IBM Network Station can handle the computing needs of many end users. It has inherent
limitations, however, that may make it an inappropriate client system in some cases. Specifically where:
Ÿ
Mobility and/or standalone operation is a key requirement
The Network Station is not able to function off-line (without a network connection). Dial-up
capability is being provided, however, booting over dial-up will be quite slow, so dial-up
operation will generally need to be accompanied by local boot (flash memory card). This might
be a suitable configuration for some specific situations (e.g. where the boot configuration is
expected to be highly stable over time), but, in general, the Network Station is not well suited to
non-LAN connected operation.
Ÿ
Remote execution of applications with high multi-media content is required
The Network Station does have the ability to process multimedia content. However, applications
that make heavy, continual use of audio and/or animated graphics (e.g. games) place a high
demand on the LAN for transmitting data between the application server and the Network
Station and may not perform acceptably. However, a browser-based or Java application with
high multimedia content is well suited to the Network Station (except Series 300).
Ÿ
Removable media is needed on the client system
The IBM Network Station has been purposely designed with no diskette, CDROM or other
removable media drive. This eliminates the possibility of users introducing unwanted programs
- 20 -
(e.g. games) or viruses, or copying sensitive information. In some situations, however, removable
media may be a requirement. The Network Station is not suited to such requirements.
Ÿ
Applications rely on the client's network address
Some WinTel applications use the client's Netbios computer name or IP address to perform
certain functions. For example, a help desk (telephony integration) application may route calls
based on the client system IP address. In a multi-user Windows environment with Network
Stations, such an application may not work because the application always runs in the server, and
every call would thus be routed based on the server's IP address.
Having said this, the Network Station is ideally suited to many types of applications. Popular office
suites (e.g. MS Office and Lotus Smart Suite) have been proven to work very well in the multi-user
Windows environment with thin clients, as have most other popular WinTel applications. The Network
Station is an excellent choice to handle virtually any text-based application from any server (mainframe,
midrange, Unix, etc.). Multiple, simultaneous instances of any mix of such applications is easily possible.
Finally, the growing trend toward browser-based enterprise applications makes the Network Station an
ideal client for delivery of internet / intranet based end user access. In many cases, the capabilities of the
Network Station can provide for a smooth migration path from text based to WinTel, internet and Java
applications. Network Stations can be initially deployed to deliver access to text based applications. With
no change to end user hardware, servers can be later updated to deliver WinTel, internet and Java
applications when the enterprise is ready to do so.
Key benefits
Real TCO savings are realizable from thin client computing, as delivered by the IBM Network Station.
The savings result primarily from:
Ÿ
Rapid and efficient application deployment
Improvements in deploying applications is the benefit most frequently mentioned by I/T
departments with experience using network computers. Deploying applications to large numbers
of geographically distributed PC users can be a huge challenge. Some of the factors that
contribute to this challenge are:
§
§
§
The sheer number of systems that have to be touched
Dynamics of the user population - users added/deleted, changing jobs/work locations,
non-availability of users due to vacations, illness, etc.
Compatibility issues - making sure that applications will work properly on numerous
hardware platforms.
- 21 -
All of these issues are dramatically reduced or eliminated through the use of the IBM Network
Station. Only servers are affected, so application deployment becomes greatly simplified and
much faster. Rapid and successful application deployment doesn't just make life easier for I/T
departments. It is foundational to making users productive in the business.
Ÿ
Simplified IMAC (Install / Move / Add / Change) tasks
Solutions using the IBM Network Station can dramatically reduce, or even eliminate totally, the
need for client system hardware and software configuration. Client system deployment and
redeployment are greatly simplified. Only the most basic of skills are needed: plugging cables and
powering on.
Ÿ
Decreased user-induced problems
Server administrators control systems configuration, resulting in greater compliance with
corporate computing policies and standards as compared to PC's. End users cannot install
unauthorized applications, or accidentally or purposely alter system settings, resulting in fewer
calls to the help desk.
Ÿ
Improved security
Users cannot copy and remove information, or introduce unwanted applications or viruses on
diskettes or hard drives. All data is stored on servers which can be physically secured more easily
than client systems. Administrators can also easily limit application access to the desired user set.
Ÿ
Enhanced backup and recovery
User data is stored on one or more servers, so backup and recovery requirements - even for user
data - are confined to those servers only. Should a Network Station fail, simply replace it, and
nothing has been lost or needs to be restored.
Ÿ
Independence of users and client systems
In distributed offices using Network Stations, any user can logon to and use Network Station at
any office. No matter which one they use, they will get their desktop and access to their
applications. Such independence of users and systems can be a great benefit to organizations that
have users that may "roam" from one client system to another, depending on local needs.
Ÿ
Reduced client system obsolescence
If new applications needing more computing power (e.g. processor speed, memory or hard drive
space) are required, there is no need to touch the client systems. Simply add additional server
- 22 -
capacity (create a "server farm", if necessary) and all users immediately have access to the
additional power needed.
The use of IBM Network Stations can result in real savings to TCO through reduced dependence on
the client system, greater administrative control and centralization of system administration.
Applications in retail banking
Branch banking
In many ways, branch banking is an ideal environment for thin client computers like the IBM Network
Station. Branch banking typically has:
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Minimal mobility requirements
Limited physical workspace
Standardized application set among users
Limited need for multimedia applications or removable media
Need for high security and backup of critical data
Strong requirement for access to mainframe applications and data
Limited local PC configuration / troubleshooting skills among users
Single LAN segment for all local users
Potentially large numbers of client systems across the enterprise
Bank branches typically have two groups of users: tellers and platform officers. The latter are also
sometimes known as loan officers, customer service representatives, financial consultants, personal
bankers, etc. Employees may have different specialties in this group. Specific roles and responsibilities
vary from one institution to another. Many banks have one employee designated as the branch manager.
Some banks also use an employee that functions as a receptionist / greeter that also handles routine,
noncash transactions and answer questions. All of these employees are potential candidates for a
Network Station as their client system, provided they do not have mobility requirements and the WinTel
application set can be certified to function properly in a multi-user NT environment. Key technical issues
will be discussed later.
The use of network computers in a bank branch offers numerous advantages:
Ÿ
There is normally little, if any, I/T skill available locally to resolve problems that arise in the
traditional - and more complex PC - client/server environment. System support personnel can
focus their efforts on the network and branch server, since the thin client systems will normally
need no attention.
- 23 -
Ÿ
Because the number of users is typically small, a single, modest server is usually sufficient to
provide all the capability needed.
Ÿ
The key benefits mentioned previously - IMAC activity, security, and backup / recovery - are all
important considerations in branch banking.
Ÿ
Perhaps most significantly, the task of applying software updates and deploying new applications
at these remote locations is greatly simplified by centralizing it at branch servers.
Call centers
Call centers (inbound and outbound), with high concentrations of users, limited mobility requirements
and a uniform application set, may be excellent candidates for thin client systems. The application set,
though, if there are WinTel applications, should be closely analyzed for telephony integration
requirements, to ensure compatibility with call routing functions.
Call center applications require a high level of integration between multiple information sources and
quick response times at the user workstation. Middleware provides computer telephony integration (CTI)
functions, along with workflow and data integration. Over time, as banks have increased the number of
delivery channels, the number of databases/servers have multiplied. The user workstation inevitably
becomes a multi-session, multi-windowed environment, often mixing presentations in GUI and green
screen type sessions.
The Network Station's access to multiple servers and multiple sessions, including native terminal
emulation, WinTel (via ICA), and local browser capability provides the call center end user with a
convenient system for presenting and navigating all applications and data seamlessly. And administrators
and support personnel get a
system that requires little upkeep.
Advanced call center applications are now available in Java. Network Stations offer an ideal platform for
deploying enterprise Java applications, with all the benefits of low TCO and without the headaches of
traditional fat client systems.
Back office
Financial institutions, like other businesses, normally employ an assortment of personnel using client
systems for various back office tasks, such as ERP (enterprise resource planning). Other employees use
desktop systems for market analysis and research, portfolio and investment management, managing trust
accounts, and countless other tasks related to running a profitable bank. An analysis of these users'
- 24 -
computing requirements may reveal additional opportunities for thin clients like the IBM Network
Station to replace traditional client / server systems, and pave the way for lower TCO. Again, when a
reasonable number of users are found to be using the same application set, with limited mobility and
multimedia requirements, the IBM Network Station may be an excellent fit.
Key technical considerations
Network computers have many advantages, but their unique characteristics require thoughtful
consideration of certain technical requirements.
I/O device support
Banks, and tellers in particular, typically use industry unique I/O devices attached to workstations.
Examples are:
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Receipt printers
Passbook / multipart form printers
Personal Identification Number (PIN) keypads
Magnetic stripe readers / encoders (MSR, MSR/E)
Check readers
Coin dispensers
Teller Assist Units
Most commonly, these devices are attached to serial ports on the client device, although parallel ports are
sometimes used for printers, and keyboard / mouse port connections are sometimes used for ancillary
input devices like PIN keypads and MSR's. As many as five serial ports are used on a teller client system.
Also, it is
quite common for two or more users to share devices through special device driver and/or application
software. Attachment of such devices to network computers like the IBM Network Station may present
technical considerations:
Ÿ
Depending on the specific model, the base product may not have sufficient serial ports available.
Serial port expansion is provided on the Series 300 and 1000 with a PCMCIA adapter (up to five
ports total) and on the Series 2800 with PCI adapters (up to 18 ports total).
Ÿ
Mouse (pointing device) port attached devices will not work because of the way the drivers for
these devices require direct access to the port hardware. However, keyboard port attached input
devices (e.g. an MSR or check reader on a "Y" cable) generally work fine because the data
transmitted by the device is treated just like keyed data.
- 25 -
Ÿ
Some branch automation applications in usage are still DOS based (particularly for teller
applications, where the industry I/O is most heavily used), and the drivers for the devices in use
are therefore DOS drivers. Many teller automation programs have a DOS heritage, and there has
been limited motivation to port them to a more advanced environment. Teller applications derive
little benefit from a GUI (in fact, some would claim it is a detriment), and the single-tasking
ability of DOS is generally sufficient for a teller application. The WinTel environment supported
by the IBM Network Station requires the use of multi-user Windows , which is not generally
compatible with DOS device drivers. Device I/O (serial and parallel) is supported in this
environment via "virtual ports", or port redirection across the LAN, something that is normally
not possible with DOS device drivers.
Some serial devices are designed to communicate with the client application using per-byte handshaking
protocols. Such communication is, by nature, very "chatty" and can result in poor performance when
using ICA and the client application is actually running remotely in a server connected by relatively low
speed lines.
Device I/O, then, with WinTel applications, requires one of following possible solutions:
1. Migrate to a Windows NT/2000 application using Windows drivers instead of a DOS application
with DOS drivers
Windows NT/2000 drivers for industry devices are now readily available from most
manufacturers. At the same time, ISV's of branch automation software are also providing
NT/2000 versions of their applications. The downside of this approach is the extra expense and
training required in moving users to an NT/2000 environment.
2. Another possibility - and an increasingly popular and important one - is to migrate to a Java
application, which can run natively on the Network Station, and use the device support of J/XFS.
More on this in the next section.
3. Modify the DOS drivers to work in the NT/2000 environment and port redirection
Providers of DOS drivers may be able to modify their drivers to work in an NT/2000 VDM
(Virtual DOS Machine) and support redirection that will work with the Network Station ICA
Client and Citrix CDS or MetaFrame. If this can be done, the modified drivers could present the
same interface (API) to the DOS teller application, eliminating the need to move to an NT/2000
application.
4. Use TCP socket programming
The I/O ports in the Network Station are accessible through TCP socket programming. Each port
is associated with a default TCP socket number (which can be changed). The serial port's
- 26 -
configuration for baud rate, parity, start/stop bits, and handshaking (dts, rts, Xon/Xoff, etc.) is
also customizable at boot time. Port access control is provided via tables read by the Network
Station at boot time, which specify hosts that are authorized to send and receive data.
To use TCP socket programming for port I/O instead of standard serial (COM) port
programming, the application and/or driver source code must be modified. Socket programming
is independent of, and can be used in conjunction with, WinTel application access via ICA.
A careful evaluation of device support requirements should be undertaken as a key consideration in the
use of thin clients with WinTel applications and multi-user NT.
WinTel application considerations
As discussed earlier, specific types of WinTel applications are not well-suited to the multi-user NT
environment. Applications with high multimedia content and applications that require a unique client
system address are the two most common examples. In the latter case, it may be possible to re-engineer
the application to work around the dependency on the client system's address.
Application re-engineering - Java
Another issue to consider in the use of thin client systems is the organization's application strategy as it
relates to Java. Many enterprises are past the stage of evaluating Java and developing a strategy for it,
and are now piloting, rolling out or in widespread production with Java business applications. The
promise of Java (OOP with platform independence and inherent internet affinity) is being increasingly
realized as the technology has matured and early concerns with performance and security have been
addressed.
An early criticism of Java was its relatively weak support for I/O devices. Significant improvements have
been made in this area, however, to develop an industry standard set of programming interfaces (API's)
for financial devices, through an initiative called J/XFS. The objectives of J/XFS are:
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Ÿ
Enable the access to banking peripherals for new Java banking applications
Provide a migration path for current financial I/O implementations
Ensure coexistence between 'old' and 'new' applications at the client level
Support for thin clients
Platform neutrality
Protect customer investments in current infrastructure of banking devices
Enable full transparency between the application and the device level
Provide a flexible and extensible solution for the network computing paradigm
- 27 -
The J/XFS architecture and specification were officially approved in September 1999, representing a
huge step forward towards formal standardization of both the J/XFS device model architecture and
specification. The following J/XFS documents have been completed: J/XFS Base Architecture Guide,
FAQ, Conceptual
Overview, and some of the device API specifications. (Specifications for three remaining devices in the
self-service area - Sensors and Indicators, Depository Units and Check Readers and Sorters - have also
been generated). All these documents can be downloaded from the web at JFXS Documentation
(http://www.jxfs.com/documentation).
Network Stations are excellent Java clients, and have been deployed by numerous enterprises for use
with Java, or in anticipation of new line-of-business Java applications, even when the Java requirement
doesn't yet exist. An organization considering the use of thin clients should make their commitment to
Java a key component of their decision.
Server location and administration
Since the IBM Network Station has a critical reliance on server availability, the design, placement and
support of servers is of utmost importance. Many factors can affect the final architecture of the
supporting server topology. In a branch bank situation, with a relatively small number of users connected
to the WAN by a
relatively low speed line, a single, modest, local server can usually provide all the necessary functions
(DHCP, boot, configuration and authentication). Remote administration and management of such
servers is accomplished by modern tools available for such purposes on all server platforms. For
instance, RDP on Windows Terminal Server can provide complete remote administration ability across
low speed lines from a Windows NT workstation. When clients are placed in remote locations, such as
bank branches, a key consideration is the amount of bandwidth connecting the branch to the enterprise
WAN. This bandwidth is a major factor in server placement. A good question to ask when considering
network computers and traditional PC client / server alternatives is,"how do the different options
compare on their requirement for WAN bandwidth?" Another factor to consider is how the requirement
for WAN reliability differs (if at all) between alternatives. Very often, WAN requirements are the same
whether the clients are "thin" or "fat". Careful server design and backup procedures can minimize
downtime and recovery time. For example, ECC memory and disk mirroring or RAID features
commonly found in servers can greatly reduce the risk of operational errors and lost
data. If another PC (e.g. a desktop system) is available in the branch, it could be configured to provide
backup DHCP and boot server support in case the main server goes down. The Network Stations could
use this ability to access mainframe and internet applications until the main server is repaired. A call
center situation is
- 28 -
entirely different. Here, powerful servers can be clustered on high speed networks to create server"farms"
with load balancing and auto fallback features to support large numbers of users. Multiple DHCP and
boot servers provide scalability and backup.
Standalone operation
In some cases, traditional client / server PC networks are designed to support temporary continued
operation in case the local LAN segment becomes unavailable. This could happen if the LAN hub failed,
the client or server LAN adapter failed, or the LAN wiring failed. PCs can, with proper application
software, be designed to continue to operate in a temporary standalone mode until the LAN problem is
resolved. This is not possible with network computers. But the advantage may be minimal, because
modern LANs are extremely reliable. Even twenty years ago, when networks were far less reliable than
today, branch automation systems using controllers and "dumb" terminals were used very successfully.
An organization concerned with client downtime because of LAN problems should examine their
history of LAN failures to determine the extent of such a risk. LAN hub replacement, if needed, is
usually accomplished very quickly since no configuration is required. Finally, servers can be configured
with an extra LAN adapter to
use in case the primary one fails.
Case study
A large US bank has deployed IBM Network Stations in about 40 of its branches. In this section we will
review this bank's experience.
Background
The bank's primary platform applications were mainframe based (IMS and CICS). Platform personnel
("financial consultants", in this case) used traditional 3270 terminals coax attached to 3174 controllers.
Branches were also equipped with a single desktop PC containing a suite of modern WinTel applications.
This PC was shared among financial consultants. Tellers used traditional PC client / server systems for
processing financial transactions. The teller systems were not part of the employee group being migrated
to Network Stations.
The bank decided to pilot the use of IBM Network Stations, for use by financial consultants, in about 40
of its branches. A strategy was laid out to deliver functionality in phases: 3270 functionality would be
delivered first. Later, access to PC applications and internet access would be added.
- 29 -
Phase 1
The initial phase required the design and deployment of a solution that provided 3270 emulation on IBM
Network Stations in the branches, in place of the aging 3174/3270 coax terminal solution. Several issues
had to be addressed:
Ÿ
TN3270 vs. SNA
The traditional 3270 equipment used native SNA protocols to communicate with the mainframe.
The Network Station does not support native SNA. Fortunately, the bank already had 3270 telnet
gateways operational in their network. The gateways perform LU to IP address mapping and
EBCDIC to ASCII character translation, allowing the TN3270 emulation of the Network Station
to communicate with the mainframe. Other solutions exist for this, such as TCP/IP on the
mainframe, but since the bank already had gateways with sufficient capacity in place, it was
decided to use them.
Ÿ
Server for DHCP, boot and configuration / authentication
A local system was needed in each branch to support the use of Network Station clients. Since
the number of clients was small (maximum of five in any branch), and the server load per client
was also small (clients would seldom require a reboot), a very modest PC could easily fulfill the
server requirements. It was decided to use the existing shared PC (a desktop system) as the local
server. It was upgraded to Windows NT Server 4.0 and IBM Network Station Manager for NT.
With 48MB of memory, this system easily provided the resources needed to support up to five
client systems.
Ÿ
Host directed print
One of the features of the traditional 3270 system was the ability to request forms printing to LU1
type printers from an IMS mainframe application. Each financial consultant had their own impact
printer. From their 3270 session, they could request certain single and multi-part forms to be
printed for various customer needs. In the old system, LU tables performed routing functions to
ensure that print jobs were sent to the right printer LU, based on the requesting terminal LU. In
the new system, there was no SNA. The printers became addressable through IP and the LPD
service. Once again, the existing 3270 gateway systems were configured to perform the required
LU to IP address mapping. However, there was still a problem: how could we specify which
printer should receive the print job? We could associate using LU association in the host
system, like before. But if we used DHCP with IP address pooling, we could not guarantee that
the Network Stations would have the same IP address every time it booted. The solution was to
- 30 -
use static IP mapping in the DHCP server. With this option, IP addresses are not pooled. Instead,
each client's MAC address is permanently assigned to a specified IP address.
Ÿ
Support and maintenance
With the solution that has been developed, each branch has an NT Server system in place. What
if this system failed and the hard drive needed replacement? Procedures were developed to
support the on-site build of a system's hard drive by service personnel, using a "golden image" on
a CDROM. The final steps of this procedure are performed remotely by I/T operation support
personnel, using remote management tools. These persons then also ensure that the rebuilt
system is working properly.
Phase 2
For the second phase, it was decided that internet access was not a priority. There were concerns about
sufficient bandwidth at the branches to support all normal teller and platform communications in
addition to multiple internet sessions. So phase 2 became an upgrade to multi-user NT, providing access
to the PC applications from the Network Stations, thus eliminating the need to go to the single (shared)
PC system and hope no one was using it when you wanted to. The upgrade contained several key
components:
Ÿ
Additional memory
In making the PC a multi-user system, additional memory was added to it, to support
simultaneous access to it from multiple users.
Ÿ
New operating system
Windows NT Server Terminal Server Edition and Citrix MetaFrame replaced Windows NT
Server 4.0. This upgrade required a complete rebuild of the system's hard drive. The upgrade also
included the latest version of IBM's Network Station Manager for NT and DHCP server, and
Microsoft's Internet Information Server.
Ÿ
New user desktop
In phase 1, the Network Station's desktop contained a taskbar with two buttons, each used to
launch a 3270 session. In phase 2, an additional button was added to the taskbar. This third
button launched an ICA client session, for access to the PC applications.
For the PC session, each user was presented with an identical desktop. The NT System Policy
editor was used to tightly control and restrict the actions users could perform. Users were given
access only to the desired set of applications. The "My Computer" folder, Internet Explorer, DOS
Command Prompt, Windows NT Explorer and other system resources were restricted.
- 31 -
Ÿ
Shared server resources
For storage of personal files created by PC applications, each user has a home directory on the
branch server, accessible only to them and system administrators. The home directories can
easily be backed up periodically. The server has a laser printer attached to its parallel port. This
printer is the default printer for all users.
Ÿ
Remote support enhancements
With NT 4.0 TSE, Remote Data Protocol (RDP) is a standard feature. RDP allows support
personnel to log in to remote servers and have the remote server's desktop displayed as though it
were local. Good performance is possible with RDP over relatively low speed connections.
Windows NT workstation clients offer RDP client capability.
Future
In the future, the bank is interested in adding intranet / internet browser capability to the Network
Stations, using the NSM provided browser. This will provide users access to internal web sites that
contain useful reference information, as well as up-to-the-minute information on financial markets.
Summary and conclusions
The promise of thin client computing - lower TCO - is here today. The IBM Network Station is a great
choice for businesses looking for a flexible, secure, and configuration-free client system. As networks
and application suites grow, the IBM Network Station is positioned to grow with them. In the Network
Station, financial institutions can find a cost saving client system for many users in branches, call centers
and back offices. To learn more about the IBM Network Station, including customer application briefs in
banking and other industries, go to http://www.pc.ibm.com/us/networkstation/index.html .
- 32 -
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement