Previous | Table of Contents | Next |
For years, a major automotive manufacturer delayed PC LAN E-mail deployment in deference to the purported needs of the traveling executive. Senior managers wanted to be able to walk up to any company computer terminal, workstation, or personal computer anywhere in the world and know that they would be able to access their E-mail in the same manner. This implies a common look and feel to the application across platforms as well as common network access to the E-mail server. In this companys case, PROFS (OfficeVision/VM) was accessible through 3270 terminal emulators on various platforms. As long as SNA network access remained available, E-mail appeared the same worldwide. This IBM mainframe shop had few problems implementing this model.
The common platform model is not unique to IBM mainframe environments. Another manufacturer used the same technique with its DEC ALL-IN-1 environment distributed across multiple VAX hosts. As long as a DECnet network or dialup access was available, users could reach their home systems. The upside of this approach is that an individuals E-mail files are stored centrally, allowing for a single retrieval point. The downside was that the user had to be connected to process E-mail and was unable to work offline.
This strategy is not limited to mainframe and minicomputer models. A number of companies have standardized on Lotus Notes, Microsoft Mail, or Novells GroupWise. None of these products are truly ready for large-scale deployment without IT and network staffs having to plug the technical gaps.
The multiple backbone model assumes that an organization integrates its E-mail systems as though it were multiple smaller companies. The OfficeVision/VM system may connect via Advantis to reach the Internet and X.400 world. The cc:Mail WAN may have an SMTP gateway for access to the Internet and an ISOCOR MTA for access to the Message Router/X.400 gateway. All the various E-mail environments may have a proprietary Soft*Switch gateway for access to the IBM/MVS host so that everyone who needs to can access their OfficeVision/400systems (see Exhibit 8).
On the surface, this hodgepodge of point-to-point connections may seem a bit unwieldy, but it does have advantages. Users of cc:Mail can address Internet E-mail users by filling out an SMTP template rather than waiting until the cc:Mail administrator adds recipients to the cc:Mail directory. OfficeVision/VM users can fill out a simple address block within the text of their message to reach an Internet user. AS/400 users can send mail to an application that forwards the message on their behalf. The trouble occurs when the recipients of the AS/400 users try to reply they end up replying to the application that forwarded the message rather than the original sender, or originator, of the message.
Exhibit 8. The Multiple Backbone Model.
This architecture may still work. If each E-mail environment had its own gateway, network administration could offer multiple connections to the Internet.
The common backbone takes two forms:
The common hub involves a single switch that serves the users applications, thus serving their needs indirectly. Each E-mail environment has an application gateway that converts its environmental format to that of the common hub. Other systems are attached to this hub in a similar manner. Messages destined for dissimilar environments all pass through this central point to be sorted and delivered to their final destinations.
The distributed backbone takes the central hub and replaces it with two or more systems sharing a common application protocol. This solution offers the ability to deploy two or more less expensive systems rather than a single, more expensive system. Any system connected to any point in the backbone can use any other service (e.g., gateway) connected to that same backbone.
Network managers may decide to purchase a single hub and gradually add systems to form a distributed backbone. Should you decide to use a common backbone protocol like X.400 or SMTP, there is an advantage. Because these protocols are available from a number of vendors, the cc:Mail/X.400 gateway could connect to an X.400 system running in an HP9000, DEC/Alpha, or Intel/Pentium system all running the same protocols. It is possible to change distributed servers without having to change the gateways to these servers. Exhibit 9 illustrates three-tier flexibility.
A third approach is to use one central server or a distributed backbone of similar systems. In the central server/central hub approach all, E-mail environments use application gateways to connect to the central switch. There they are routed to their target environment.
Two-tier models may seem most convenient because they can use the offerings of a single vendor. One problem is that the system must use that vendors protocols for a long time. Three tiers allow the layers in the model to be changed, which allows for ease of transition.
Previous | Table of Contents | Next |