|
|
|
Managing Multivendor Networks
  
- 8 -
Services
The Scope of Services
Services are a very elusive aspect of networking. Because they cannot be seen
or held in the palm of your hand, it is difficult to envision connecting them together.
Yet services are the make-or-break component of a network implementation. If the
underlying services cannot support the demands of the applications and the users,
then the network will collapse.
And while networks depend greatly on services, the reverse is not true. In most
cases, services are independent from the type of network on which they run. For example,
multivendor office automation services have similar applicability and functions in
both LANs and WANs. The same is true of manufacturer-specific services, such as IBM's
Systems Network Architecture (SNA) and Digital's DECnet.
Sometimes, however, services are married to networks for a reason. For example,
PC (MS-DOS) virtual disk services could technically be implemented on a midrange
host over a WAN or LAN, but the need for transmission speed dictates a close marriage
to the LAN environment.
In fact, the very nature of a LAN poses certain requirements for services. After
all, if a LAN presented no benefits, no one would consent to attach to it. For minicomputers
and mainframes, the purpose of a LAN is to share terminals, printers, and disk space.
For PCs, however, the prime requirement is to share files and applications, and to
promote communication. Furthermore, not only do PC LANs and minicomputer/mainframe
LANs have separate service needs, but when both types of systems need to be integrated
as a whole, yet another set of services is necessary. In this arena, then, the choices
become broader, the players grow in number, and the mind begins to boggle.
Rising to meet this need for better integration among all types of computers is
the concept of client/server computing. This concept provides a distributed
environment for all application programs, while still giving the user a consistent
and understandable appearance.
The LAN environment contrasts sharply with that of a WAN. For one thing, transmission
speed in a LAN is virtually free (in other words, there are no ongoing costs for
daily operation of the network). In a WAN, however, you get what you pay for when
it comes to speed. Sure, you can get breathtaking speed with T1 links, satellite
links, and even microwave links, but these technologies don't come cheap.
At the other extreme of cost/performance is low-speed networking. Where high speed
WANs engendered concern about optimum use, slower networks tend to be used for lower
volume and less critical information. In this category fall the traditional phone-dial
and packet switching networks. They are excellent, cost-effective solutions for occasional
terminal access, intermittent and non-critical file transfers, or electronic mail.
In particular, electronic mail services have enjoyed explosive growth in WANs
of all varieties. Electronic mail products have become much more sophisticated and
have begun to offer real value to companies implementing them. And with this increase
in use has come an increase in the need to expand the communications sphere of the
product. Often, electronic mail starts in one department on one type of computer
but grows into a corporatewide network encompassing many different departments and
many different types of computers.
LAN Services
Despite the physical and logical connectivity provided by a LAN, a network has
no functional capabilities until network services are added to the mix. These services
facilitate shared files, shared printers, program-to-program communications, directory
services, and other more specific functions. The implementation details for network
services, however, differ from vendor to vendor and from system to system.
Perhaps the biggest difference is how PCs interact on LANs compared to how midrange
and larger computers interact on them. This difference results partly from the fact
that the needs of PCs on a network differ from the needs of traditional computers,
and partly from the fact that much of the LAN networking software for PCs was developed
from scratch (without respect to existing standards).
The requirements of a PC LAN are rapidly changing. In a larger environment, the
network is used as a collaborative tool that enables individuals in different geographical
locations to work together on individual documents. In a smaller environment, users
may have more modest needs from their networks, and may use them only for sharing
files, peripherals or applications, and for e-mail. The network interface to handle
files is at a very low (sector) level to maximize speed.
In minicomputer/mainframe computer LANs, however, the requirements generally focus
more on the movement of files and the optimization of terminal resources. File access
must be performed in a highly structured, secure manner, and files have specific
places of residence and ownership. When an end user wants to alter a file in this
environment, the file will probably be copied (transferred) to the user's computer
and then modified there. Terminals are the user's way of accessing applications and
information; therefore, this type of LAN maximizes the way a terminal accesses the
various systems in the LAN. As in PC LANs, though, it is common to share printing
and program-to-program communications between systems.
The heart of the contrast between the two operating environments lies in the operating
systems. Operating systems written for midrange and mainframe systems (for example,
VMS, MPE, OS/400, and Windows NT) are designed with networking in mind. File systems
are designed to accommodate residence on different physical hosts, physical printers
are isolated from the print generation process by print queues and spoolers, and
program compilers are developed to accommodate all of these network-oriented operations.
Thus, a program developed in this environment can immediately take advantage of the
network architecture.
Originally, personal computers were largely stand-alone devices. One of the first
PC operating systems was Microsoft's Disk Operating System (MS-DOS) with its IBM
derivative (PC-DOS) and other OEM versions. DOS in its various incarnations was designed
to control all resources directly. Files were on local disks, printers were locally
attached, and every program was an island incapable of communicating with other programs--and
that was that. Thus, when networking was introduced to the PC, it had to be crowbarred
in between the operating system (DOS) and the hardware. In other words, a program
operating on a networked PC had to think it was operating using its own local resources.
Faster PCs eventually led to the development of more sophisticated PC operating systems,
such as Microsoft's Windows 95 and Windows NT, which have networking features built
in.
The presence or absence of tight integration between network services and the
operating system makes a dramatic difference in how the network appears to the end
user. In tightly integrated systems like DECnet, the network is a widely accepted
and embraced part of the system. In loosely integrated systems, such as most implementations
of TCP/IP, the network is a separate entity, accessed through a separate set of utilities
and routines. And in between these two examples are networks that make a variety
of compromises between tight and loose integration.
Minicomputer/Mainframe LAN Implementations
Given that networks and operating systems have a significant impact on one another,
a brief recap of the networking architectures and philosophies of Digital, HP, IBM,
and Sun is in order.
Digital Equipment Digital Equipment's networking architecture
is based on the IEEE 802 family of standards. In terms of networking software, Digital
offers a range of utilities and services under the umbrella of DECnet. DECnet protocols
and services allow remote file operations, print sharing, remote logon, program-to-program
communications, and other functions. Because DECnet is tightly integrated with Digital's
operating systems (VMS and ULTRIX), DECnet is part of the user and file-naming conventions
and structures used by the operating systems. Another Digital LAN protocol that has
gained wide popularity is the Local Area Transport (LAT). LAT is a protocol
used by terminal servers (devices that attach terminals directly to the LAN)
to route terminal traffic to and from one or more hosts on that LAN. LAT is not a
formal part of the DECnet service suite and has gained some usage and acceptance
in non-DEC networks and hosts.
All things considered, Digital Equipment has one of the most well-integrated network
archi-tectures--it was one of the first companies to integrate networking into their
standard computing environment.
Hewlett-Packard HP's primary LAN architecture relies on the
IEEE 802.3 standard. It, however, does have some peripheral products that also use
Ethernet. HP's networking software is called NS and is similar to both TCP/IP and
DECnet in its architecture and implementation. Because HP added networking to its
core products much later in life than Digital, networking routines and utilities
have been implemented as extensions to its existing products.
HP's most significant contribution to LAN computing has been its use and endorsement
of the client/server computing architecture, which is discussed later in this chapter.
IBM IBM's LAN strategy is primarily focused on its token-ring
network, compatible with the IEEE 802.5 specification. For networking services, IBM
has implemented those defined in its SNA. Specifically, in a mainframe environment,
token-ring networks can be used to tie workstations to controllers, and controllers
to communications processors (front ends). Token-ring networks provide high-speed
communication links for these traditionally distributed and hierarchical SNA connections.
Token-ring LANs can also connect AS/400 computers. With these implementations,
IBM offers a set of services to enable file sharing between systems (the Distributed
Data Manager) or the logging on to one system from another (Display Station Passthrough).
Again, because the token ring is part of the bigger SNA picture, standard SNA
transports such as LU 6.2 can run across a token ring LAN just like they run across
SDLC links.
In addition to its token ring implementations, IBM also offers a number of products
to provide connectivity to both Ethernet and IEEE 802.3 networks. These connectivity
products typically use IBM's implementation of TCP/IP for network services to non-IBM
computers.
IBM has further reinforced its commitment to establishing connections between
SNA and the LAN by purchasing Novell's NetWare for SAA (System Application Architecture)
gateway business. NetWare for SAA is a leading LAN-to-SNA gateway, and connects NetWare
LANs to IBM SNA applications. However, the deal now places IBM in the position of
having two competing products. IBM's Communications Manager/2 accomplishes the same
functions as the former Novell product. Both of these products in turn compete with
Microsoft's PC LAN-to-SNA integration product, SNA Server.
Sun Microsystems Sun Microsystems provides Ethernet connections
with most of its equipment. Its networking services are layered on top of TCP/IP
and are focused on Sun's Network File System (NFS) product, which provides transparent
file access between systems participating on the same network. In fact, Sun's approach
to networking is an interesting hybrid between Digital's distributed processing techniques
and the shared file server technology now commonly used in PC LANs. To a certain
extent, Sun enjoys the best of both worlds.
Such functions as program-to-program communications, print services, and remote
logon are handled through services integrated into the operating system. These services
are based on the TCP/IP model.
For file services, however, Sun has introduced the concept of NFS servers to its
LANs. In this approach, one or more systems contains the physical disk and the logical
files used by other systems throughout the systems. As in PC networks, a user wanting
to access a file on a server must issue special network requests (such as a mount
command) to make the files available.
This use of NFS servers is quite different from Digital's approach of giving each
system its own local disk to share. If nothing else, Sun's networking approach puts
a new spin on traditional TCP/IP implementations.
And finally, note that standard implementations of TCP/IP are available for all
of these vendors systems, although in some cases TCP/IP must be obtained through
third-party sources. Unlike the manufacturer's proprietary networking services, TCP/IP
has no particular ties to any one manufacturer or operating system. See Chapter 9,
"PC LAN Network Operating Systems," for TCP/IP details.
PC LAN Implementations
Because most of the companies that developed LAN software for PCs have no vested
interest in any particular LAN, their products can typically be configured for any
type of network. This brings tremendous flexibility to the desk of the haggard network
administrator who desperately wants only one network for the corporate equipment
connections.
While achieving this distance from the manufacturers offers benefits (in the form
of LAN independence), it also contributes complications because the network vendor
and the operating system are not closely related. Again, this situation sharply contrasts
with the implementation of networking services in the larger computers. In that environment,
networking functions can often be incorporated into the operating system itself,
offering a seamless, or nearly seamless, interface between the two.
In the land of the PCs, however, Microsoft dominates the market with its Windows
family of operating systems. The bulk of network services have been designed around
the Microsoft operating system structure. Windows 3.1 and previous releases are not
true operating sys-tems; rather, they are operating environments that run on top
of MS-DOS. Windows 95 and Windows NT, however, are true operating systems that incorporate
the functionality of MS-DOS within the overall operating system.
In order to understand how LAN services came to the PC environment, you need to
look at the original MS-DOS architecture. As shown in Figure 8.1, the MS-DOS operating
system uses two sets of low-level services for interface with the physical hardware.
One set of services is provided through a ROM-based BIOS (Basic Input/Output System)
program, and the other set is provided through a set of MS-DOS BIOS routines.
FIG. 8.1 Basic Input/Output System
The two sets of BIOS services are not independent of one another. Specifically,
the MS-DOS BIOS services provide generalized services that are requested by application
programs (such as read a record in a file or send print to a printer), while the
ROM BIOS provides extremely low-level services such as read a specific sector on
a disk or write this information to a machine-level I/O port.
In practice, many MS-DOS BIOS services actually end up calling the lower-level
ROM BIOS service. For example, when an application requests MS-DOS to read a record
from a file, the MS-DOS BIOS service translates the request to a specific sector
on the physical disk drive and then requests the ROM BIOS to read that sector. Similar
relationships are in place for printer and communications services.
This channeling of basic input/output services through a common point gives networking
software the opportunity to impose itself between the operating system and the hardware,
without forcing any changes in the application program. This insertion can be done
in several ways: by adding a device driver to the standard MS-DOS environments to
redirect services on to the network; by replacing the MS-DOS BIOS routines with network-oriented
routines compatible with the MS-DOS services; or by combinations of the two techniques.
When network services are put in place of or added to the MS-DOS BIOS services,
requests for disk information and printed output can then be routed from one machine
to another through the physical network (see Figure 8.2). Obviously, practical use
of this technique also involves specifying which machines are servers for which services.
But, when properly configured, a request to print a file on computer A can be routed
to print on computer B. Furthermore, the disk resources of computer C can also be
made available on computers A and B.
FIG. 8.2 Network Redirection
As mentioned earlier, disk sharing is a common function of most PC LANs. A network
disk to be shared is normally mounted on the local workstation and accessed as if
it were a normal, local drive. For example, a workstation might have two floppy drives,
a local hard disk, and two network drives. The operating system and the application
programs should not be able to distinguish the mounted network drives from local
drives. This makes for relatively smooth integration.
Integration notwithstanding, the speed of performing network disk access is an
issue. The issue is not the raw access speed of the physical disk drive (although
it certainly is a factor), but how quickly and efficiently an access can be serviced
over the network.
A PC can serve as both a workstation and as a network file server. However, PCs
were originally designed as single-task machines, so only one operation could occur
at a time. When the CPU is busy (doing a spreadsheet recalculation, for example),
a network request would have to wait to be serviced. Newer PC operating systems are
now based on multithreaded, multitask-ing architectures, and are able to accommodate
several tasks at once (given powerful enough hardware). Still, larger LANs require
a system to solely function as a file server. These file servers do not need to run
the PC operating system. Thus, special operating systems were developed for network
file servers to maximize performance and minimize the potential for disk errors.
PC LAN Players
Both Microsoft and IBM offer networking solutions to go along with their PC operating
systems. Other networking products are available from Novell, Banyan Systems, and
other companies, which provide high-performance networks that are compatible with
an operating system over which they have no control.
Thus far, Novell has gained the greatest degree of acceptance and use in the corporate
market. In a traditional Novell environment, one or more high performance computers
are dedicated as the file servers. In terms of network-level communications, Novell
has implemented its own protocols, named the Internetwork Packet Exchange (IPX)
and the Sequenced Packet Exchange (SPX), that run on top of IPX. Novell's
software offering is referred to as NetWare. Several different implementations
are available to accommodate different networking scenarios. Because the file server
is central to the network, it must offer high performance.
The greatest changes in the PC networking arena are driven by the need to integrate
PC information with minicomputer/mainframe information. As more and more devices
reside on the same physical LAN, it becomes more difficult to overlook their inability
to communicate with one another. Some of the most widely-used PC LAN operating systems
include:
- Banyan VINES. Banyan Systems provides many of the same functions as NetWare,
but Banyan's VINES (VIrtual NEtwork Software) products run with existing network
standards. Thus, unlike Novell, which implements its own transport-layer protocol,
VINES can run with TCP/IP, SNA, and other networking protocols. VINES is similar
to Novell's NetWare in its use of servers, but Banyan claims that it is more unstructured
and open, and therefore easier to use.
- Novell NetWare. For many years, Novell NetWare was the dominant file and
print server in the PC LAN arena. NetWare runs in a designated server system and
communicates with a variety of client systems (PC, Mac, UNIX) using either the IPX
or TCP/IP protocol suite. Novell NetWare is the seasoned veteran of the industry,
and has established a strong, loyal following in the corporate market. One of the
key technological advantages of the current 4.x line of NetWare products is NetWare
Directory Services (NDS). NDS is a global directory service designed to manage
LAN-based resources in large, enterprise-class environments. Although Novell went
through a series of corporate twists and turns in the mid-1990s, the company has
since refocused itself on its core NetWare technology.
- Windows NT. For years, Microsoft stayed out of the networking business.
However, when Microsoft acquired 3Com's networking PC LAN technology, it began to
integrate networking services into its operating system products. The first attempt
at this integration was Windows for Workgroups, which was a difficult product because
of the underlying DOS component. When Microsoft designed Windows 95 and Windows NT,
however, it seized the opportunity to integrate core networking services right into
the operating system. Microsoft took two tracks here, pushing peer-to-peer (workgroup)
resource sharing via Windows 95 and Windows NT Workstation, and enterprise-scale
file, print, and application serving via Windows NT Server.
Refer to Chapter 9, "PC LAN Network Operating Systems," for more information
on these three key PC LAN operating systems.
Server Alternatives
Although Windows dominates the corporate desktop, UNIX is still widely used as
a server platform due to its strong performance and robust features. Business-critical
servers must be able to deliver high-end features and run the company's transaction-based
applications. They also must be scalable enough to become part of a distributed network,
which replaces mainframe and minicomputer-based networks. Additionally, as a mainframe
replacement, a business-critical server needs to support security and systems management,
and must be able to interoperate with other dissimilar resources throughout the enterprise.
Specifically, it must be able to integrate with Windows PCs to make these critical
resources available to PC users.
The Common Desktop Environment (CDE) is part of the Common Operating System
Environment (COSE, pronounced "cozy") agreement, one of many attempts at
unifying the UNIX market. Although COSE itself never took off, CDE has achieved some
success--most notably, all the major UNIX vendors agreeing on the Motif interface
as the basis for the Common Desktop Environment as well as establishing several other
commonalities. Long overdue, this simple agreement will help make UNIX easier to
run in a multivendor environment.
64-bit API
Another unification attempt involves an initiative to develop a common 64-bit UNIX
API. Several UNIX vendors, including Intel, HP, SGI, DEC, Compaq, IBM, Novell, Oracle,
and Sun, are hoping that the common specification will reduce more of the problems
developers encounter in having to write for
different implementations of UNIX. The alliance will build the 64-bit specification
from existing 32-bit APIs, and will comply with existing standards, including CDE.
Despite its fractured nature, UNIX has a number of strengths. Many tools are available
for free, and there are plenty of UNIX experts out there looking for something to
do. UNIX is a strong platform for use as an application server. UNIX also offers
the advantage of easy remote access--nearly any PC or Macintosh running any operating
system can be made to work as an X Window terminal.
Finally, note that if you're on a tight budget (or have no budget at all), a UNIX-like
32-bit operating system called Linux (based on Berkeley Software Distribution,
or BSD, UNIX code, which was developed at the University of California at Berkeley)
is freely available. Linux is a noncommercial operating system, although implementations
of Linux are available from commercial vendors complete with technical support. It
might require some long hours and customization, because like most freeware products,
it has a few rough edges. However, Linux has a number of fans, and a large informal
support network offers technical help and advice, freeware products, and other services.
PC/Minicomputer/Mainframe LAN Integration
Although practicality might dictate that PC LANs and minicomputer/mainframe LANs
share a common topology and discipline, no law dictates that they must communicate
with one another on that same LAN. In fact, multiple sets of computers can implement
different networking services, and each set might lead its life of quiet desperation
independently of the other sets.
But when cross-communications are mandated by some foolish need or frantic demand,
the broad scope of choices normally available in the data processing market narrows
rapidly. In looking to integrate PC functions with the larger systems capabilities,
you have to make some basic choices. Which architecture will be promoted over the
others? Will the larger systems become servers for the PCs? Will the PCs become terminals
to the larger systems? Or will a third LAN structure be implemented in which both
the PCs and large systems conform to a common standard?
Most approaches provide similar results (shared disk space and shared printers),
but each approach has its pros and cons:
- System Servers. If the larger systems become servers for the PC LANs,
the PC file structure is imposed upon the larger system. In most cases, an area of
the system disk is then unavailable to native system users. On the plus side, the
PC LAN server information can be backed up along with all of the other system information
(one procedure can address both needs). Manufacturers that support this approach
include Digital Equipment and Novell. Digital markets a product that enables VMS
systems to store MS-DOS files, and Novell has released NetWare for SAA, NetWare for
DEC Access, and NetWare Connect. NetWare Connect provides a number of connectivity
options: It permits remote Windows and Macintosh computers to access any resource
available to the NetWare network, including files, databases, applications, and mainframe
services; and it permits users on the network to connect to remote control computers,
bulletin boards, X.25, and ISDN services.
- Terminal Emulation. When PCs emulate native devices to the larger system,
they lose some of their intelligence by emulating unintelligent terminals. File sharing
in this en-vironment is normally supported via file transfers between PCs and the
larger system. This architecture is very centralized and favors the larger system
by keeping PC access to a minimum. Digital, HP, IBM, and Sun all have sets of products
that provide this type of centralized integration.
- A number of third-party products are on the market to connect TCP/IP-based networks
to mainframe and midrange hosts, potentially giving PC users access to CICS applications
and facilitating file transfer between the LAN and the mainframe system.
- Peer Connections. Introducing a new set of services to accommodate both
small and large systems establishes an environment in which all computing nodes are
peers. This approach, however, consumes additional resources (memory, CPU, disk)
on each com-puter that participates in the shared environment. In such a system,
TCP/IP might be implemented to allow file transfer between any two systems, to provide
electronic mail services to all systems, and to enable the PCs to access the larger
systems as if they were terminals.
All of these approaches share one fundamental concept: The application the user
must be accessed at its native location. Therefore, to run a minicomputer program,
you must log onto the minicomputer and have proper authority to run it. Similarly,
to run a microcomputer program, you must mount and access the physical or logical
disk where it resides. In both cases, the user must find a path to the remote application.
This concept is changing, however, with the advent of distributed client/server computing
architectures.
The Client/Server Model
To create more meaningful integration between PC LANs and LANs built on larger
systems, a few manufacturers have developed some new approaches. They noted that
the intelligence of the desktop device was rising increasingly, while the rule of
dedicated (dumb) terminals was slowly crumbling. Emerging was a new breed
of intelligent, low-cost, general-purpose computers that were quite capable of handling
some of the applications-processing load. In short, the PCs had arrived.
To take these microcomputers and dedicate them to the task of terminal emulation
was an obvious step in the evolution of the PC explosion, but was also, in many respects,
a mismatch of power to purpose. To make a PC emulate a terminal sacrificed the ability
of the PC to interact with data, and clearly a PC can perform data entry, do mathematical
calculations and store information for subsequent retrieval. But when a PC is emulating
a terminal, it performs none of those functions. Instead, it uses all of its own
intelligence and resources to emulate a dumb device. Therefore, it would seem reasonable
to let the PC take a more meaningful role in the processing of the data. But how?
Certainly the idea of distributed processing was nothing new. In fact, most operating
systems and networks have basic task-to-task communication facilities. But in this
case, the communications would not necessarily occur between similar computers. A
PC might need to initiate a conversation with a midrange, or a mainframe might need
to communicate with a PC. This was the interesting twist--how to implement a distributed
processing environment that took advantage of computing power wherever it was in
the network, without requiring all of the computers to use the same operating system
or even the same primary networking services.
What formed as a possible solution to this puzzle was the concept of client/server
computing. In the client/server scenario, the local computer (PC or a user's session
on a larger computer) acts as the processing client. Associated with the client is
software that provides a universal appearance to the user (be it a graphical, icon-oriented
display, or a character, menu-oriented display). From that display, you can select
the applications you want to use.
When a user selects an application, the client initiates a conversation with the
server for that application (see Figure 8.3). This might involve communications across
LANs and WANs or simply a call to a local program. Regardless of where the server
resides, the client acts as the front end for the server and handles the user interface.
Thus, the user is not aware of where the application actually resides.
FIG. 8.3 Client/Server Processing
Furthermore, the client/server approach is dramatically enhanced when used with
a windowing client platform. If, for example, the user is at a PC that is running
a multitasking system, multiple windows can be used to initiate multiple client sessions,
thereby enabling the user to hot-key between applications, with each application
potentially running on a different computer system. This is a vastly superior method
to having multiple terminals, each with a separate terminal emulation session logged
into a specific host and running a specific application with specific keyboard demands.
The client/server approach offers one consistent user interface for all screen and
keyboard activities.
CAUTION: Hot-keying between applications can be a tremendous boon
to end users, but if the network hardware is inadequate, this can cause performance
problems. Some administrators might choose to limit the amount of active applications
a user can have running at one time. Many network management systems give ad-ministrators
the ability to enforce a "clean desk" approach by establishing a maximum
number of simultaneous sessions.
When it was first described, client/server computing was intended as an enterprise
solution, where users at all levels could work cooperatively across platforms. Client/server
technology has gone a long way in enhancing departmental productivity, although further
advances must be made before it can live up to its expectations on an enterprise
level. One of the biggest challenges of implementing a client/server environment
is establishing bridges between all of the various heterogeneous elements. Typically,
client/server solutions offer only limited access to critical data. Also, because
the environment is by its very nature decentralized, managing the environment is
extremely difficult. In order for client/server to be useful as an enterprise solution,
it must be able to access large amounts of data distributed over a heterogeneous
environment and integrate it into a common report. This service is in fact being
provided by executive information system (EIS) software and data warehouse technology.
There are many factors involved in designing a server system in a distributed
computing environment. Application partitioning can follow one of three different
paradigms:
- Client-centric model. Also called a "fat client" system, this
model places all of the application logic on the client side. It requires higher-powered
desktop machines, and requires substantially more administrative chores. Multiple
copies of the applications, which have to reside on each and every client, must be
synchronized. Additionally, this can cause the network to bog down, and the fat client
system is vulnerable to security problems because of the unprotected client OS.
- Server-centric model. This model is easier to implement and less expensive
than the client-centric model. It does not put critical data at risk. However, this
model does not take full advantage of the Windows desktop. The client usually consists
of only a terminal, or a PC running a terminal emulator with a minimal GUI front
end.
- Distributed transaction model. This hybrid model places certain operations
at the client, where the end user needs to take advantage of multimedia, or other
features more common to the PC, and runs less intensive applications on the server.
Multitiered distributed systems can be used in larger situations. This model divides
the server logic across multiple servers, enabling functions to be divided between
branches or divisions. UNIX is best-suited for distributed computing, and many companies
put their critical operations on UNIX servers.
A newer model for client/server takes a three-tiered approach in order to avoid
both fat-client and fat-server situations. A three-tier client/server model separates
logic and compute-intensive calculations from the rest of the application. The first
tier includes the GUI, the middle tier covers the logic and calculation components,
and the third contains data management services. In some situations, the application
logic can even be replicated over multiple servers, so the server with the most resources
at a given time can handle a specific request for services.
Application development software vendors are starting to offer three-tiered development
products in addition to their traditional environments.
Client/server products are relatively new, although each major manufacturer has
its own applications architecture to implement client/server functions. Unfortunately,
each manufacturer's implementation is very much geared toward its own product offering.
If you're looking for an outside approach, X (Windows) marks the spot.
X Window Interface
By way of introduction, X Window strives to provide a common, GUI across systems.
Under X Window, each terminal or workstation is, in fact, an intelligent graphics
device that has multiple windows in it, each of which sponsors a different application.
Consistent with the client/server model, the full scope of X Window enables each
of these applications to reside on different systems.
Furthermore, because X Window is a third-party architecture, it is explicitly
targeted to provide connectivity among different manufacturers. Because the user
sees only one consistent interface, he or she is unaware of where the application
program actually resides.
X Window is also a contender in the battle for presentation standards for graphical
data. Specifically, X Window allows graphical data composed or stored on different
systems to be displayed on a common terminal. This arrangement is significantly better
than each manufacturer using its own format for graphics that will only display on
its own graphics terminal. Under most implementations of X Window, a manufacturer's
graphics format is converted to and from X Window's. As the popularity of X Window
rises, however, more manufacturers will begin to include options for storing the
data in the X Window's graphic format on disk, thereby eliminating any need for conversion.
The negative side of X Window is the relatively high cost for the workstations.
Because X Window requires graphics processing capabilities, the X Window workstations
are really specialized graphics computers that are far more expensive than the traditional,
character-mode (nongraphic) terminals. However, an X workstation is still often more
economical than a fully outfitted multimedia PC.
As PCs become less expensive and more widely deployed in the enterprise, X terminals
will continue to fall out of favor. There are still a significant number of X terminals
in use, but the market has reached its peak. Many companies are instead opting to
purchase inexpensive PCs and run X terminal software on them. PC X servers, on the
other hand, are gaining in popularity. X terminals are associated with UNIX, but
many X desktop users want to be able to access Windows applications. Fortunately,
X terminals can become Windows displays by deploying Windows NT-based software products
that permit an X device to function as a networked PC running Windows.
WAN Services
Although WANs are used for terminal access and file transfer, implementing these
services in a wide-area environment is not all that different from implementing them
in a local or metropolitan area. Therefore, viewing these services from the WAN perspective
does not shed much new light on the subject.
The area of office automation and electronic mail, however, is a different matter.
Here, a WAN is the best solution for tying together computer systems and LANs from
different manufac-turers for the purpose of enhancing human-to-human communications.
Certainly, the fact that the communications links might not have speeds measured
in millions of bits per second does not deter the effectiveness of electronic mail.
Even the case where electronic mail goes through packet-switching networks and experiences
delays at the packet level does not have an adverse effect.
But implementing office automation and electronic mail between systems is not
a trivial task. For office automation, complex documents must be exchanged between
systems that do not recognize each other's native file formats. Similarly, a mechanism
is needed to enable one system to look across the network and see which files are
where (this is also useful when performing general-purpose file transfers).
For electronic mail, the requirements are even more complex. Mail must be distributed
to users who are often unknown to the system where the mail originates. The format
for messages and documents might be different from system to system. And finally,
the each type of system might use a totally different distribution technique.
This section will look at the following standards and services in this emerging
area:
- DCA/DIA. Developed by IBM, the Document Content Architecture and Document
Interchange Architecture have become de facto standards for exchanging documents
between different manufacturers' systems.
- X.400. X.400 is a standard for interfacing diverse office automation systems.
The number of products supporting this standard is increasing dramatically.
- X.500. X.500 is a standard for multivendor directory and file resources.
Increasing acceptance of this standard has given birth to a number of X.500-compliant
products. The directory services features of some network operating systems, including
NetWare 4.x, Windows NT 5.0, and VINES, is based on this technology.
Document Content and Interchange
Architectures
Even though from an application perspective the format of data is normally kept
at a respectable distance from data communications and networking issues, the explosion
of word processing and office automation tools has led to some key developments in
the area of interoperability. The concern is not how the data gets from one system
to another, but what format the data is in when it arrives.
For example, document interoperability is needed when two users are working on
the same document, but each is based on a different computer system. Even in the
simplest case where each user can work on his or her own separate section of the
document, the final integration of each user's work still poses a problem. What if
the two users needed to trade the document back and forth, each person adding his
or her own edits and comments? Moreover, imagine how much more complicated the situation
would be if more than two users were concurrently working on the same document.
IBM sought to address this dilemma with DCA/DIA. While the DIA addresses a much
broader scope (specifically, the movement of documents among and between systems),
the DCA has become a modern standard for document exchange. Specifically, the DCA
defines two types of documents:
- Revisable-form documents. Contains the original document and its history
of edits. This tracking of revisions not only allows changes to be removed, but more
important, provides details on all changes made to the document. This type of historical
tracking is often critical for maintaining contracts, specifications, and other documents
of similar importance. Most modern word processors support the ability to convert
to and from the DCA revisable-form document format.
- Final-form documents. The result of all edits; it is no longer truly revisable
because the history of edits has been removed. The final-form document format is,
however, supported by more hardware and software manufacturers, mostly because it
is the easier of the two formats to implement.
Thus, DCA provides a common format that documents originating on different systems
can convert to and from.
X.400
The X.400 standard specifies how to exchange electronic mail among diverse systems.
In the context of X.400, electronic mail includes message exchanges, fully functional
file transfers, and the transport of video images. Like X.25, X.400 is a standard,
not a product, but X.400 products have taken to using the X.400 banner as an noun
("this product supports X.400") as opposed to a statement of compliance.
And as with IBM's DCA/DIA approach, X.400 includes a set of formats for the mail
it carries.
Within the structure of X.400, each user interacts with a User Agent (UA).
The UA is normally a software package that interfaces between the user and the X.400
electronic mail network. In the minicomputer/mainframe world, the UA could be, for
example, Digital's ALL-IN-1, IBM's OfficeVision, or HP's Open DeskManager.
UAs never communicate directly with other UAs; instead, they forward their mail
to a Message Transfer Agent (MTA). The MTA then forwards the message to a
UA or to another MTA if the final location for the electronic mail is not in the
network domain of the first MTA (see Figure 8.4).
FIG. 8.4 X.400 User Agents and Message Transfer
Agents
MTAs reroute mail until it reaches its final destination. These MTA routes are
collectively referred to as the Message Transfer Systems (MTS). Helping the
MTAs move the data within the MTS is an additional utility called the Reliable
Transfer Server (RTS), which assists the MTA in determining the best route.
The X.400 standard has taken on a new life outside the dominion of the OSI Reference
Model. Given the popularity of X.400 in the private sector, many computer manufacturers
have adopted X.400 as a means of interfacing their office automation package with
other vendors' office automation packages (providing they also support X.400). Thus,
the X.400 standard is quickly giving birth to a large number of wide-area electronic
mail networks.
The X.400 Application Program Interface Association (XAPIA) has released
a new version of the Common Messaging Call (CMC) API. CMC 2.0 provides for
greater interoperability between collaborative applications from different vendors.
It supports features such as workflow, document management, and electronic data interchange;
Version 1.0 of CMC only provided the capability to send and read messages, and to
translate names into messaging addresses.
X.500
Whereas X.400 tackles electronic mail, X.500 focuses on user and resource directory
services in large heterogeneous networks. While each computer manufacturer provides
these services within its own proprietary network, the same services are, for the
most part, unavailable when the network is composed of incompatible systems from
different manufacturers. The X.500 standard is intended to provide this type of service
within a global, multivendor network. Unlike the X.400 standard, X.500 has a relatively
low profile because it is deeply integrated within other products and services that
require multivendor access. For example, the X.400 electronic mail standard relies
on the X.500 standard for its directory services.
The main point here is that a large company is likely to want a single, global
directory for all users throughout the enterprise. This single directory might encompass
multiple LAN systems. There are some difficulties involved in managing a global directory,
including synchronization. Directory synchronization makes sure that each LAN directory
is aware of any change in the enterprise.
There are a number of solutions for establishing a global directory:
- StreetTalk. One of the earliest directories, StreetTalk is part of the
Banyan Systems VINES network operating system. The Universal StreetTalk directory
service is being incorporated in equipment from a number of hardware and software
vendors, including Cisco Systems, Oracle Corp., and SAP AG. However, until recently,
Universal StreetTalk required a Vines server; but in order to compete in an increasingly
tough market, Banyan has decided to unbundle its network services from Vines and
offer them separately.
- NDS. Novell has now added the same facility for NetWare networks, in the
NetWare Directory Service (NDS) product.
- Windows NT 5.0. Microsoft joined the fray late in the game, but plans
to add global directory services in the newest release of Windows NT.
- NIS+. Sun's Network Information Services Plus (NIS+), bundled with several
different UNIX operating systems, also competes in the global directory market. NIS+
is based on Sun's older NIS product, which was known as Yellow Pages. NIS+ uses a
tree-based hierarchical directory, and keeps directories synchronized by transmitting
only changes. The older version sent the entire directory map in the process of synchronization.
Although each of these vendor solutions has proprietary components, they are all
moving toward supporting X.500 as a means of exchanging directory information between
them.
X.500 Lite X.500 Lite, also known as Lightweight Directory Access Protocol
(LDAP), presents users with a faster way to get data out of an X.500 directory.
The full X.500 Directory Access Protocol (DAP) is much too processor-intensive
to run on a standard desktop PC. Like DAP, LDAP takes information out of the X.500
directory service in response to queries. However, there are a few differences between
DAP and LDAP that make LDAP much more bandwidth-conscious. With LDAP, there is a
limit on the number of replies that can be returned in response to a query. LDAP
also differs from DAP in that no referrals are allowed. Under DAP, if a server is
unable to fulfill a query, a referral technique enables the search to continue on
other servers. LDAP is easier to implement and use, and several vendors have announced
plans to support the new standard, including Novell, Banyan Systems, Lotus Development
and Netscape Communications.
LDAP supports these operations: search, add, delete, modify, modify RDN, bind,
unbind, and abandon. It does not include the list and read functions found in the
full X.500 implementation; rather, list and read are approximated with the LDAP search
function.
An LDAP database record includes basic information, such as name and e-mail address,
but can also include additional fields, such as address, phone, and public encryption
key. LDAP was created at the University of Michigan under an NSF grant. A consortium
of 40 companies have announced support for LDAP. If this type of support continues,
the dream of an Internet-wide directory might eventually become a reality.
ON THE WEB:http://www.umich.edu/~rsug/ldap/ LDAP clients
for several platforms are readily available from the University of Michigan Web site.
Emulation
Emulation is a software layer that enables one type of system to run applications
meant for another type of system. Emulation software can display a PC window on a
UNIX workstation screen, enabling the UNIX user to work as if she was working on
a standard PC. Software that does the reverse (that is, it enables a PC to emulate
UNIX) is also available. However, most emulation solutions suffer from sluggish performance
and limited compatibility. There are several commercial emulation packages available.
Some of the popular ones are the Macintosh Application Environment, which is a Motorola
68K emulator; Wabi (Windows application binary interface) from SunSoft (Chelmsford,
Massachusetts); and Insignia Solutions Inc.'s (Inglewood, California) SoftWindows.
Wabi and SoftWindows are x86 emulators that run on UNIX workstations.
Middleware
Application-to-application communications in a multivendor network can often be
achieved through a new type of software, termed middleware, that sits between
the application and the operating system. Developers can use it to accommodate multiple
protocols, platforms, and languages, and exchange messages between applications.
The goal of middleware is to give users seamless access to applications and data,
regardless of platform or operating system. There are several types of middleware,
including network gateways, Message-Oriented Middleware (MOM), remote procedure calls
(RPCs), object request brokers (ORBs), and transaction processing (TP) monitors.
With RPCs, a client process calls a function on a remote server, waits
for the result, then continues processing after the result is received. This synchronous
model contrasts with the asynchronous techniques used with MOM and TP products, which
queue messages. Synchronous middleware products are used in situations where bi-directional,
real-time communications is essential; asynchronous communications are used where
near-real-time is acceptable and high volume and speed are important.
MOM products handle message queuing in one of three ways:
- Nonpersistent queuing stores queue data in volatile memory, which increases
performance, but is at risk of being lost in the event of network failure.
- Persistent queuing is slower than nonpersistent, but more secure. This
type of queue data is stored on disk.
- Transactional queuing is also disk-based, but includes a mechanism for
verifying that messages have been received.
TP monitors can maintain transactions over multiple servers, and are used
in high-volume, critical environments.
Middleware is a vague term, and can have different meanings depending on the situation.
Generally, middleware sits between the client and server, but it can also sit between
the application and the database. Some middleware is based on messaging, while others
are replication-oriented or transaction-oriented.
Object request brokers (ORBs) are not strictly middleware, but they might
have a significant impact on the middleware market as the Common Object Request
Broker (CORBA) architecture matures. One limitation of the ORB model is its limitations
in connecting legacy systems to new architectures. Middleware is largely a custom
business, with little available in terms of off-the-shelf, ready-to-run products.
For more about CORBA and object technology, refer to Chapter 13, "Software Considerations."
Advances in middleware technology are permitting more end users to share information,
regardless of the underlying network and operating system platform. For example,
Teknekron Software Systems, Inc.'s Rendezvous Software Bus works as a communications
software layer, which is able to translate data from different applications into
a common format. Applications wanting to access data from a different application
merely plug into the bus to access data from any source. With tools such as Rendezvous,
it is no longer necessary to establish individual point-to-point links between many
applications.
IBM's MQSeries middleware, a messaging and queuing technology, lets users establish
links between client/server applications and legacy data. IBM has added object-oriented
technology and asynchronous communications features to the middleware, which offers
direct links to legacy TSO, IMS, and CICS packages. It is used to simplify the process
of establishing application-to-application communications links, and permits applications
to communicate asynchronously.
Novell's Tuxedo transaction processing monitor is being positioned as a key middleware
tool for connecting Windows NT, UNIX, and mainframe systems into NetWare networks.
With Tuxedo, developers can create distributed applications that are operating system-independent.
Fitting NetWare for a Tuxedo
Novell has established a partnership with BEA Systems (Sunnyvale, California) for
future development of Tuxedo. The partnership will focus on integrating Tuxedo with
NetWare. Tuxedo's namespace will be replaced with NetWare Directory Services (NDS),
which will give NetWare users easy access to dozens of applications and processes
running on multiple platforms. Under this scenario, a NetWare user could merely click
an object in the NDS tree that represents a process or application running on any
server. Consequently, users would no longer have to run live sessions in UNIX, NT,
and NetWare simultaneously. Tuxedo would instead monitor calls to specific applications.
SNA-LAN Internetworking
As internetworks grow in size and complexity, many corporations are recognizing
the need to integrate legacy data and applications with their LANs. Simply eliminating
mainframes completely in favor of a distributed, client/server environment might
initially sound attractive at first, but can be an enormously complex and costly
procedure, especially if several mission-critical programs and datasets reside on
a mainframe or midrange platform.
IBM has embraced the necessity for integration by enabling NetWare to be integrated
with the AS/400. A new board-level file server for the AS/400 adds NetWare support
to the platform. Previously, the AS/400 could only run IBM's own OS/2 LAN Server
network operating system. Although LAN Server is faster than NetWare, NetWare integration
is an important step because of NetWare's large presence. The addition of NetWare
support will let the AS/400 run business applications perform file and print sharing,
and eliminate costs by cutting out the need for additional PC servers.
There are a number of software options for connecting 32-bit Windows desktops
to mainframe and midrange platforms. Vendors such as Wall Data, NetSoft, and Walker
Richer & Quinn are offering connectivity software for this purpose. Wall Data
is planning Windows 95 and Windows NT versions of the Rumba Office product; IBM is
also getting into the game with the Personal Communications product family, available
for Windows 95. Others include Attachmate's Extra Personal Client 6.0, NetSoft's
NS/Elite and NS/Router, and WRQ's Reflection 3270 and Reflection AS/400. Many of
these products offer much more than plain terminal emulation. Many support OLE 2.0
technology, and offer Windows users direct access to legacy databases.
IBM's 3172 Interconnect Controller Model 390 for the Network Control Program-Multinetwork
Server (3172-390) attaches to a 3745 front-end processor, and is used to off-load
SNA and TCP/IP session establishment routines from the mainframe. This can significantly
decrease WAN traffic, because administrative traffic no longer has to be sent across
the WAN. The 3172-390 can be used as a tool to migrate to APPN. It supports TCP/IP
routing as well as APPN, although this support can also be achieved with IBM's 3746-950.
IBM's front-end processor family, the 3746 Nways Multinetwork Controllers, can
help you with the task of running SNA, APPN, and LAN traffic to the mainframe. Two
models are available: the 900 and 950. The 3746-950 supports APPN, dependent LU Requestor
(dLUR), and Enterprise Systems Connection mainframe links. dLUR is used to permit
SNA devices to communicate over an APPN network. A later release of the 3746-950
will include support for TCP/IP routing protocols. IBM is also expected to add ATM
and ISDN support.
The larger 3746-900 is used primarily in scenarios where you are migrating to
APPN and deploying a multiprotocol backbone. The 3746-900, an expansion unit for
the 3745 front-end processor, lets you retain your original investment in 3745s while
participating in an APPN network.
One of the biggest factors in SNA/LAN integration is the availability of network
management. Cisco Systems Inc. and Cabletron Systems Inc. have both released new
products for managing routed networks carrying both SNA and LAN traffic. Cisco's
CiscoWorks Blue and Cabletron's BlueVision 2.0 can consolidate management of an SNA/LAN
internetwork.
One problem in integrating SNA with other systems is storage management. Storage
Technology Corp. (Denver, Colorado) has a product called Enterprise Volume Manager,
which unifies UNIX and mainframe storage management by allowing combined MVS/UNIX
systems to share a single tape transport and library. The company has plans for multiplatform
storage management products that accompany tape, disk, and solid state media. The
Expert Volume Manager software is deployed by MVS users as a supplement to
their tape management system and hierarchical storage management software, and brings
many of the benefits of UNIX to the MVS environment.
Options for connecting Windows 95 to SNA environments emerged almost as soon as
Win-dows 95 hit the streets. Microsoft's Windows 95 client for Microsoft SNA Server
is an SNA gateway that lets Windows NT servers work as a bridge between Windows clients,
IBM mainframes, and AS/400s. The Windows 95 client software serves as a platform
for SNA applications running on Windows 95 and connecting to IBM hosts. Windows 95
Client for SNA Server provides Windows 95 users with access to the IBM mainframe
for AS/400 applications and data. Those sites with large investments in IBM host
systems can provide a Windows 95 desktop to their users, while still retaining their
legacy systems. The client includes an ODBC driver that permits users to access all
IBM DB2 databases. Windows 95 clients can also download large host files.
Third-party products are also widely available for connecting Windows 95 to host
platforms.
© Copyright, Macmillan Computer Publishing. All
rights reserved.
|
