Host Integration Server (HIS) is designed to provide connectivity between network client computers and host systems. Host systems refers to large, centralized-computing machines such as mainframe computers and IBM AS/400 midrange systems. When working with HIS, you have to keep in mind how host systems are designed to work: All of the computing work actually takes place on the host system itself. The host system assumes that client devices are dumb terminals, which are little more than a keyboard and display device. The host system produces all of the screen displays and transmits them to the client device, and then accepts keyboard input from the client device.
Note
The operation of host computing is nearly identical to Windows 2000’s own Terminal Services, where client computers send keystrokes and mouse clicks to the terminal server, and display the screen information created by the terminal server. The biggest operational difference between Terminal Services and host computing is that mainframes and AS/400s usually generate all-text displays and don’t require a mouse, where Terminal Services generates a Windows-based display and works best with both a keyboard and a mouse. Of course, the technologies underlying host computing and Terminal Services are entirely different.
In a traditional host computing environment, client devices are connected directly to the host system through specialized coaxial cabling. Client devices communicate with the host system using a protocol called 3270 (or a newer alternative, 5250), which is a protocol created by IBM and designed to carry display and keystroke information between the client device and host system. Newer host systems, such as AS/400s, can also use Advanced Peer-to-Peer Computing, or APPC, which requires more complex client devices that can perform their own computing tasks.
In a 3270 environment, client devices are referred to as logical units, or LUs. More accurately, they are referred to as dependent LUs, because they can only operate when connected to a host system. LUs must not only be connected to the host computer, but must also be defined and allocated on the host computer, which enables the host to recognize the LU and communicate with it. Most host systems recognize display devices (designated LU 2), printers (designated LU 1 or LU 3), and applications (designated LUA). In an HIS environment, LUs aren’t dedicated client devices, but are instead software emulators that run within the Windows operating system. These emulators, called terminal emulators since they mimic the functionality of a hardware client terminal, connect to an LU allocated on an HIS computer. HIS in turn establishes a session with the appropriate LU on the host system, completing the connection path between the client computer’s terminal emulator and the host system. In effect, then, users can have a software-based client device running within a window, enabling them to access the host system while running other Windows-based applications.
One advantage that HIS offers over dedicated hardware terminal devices is LU pooling. Rather than configuring individual LUs for each client, HIS enables you to configure a pool of generic LUs, and enables you to decide which clients can connect to the pool. LU pools are more efficient than individual per-client LUs, particularly if your users access the host system intermittently throughout the day, rather than constantly.
A variant of the 3270 protocol, TN3270, enables intelligent terminals (such as Windows-based terminal emulators) to access host systems by using the Telnet protocol. TN3270 access is often more efficient than regular 3270 access, although it works similarly: TN3270 emulators connect to LUA-type LUs configured on HIS, and HIS provides a session to the host system.
Note
TN3270 access provides more efficient network communications than 3270 access. Also, because TN3270 relies on TCP/IP, it’s easier to pass TN3270 traffic through devices such as firewalls.
APPC environments are usually associated with IBM AS/400 midrange computers, which are designed to use APPC. However, newer mainframe operating systems may provide APPC support as well. In either case, the APPC protocol is designed to run over IBM’s SNA network protocol, and makes each device on the network responsible for managing its communications with other devices. This peer-to-peer communication is also referred to as Advanced Peer-to-Peer Networking, or APPN (IBM has never been shy about creating acronyms to go along with its computing products). In an APPN network, each device is referred to as a type 2.1 physical unit, or PU. Host systems must still contain LUs to define the logical communications with a physical device, and in an APPN network those LUs are referred to as type 6.2 LUs, or APPN LUs. HIS provides terminal emulators for APPN environments, and those emulators mimic the functionality of a type 2.1 PU.
The APPC protocol is most commonly used to carry 5250 display-protocol traffic. 5250 is very similar to 3270, but contains additional functionality to allow full-color displays and other newer features. A TN5250 variant which relies on the Telnet protocol is also available. These two display protocols are used by APPC/APPN-compatible devices to transmit screen displays and keystrokes between the host system and PUs. The terminal emulators provided with HIS use the 5250 display protocols to communicate with the host system. Figure 11.1 shows how HIS acts as a gateway for terminal emulation.
HIS provides a number of communications options for connecting to host systems, including
In all cases, the physical connection must be made through a supported third-party hardware adapter. HIS’s documentation provides a list of supported adapters. HIS provides communications support for five standard SNA protocols:
LU1 and LU3 for printers
LU2 for 3270 displays
LU 6.2 for APPC connections (including 5250 displays)
LU 0
LUA for applications
HIS includes Network Integration Services (NIS), which is the layer of HIS that provides networking connectivity to hosts. NIS is not necessary if you plan to connect to your host system over TCP/IP (which is natively supported on most host systems, including AS/400s). HIS’s application and data integration services (discussed in the next section) support operation over TCP/IP.
Shared Folders is a feature that allows host systems to act as file servers, effectively enabling client computers to map a network drive letter to a folder on the host system. The HIS client software enables client computers to connect directly to host systems and take advantage of shared folders. For clients not running the HIS client software, an HIS computer can act as a gateway, making the host system’s shared folders appear to be standard Windows shared folders, which network clients can access through a UNC or mapped drive letter. Figure 11.2 shows how the gateway service operates.
The shared folders gateway service communicates over APPC, using a standard APPN LU. In addition to hosting the gateway service, the HIS computer can also act as a standard Windows file server, enabling clients to access both Windows-based and host-based shared files from the same server computer.
HIS provides similar integration capabilities for database access. HIS includes OLE DB data access providers which can communicate with AS/400, VSAM, or DB2 database systems located on a host. In each case, the OLE DB provider runs on data clients, along with other OLE DB providers (such as providers for Access or SQL Server databases). The OLE DB providers communicate with an HIS computer, and HIS acts as a database gateway, translating the data access calls to the host system as needed. In effect, clients see the HIS computer as the database server, and the HIS computer acts as a gateway or proxy to the host-based data. Figure 11.3 illustrates HIS’s database connectivity model.
Note
DB2 is perhaps the most universal relational database, as IBM sells versions of DB2 that run on AS/400s, MVS, VSE, VM, AIX RS/6000, Sun Solaris, HP-UX, Digital-Compaq Unix, OS/2, and even Microsoft Windows. HIS can enable client computers to access DB2 running on any of these systems. HIS also includes an ODBC driver for DB2, in addition to the newer OLE DB provider for DB2.
HIS also includes Application Integration Services, which enables applications using COM transactions or message queuing to interact with transaction-based and queued services on host systems. For mainframe environments, HIS includes a COM Transaction Integrator (COMTI) for CICS and IMS systems, providing an interface between COM components and mainframe-based applications. The Integrator essentially enables Windows-based applications to use host-based applications as COM components, enabling you to leverage the services provided by your mainframe system in Web- and desktop-based applications. As with shared folders and database integration, HIS acts as the gateway to translate COM requests into the application programs running on the IBM MVS operating system. Figure 11.4 shows how the Integrator operates.
HIS’s MSMQ-MQSeries Bridge runs on both mainframe (MVS) and AS/400 environments, providing integrated application message queuing between Windows-based applications using Microsoft Message Queue Server (MSMQ) and host-based MQSeries message queuing. The Bridge enables mainframe-based applications to send messages to Windows-based applications, and vice-versa, allowing complete, seamless interaction between the two application environments. For example, you might use Commerce Server to create a Web-based online store, and create a COM component that places completed order information onto an MSMQ message queue. The Bridge could move that message into an MQSeries message queue, enabling a host-based application to retrieve the message and process the order for fulfillment, perhaps updating inventory levels, sending orders to a distribution center for physical fulfillment, and so forth. The host-based application might then place updated inventory information on an MQSeries message queue. The Bridge could move that message to an MSMQ message queue, enabling your Web site to retrieve the latest inventory information for use on your Web site. Figure 11.5 shows how the Bridge works.
HIS is one of the few .NET Enterprise Servers that more or less stands alone. HIS does require a domain environment—either Windows NT or Active Directory—to provide user accounts and authentication. HIS also requires specialized hardware, in many cases, to connect to host systems. Other than those basic requirements, however, HIS doesn’t need any other .NET Enterprise Servers or special prerequisite software in order to function.
HIS doesn’t specifically integrate with any of the other .NET Enterprise Servers. However, it does provide some useful services that other .NET Enterprise Servers can take advantage of. As I’ve already described, Commerce Server can benefit from both COM and message queuing integration to integrate host-based enterprise management systems with your e-commerce Web sites. This enables your Web site to integrate neatly with existing host-based order processing, fulfillment, and management systems, with relatively little additional software development required to achieve the integration. Commerce Server can also be set up to used host-based databases for catalogs and other data, rather than Commerce Server’s native SQL Server databases. If your host system already contains all of the data necessary to support Commerce Server, then you can save development time by simply using that data directly from the host.
| For more information on Commerce Server’s capabilities, see “Technology Capabilities,” Chapter 8, p. 230 |
SQL Server can take advantage of HIS’s OLE DB providers to seamlessly access host-based data. For example, you may want to use a host-based database as the source for a SQL Server–based data warehouse, using SQL Server’s Data Transformation Services (DTS) to move and transform data out of the host-based database and into the data warehouse. SQL Server can also assist with a phased migration away from host-based databases by incrementally moving data off of the host system and onto another database platform, such as SQL Server or Oracle.
| For more information on SQL Server’s capabilities, including DTS and data warehousing, see “Technology Capabilities,” p. 374 |
HIS’s primary purpose, however, is not to provide integration between host systems and other .NET Enterprise Servers, but to provide integration between host systems and other Windows-based applications and users.
Because HIS deals with complex—and often old—communications standards used by host systems, you have to be very careful to architect HIS in such a way that both your clients’ and your hosts system’s needs are met. In today’s distributed environments, clients are often spread out over very large areas. While host systems don’t necessarily make remote clients easy to deal with (often requiring complex remote controller connections), HIS can make distributed environments much easier to deal with by enabling clients to access an HIS server that is local to the client, rather than placing host access communications entirely across wide area network (WAN) connections.
HIS does not require specialized PC server hardware, although meeting the minimum hardware requirements is more important than with other .NET Enterprise Servers. Depending on your host system, of course, HIS may require specialized hardware to connect to the host. This hardware often takes the form of specialized add-in adapter cards that can be cabled directly to the host system. HIS is designed to run on Windows 2000 Server with at least Service Pack 1, or on Windows NT Server 4.0 with Service Pack 6a. HIS is a memory-intensive server application and, like any other application designed primarily for network communications, HIS will function best with lots of RAM installed in the computer. 128MB is the minimum amount of RAM, while 256MB is a more reasonable operating minimum. 1GB or more of RAM will provide the best performance.
Host systems must meet minimum requirements in order to communicate with HIS:
AS/400 computers must run OS/400 V3R2 or later and Distributed FileManager/MVS V1R2 or later.
To access DB2 on OS/390, you must be running V5R1 or later. On OS/400, you must have V3R2 or later. Additionally, you can provide direct TCP/IP access to databases on OS/390 systems with V5R1 or later, and on OS/400 systems with V4R2 or later.
Shared Folders capability requires at least OS/400 V2R3, System/36 5.1, or later. If you’re using System/36, you must also have the optional PC Support/36 PRPQ applied.
Client computers must run Windows 2000 Professional or later, or Windows NT Workstation 4.0 with Service Pack 6a or later. Client computers may also run Windows 95, Windows 98, or Windows Me. HIS provides terminal emulators for 16-bit Windows (Windows 3.x) and MS-DOS 6.22 or higher, as well.
HIS offers three basic deployment models: centralized, distributed, and branched. Each offers different advantages and disadvantages. This architectural flexibility allows you to implement the host access model that best meets your users’ needs. HIS also offers server groups, which can provide both load balancing and redundancy, providing more reliable, scalable access to your host systems.
Branched designs are the most popular way to implement HIS, and have been since the product’s earliest days as SNA Server. In a branched design, shown in Figure 11.6, clients communicate with a local HIS computer over normal LAN protocols, such as TCP/IP. HIS then communicates with the host system by using SNA over WAN connections.
Branched models enable clients to access the host system when relatively small amounts of bandwidth are available for the WAN connections. Branched models also work well for distributed HIS management, enabling local administrators to manage users and connections for their office directly on their local HIS computers. The local HIS server can also act as a domain controller, DHCP server, and so forth, minimizing the hardware investment required for small branches. Branched designs do not, however, enable you to use high-speed host system connections such as Ethernet. Branched designs generally use Synchronous Direct Link Control (SDLC) over the WAN line, appearing to the host as a single physical unit (PU) with up to 256 logical units (LUs) in the local office.
Another disadvantage of branched designs is that they work best if the WAN link is only carrying the HIS-to-host SDLC traffic, or if the routers involved in the WAN link can prioritize the SDLC traffic. If the WAN link is also carrying TCP/IP or other network traffic, SDLC traffic can become interrupted easily, dropping information between HIS and the host.
Figure 11.7 shows a centralized design, in which clients connect to HIS computers that are physically collocated with the host system. Remote clients communicate over WAN links using standard protocols, such as TCP/IP, and HIS communicates locally over normal host protocols.
Centralized designs enable you to centrally manage your HIS computers more easily from a main office, and enable you to take advantage of HIS server groups for load balancing and redundancy (which I’ll discuss later in this chapter). Centralized designs also enable HIS to connect to the host system over higher-speed connections, including Ethernet or direct channel connections. Channel connections offer the fastest possible connection between HIS and host systems, often enabling you to bypass front-end processors and connect directly to the host, depending on the host’s architecture. A centralized design does, however, require an efficient WAN environment capable of carrying client-to-HIS communications as quickly as possible. Client-to-HIS communications often require more bandwidth than HIS-to-host connections.
As shown in Figure 11.8, distributed designs combine elements from branched and centralized designs. Local offices maintain their own HIS computers, which feed traffic to centrally located HIS computers. Smaller remote offices may communicate directly with the central HIS computers, as in the centralized design model. The centralized HIS computers generally use high-speed connectivity to the host system, and use HIS’s Distributed Link Service to distribute links from the central HIS computers to remote HIS computers. The remote HIS computers communicate with the centralized computers over standard protocols such as TCP/IP.
Distributed designs offer most of the advantages of both centralized and branched designs, with higher hardware expenses to implement the additional servers. Distributed designs offer the most efficient and robust host connectivity, and are recommended for larger computing environments, or when clients need constant access to the host system.
HIS computers belonging to the same Windows NT or Active Directory domain can be grouped into logical subdomains. Each so-called SNA subdomain can contain up to 15 HIS computers, and you can configure an unlimited number of subdomains within a Windows NT or Active Directory domain. Each domain containing HIS computers will contain a least one subdomain, to which the computers will belong by default. The HIS computers within a subdomain share common configuration information and appear to HIS clients as a single giant HIS computer, providing a single set of LUs and LU pools, along with other resources.
Note
Subdomains play no role in user authentication within a domain. Subdomains’ only purpose is to logically group HIS computers.
All members of a subdomain must, naturally, belong to the same domain. Subdomain members also communicate with one another constantly, and should share LAN-quality connections to one another. Breaking a subdomain across different offices which share a WAN connection is a bad idea, because HIS performance will suffer. Therefore, HIS computers that are separated by WAN links should be placed in separate subdomains.
Each HIS computer in a subdomain can play one of two roles: Primary servers provide host connectivity to users and contain a master copy of the subdomain configuration file. Only one computer in a subdomain can act as primary. Backup computers contain a read-only copy of the subdomain configuration, and can be promoted to the primary role if the primary fails. Up to 14 backups can exist in a subdomain.
Note
Primary and backup subdomain servers do not need to be domain controllers in an NT or Active Directory domain, although they can be if you want them to. The primary and backup subdomain roles have no relationship to Windows NT or Active Directory domain operations such as user authentication or Active Directory replication.
Servers within the same subdomain can be configured to provide load balancing and hot backup. Load balancing enables clients to connect to a single virtual server, while spreading the clients’ workload across all available HIS computers. Hot backup enables the servers in a subdomain to take over the workload of a failed HIS computer in the same subdomain, transparently picking up the slack in the event of a server failure. Users are not aware of hot backup operations, making the entire process transparent.
Note
Hot backup capabilities have no relationship to the backup subdomain role. The primary/backup roles simply determine which server contains the writable copy of the subdomain configuration.
When properly configured, load balancing and hot backups are automatic within a subdomain.
For Microsoft-based environments, HIS is easily the most popular LAN-to-SNA gateway product available. In its prior incarnations as SNA Server, HIS gained a tremendous market share. Other LAN-to-SNA products exist, including
Bus-Tech SNA Gateways (www.bustech.com)
Eicon SNA Gateway (www.eicon.com)
Novell’s NetWare for SAA (www.novell.com)
Most of the other popular SNA gateways operate in DOS, or are designed for Novell NetWare environments. HIS is the only gateway that provides Windows NT or Active Directory domain integration, a suite of Windows-compatible terminal emulation clients, OLE DB data access, and other advanced features, all in one package.
In this chapter, you learned how HIS provides host connectivity for network clients, acting as a LAN-to-SNA gateway. You also learned how HIS computers can be added to a network environment in a variety of configurations, and how they can provide load balancing and hot backup failover capabilities for each other. Finally, you learned about the various services that HIS can provide to your network, including terminal emulation, database access, COM and message queuing integration, and so forth.