ch08.htm

this describes managing multivendor networks

	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.<BR>
	<BR>
	
	<LI><I>Server-centric model.</I> 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.<BR>
	<BR>
	
	<LI><I>Distributed transaction model.</I> 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.
</UL>

<P>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.</P>
<P>Application development software vendors are starting to offer three-tiered development
products in addition to their traditional environments.</P>
<P>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.
<H3><A NAME="Heading9"></A><FONT COLOR="#000077">X Window Interface</FONT></H3>
<P>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.</P>
<P>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.</P>
<P>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.</P>
<P>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.</P>
<P>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.
<H2><A NAME="Heading10"></A><FONT COLOR="#000077">WAN Services</FONT></H2>
<P>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.</P>
<P>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.</P>
<P>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).</P>
<P>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.</P>
<P>This section will look at the following standards and services in this emerging
area:

<UL>
	<LI><I>DCA/DIA.</I> Developed by IBM, the Document Content Architecture and Document
	Interchange Architecture have become de facto standards for exchanging documents
	between different manufacturers' systems.<BR>
	<BR>
	
	<LI><I>X.400.</I> X.400 is a standard for interfacing diverse office automation systems.
	The number of products supporting this standard is increasing dramatically.<BR>
	<BR>
	
	<LI><I>X.500.</I> 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.
</UL>

<H3><A NAME="Heading11"></A><FONT COLOR="#000077">Document Content and Interchange
Architectures</FONT></H3>
<P>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.</P>
<P>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.</P>
<P>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:

<UL>
	<LI><I>Revisable-form documents.</I> 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.<BR>
	<BR>
	
	<LI><I>Final-form documents.</I> 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.
</UL>

<P>Thus, DCA provides a common format that documents originating on different systems
can convert to and from.
<H3><A NAME="Heading12"></A><FONT COLOR="#000077">X.400</FONT></H3>
<P>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
(&quot;this product supports X.400&quot;) 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.</P>
<P>Within the structure of X.400, each user interacts with a <I>User Agent (UA)</I>.
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.</P>
<P>UAs never communicate directly with other UAs; instead, they forward their mail
to a <I>Message Transfer Agent (MTA)</I>. 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).</P>
<P><A HREF="javascript:if(confirm('http://docs.rinet.ru:8080/MuNet/ch08/08fig04.gif  \n\nThis file was not retrieved by Teleport Pro, because it was redirected to an invalid location.  You should report this problem to the site\'s webmaster.  \n\nDo you want to open it from the server?'))window.location='http://docs.rinet.ru:8080/MuNet/ch08/08fig04.gif'" tppabs="http://docs.rinet.ru:8080/MuNet/ch08/08fig04.gif"><B>FIG. 8.4</B></A> <I>X.400 User Agents and Message Transfer
Agents</I></P>
<P>MTAs reroute mail until it reaches its final destination. These MTA routes are
collectively referred to as the <I>Message Transfer Systems (MTS)</I>. Helping the
MTAs move the data within the MTS is an additional utility called the <I>Reliable
Transfer Server (RTS)</I>, which assists the MTA in determining the best route.</P>
<P>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.</P>
<P>The <I>X.400 Application Program Interface Association (XAPIA)</I> has released
a new version of the <I>Common Messaging Call (CMC) API</I>. 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.
<H3><A NAME="Heading13"></A><FONT COLOR="#000077">X.500</FONT></H3>
<P>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.</P>
<P>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