Microsoft Host Integration Server 2000 Product Overview
Summary: This white paper offers an overview of the integration components provided by Microsoft Host Integration Server 2000. These components enable data integration, application integration, and network integration of host-based systems with Microsoft .NET platform-based applications. (31 printed pages)
An estimated 70 percent of all corporate data is stored on host systems, such as IBM mainframe and AS/400 computers. Yet, increasingly, organizations rely on personal computers together with Web-based and Windows®-based applications for everyday productivity and line-of-business solutions. Companies have discovered that Web and Windows solutions often are easier to learn and quicker to implement than comparable host-based applications. To preserve their time and capital investments in host technology, organizations must either migrate all of their host-based resources to the Windows platforms, which can be expensive and time-consuming, or integrate their host-based resources with more efficient Windows-based and Web-based solutions.
Integrating host-based data and applications with Web-based and Windows-based applications offers significant benefits, including:
- Preserves investment in currently deployed host and PC technology while taking advantage of new architectures and products being offered for the PC platform.
- Allows rapid deployment of custom, high-performance solutions, using a choice of Windows-based development tools and leveraging a large pool of qualified developers who do not need to know or learn host programming.
- Lowers administrative resources and reduces hardware expenses, thereby reducing the total cost of ownership (TCO).
Whether companies want to create data warehouses to improve decision-making, develop Web-based applications that perform transactions using host-based data, or allow users to include archived data in reports, Microsoft Host Integration Server 2000 offers integration components that make it easy to achieve those goals.
To help its customers achieve these benefits, Microsoft has offered a host integration solution since 1990, when it introduced Communication Server 1.0 in partnership with Digital Communications Associates. Microsoft SNA Server 2.0, which followed in 1992, allowed system administrators to send local area network (LAN) and SNA networking traffic across the same network infrastructure.
Since then, Microsoft has continued to improve SNA Server based on customers' needs, developing it into a complex and feature-rich product. Host Integration Server 2000 builds on the strengths of SNA Server 4.0 and offers a range of mature technologies that help companies solve their host integration challenges.
Today's Web Solutions
Organizations frequently need to integrate their host systems with Web-based applications. This is why Microsoft offers products and technologies today that developers can use to build and deploy applications for the business Internet, which includes high traffic e-commerce Web sites, corporate intranets and enterprise supply chain integration. These products and key building technologies include the following:
- Internet Information Services 5.0 (IIS) in Windows 2000 with Active Server Pages (ASP), Microsoft Commerce Server 2000, Microsoft BizTalk™ Server 2000, Microsoft Internet Security and Acceleration Server 2000, and Microsoft Application Center 2000, for deploying dynamic, scalable, and secure Web sites.
- Microsoft Message Queuing (MSMQ) in Windows 2000 for reliable asynchronous transactions.
- Microsoft SQL Server™ 2000 for developing high performance Web stores and data warehouses.
- COM+ component and programming model for developing applications using popular development tools, such as the Microsoft Visual Studio® development system.
- Using Host Integration Server 2000 in combination with these products and technologies, companies can create highly manageable, scalable and reliable distributed applications that use existing host-based resources. Host Integration Server 2000 components and services all work together; they all share a common programming model, component model and tools and are designed to work with each other. This allows developers to focus on business problems, not systems integration. By tightly combining many of the common "plumbing" services into the Windows 2000 operating system and providing access points for the Microsoft Visual Studio development system to those services, developers can spend more time on building reusable business logic components and less on underlying maintenance code that is common to and necessary for all applications.
Microsoft recognizes that today's Web largely resembles mainframe systems, where vital data is locked up in centralized servers designed to publish information in often-predetermined HTML pages. Decision makers and knowledge workers are granted limited, often read-only, access to vital data, with little or no opportunity to interact with or edit this data using Web browsers.
Microsoft is creating an advanced new generation of software that melds computing and communications in a revolutionary new way, offering developers the tools they need to transform the Web and every other aspect of the computing experience. Microsoft .NET will allow the creation of distributed Web Services that integrate and collaborate with a range of complementary services to make information available any time, any place and on any device.
The fundamental idea behind Microsoft .NET is that the focus is shifting from individual Web sites or devices connected to the Internet, to constellations of computers, devices and services that work together to deliver broader, richer solutions. People will have control over how, when and what information is delivered to them. Computers, devices and services will be able to collaborate with each other to provide rich services, instead of being isolated islands where the user provides the only integration. Businesses will be able to offer their products and services in a way that lets customers seamlessly embed them in their own electronic fabric. It is a vision that extends the personal empowerment first offered by the PC in the 1980s.
Microsoft .NET will help drive a transformation in the Internet that will see HTML-based presentation augmented by programmable XML-based information. XML is a widely supported industry standard defined by the World Wide Web Consortium, the same organization that created the standards for the Web browser. It was developed with extensive input from Microsoft Corp. but is not a proprietary Microsoft technology. XML provides a means of separating actual data from the presentational view of that data. It is a key to the Next Generation Internet, offering a way to unlock information so that it can be organized, programmed and edited; a way to distribute data in more useful ways to a variety of digital devices; and a way of allowing Web sites to collaborate and provide a constellation of Web Services that will be able to interact with each another.
Microsoft .NET comprises the following:
- Microsoft .NET platform
Includes .NET infrastructure and tools to build and operate a new generation of services; .NET User Experience to enable rich clients; .NET building block services, a new generation of highly distributed mega services; and .NET device software to enable a new breed of smart Internet devices.
- Microsoft .NET products and services
Includes Windows Server 2003, with an integrated set of building block services; MSN .NET; personal subscription services; Office .NET; and Visual Studio .NET.
- Third-party .NET services
A vast range of industry partners and developers will have the opportunity to produce corporate and vertical services built on the .NET platform.
Microsoft .NET will take computing and communications far beyond the one-way Web to a rich, collaborative, interactive environment. Powered by advanced new software, yet built on today's .NET Enterprise Server products, Microsoft .NET will harness a constellation of applications, services and devices to create a personalized digital experience—one that constantly and automatically adapts itself to your needs and those of your family, home and business. It means a whole new generation of software that will work as an integrated service to help you manage your life and work in the Internet Age.
For consumers, that means the simplicity of integrated services; unified browsing, editing and authoring; access to all your files, work and media online and off; a holistic experience across devices; personalization everywhere; and zero management. It means, for example, that any change to your information—whether input via your PC or handheld or smart credit card—will instantly and automatically be available everywhere that information is needed.
For knowledge workers and businesses, it means unified browsing, editing and authoring; rich coordinated communication; a seamless mobile experience; and powerful information-management and e-commerce tools that will transparently move between internal and Internet-based services, and support a new era of dynamic trading relationships.
For independent software developers, it means the opportunity to create advanced new services for the Internet Age—services that are able to automatically access information either locally or remotely, working with any device or language, without having to rewrite code for each environment. Everything on the Internet becomes a potential building block for this new generation of services, while every application can be exposed as a service on the Internet.
The Microsoft .NET vision means empowerment for consumers, businesses, software developers and the entire industry. It means unleashing the full potential of the Internet. And, it means the Web the way you want it.
The foundation for the Microsoft .NET platform is based on the Microsoft .NET Enterprise Server products, including Windows 2000, Microsoft SQL Server 2000, and Host Integration Server 2000.
Host Integration Server 2000 Components
Integration projects are as varied as the companies that undertake them, and Host Integration Server 2000 includes a wide array of integration components and tools to help create an effective integration solution.
Host Integration Server 2000 provides the following categories of components:
- Data Integration components, which provide desktop or server-based applications with direct access to host data. Host Integration Server 2000 provides a comprehensive set of data access services, which includes direct data access to relational and non-relational mainframe and AS/400 data through open database connectivity (ODBC), object linking and embedding database (OLE DB), and COM automation controls.
- Application Integration components, which allow host-based and Web- or Windows-based applications to communicate directly with one another. Host Integration Server 2000 delivers solutions for integrating both synchronous and asynchronous transactions.
- Host Integration Server 2000 Management components, which provide a wide assortment of tools to manage the components of Host Integration Server 2000. This includes tools for performing both interactive and scripted local and remote Web-based and traditional client/server management of Host Integration Server components.
- SNA Network components, which connect SNA networks with PC-based LANs. Host Integration Server 2000 allows users running Windows, Macintosh, UNIX, the MS-DOS® operating system, and IBM OS/2 to share resources on mainframes and AS/400 systems without requiring system administrators to install resource-heavy SNA protocols on the PCs or install costly software on the host.
Figure 1. Host Interoperability Layers. Host Integration Server 2000 offers a comprehensive set of components for the Network, Data, and Application integration layers with which to integrate Windows and the .NET platform with host systems.
Host Interoperability Layers
When thinking of the many services that Host Integration Server 2000 provides, it is useful to think of these services in groups or "layers"—similar to the network protocol stack: Network Data, Application, and Management. In the following sections of this paper, we will explore these layers in more detail, beginning with Data, then Applications, and finally Network (and Management).
The Data Integration layer of Host Integration Server 2000 provides access to both structured and non-structured data stored on IBM mainframe or AS/400 computers. This data can be stored in a database or file system. In addition to data access, the Data Integration layer is also responsible for providing data transfer services between Windows 2000 computers and host systems. The Data Integration layer consists of components that make use of existing mainframe and AS/400 software.
The Data Integration layer can be broken down further into the following categories:
- Relational database access
- Record file access
- File transfer
- AS/400 data queue access
All these services make use of IBM host-based products that implement the IBM Distributed Data Management Architecture (DDM). DDM is a framework or methodology for sharing and accessing data between systems. DDM defines the "how to communicate" and leaves it up to individual platform vendors to implement the DDM architecture. IBM currently supports DDM for most IBM platforms, including: OS/390 (MVS), AS/400, RS/6000 (AIX), and AS/36. By supporting DDM, application developers are freed from having to write complex communications interfaces for each platform they need to support. Instead the application and DDM handles this complexity on behalf of the application.
Figure 2. Distributed Data Management. Components of the Host Integration Server 2000 Data Integration layer utilize popular DDM file models when integrating host data sources with Windows and .NET applications.
Host Integration Server 2000 offers relational database access by using the Distributed Relational Data Architecture (DRDA) subset of DDM, non-relational access using the Record Level I/O (RLIO) implementation of DDM, while file transfer and AS/400 data queue access employ a subset of the RLIO protocol.
Relational Database Access
Much of the operational data stored on OS/390, AS/400, and RS/6000 computers is accessed via a relational database management system. The most popular database on these host systems is IBM DB2. In the case of the AS/400, DB2 is integrated with the operating system. For OS/390 and RS/6000 computers, it is common for organizations to deploy the IBM DB2 relational database management system (RDBMS).
What all of these host systems have in common is that data stored in these databases are accessible as relational tables using Structured Query Language (SQL). This allows for efficient and standardized access to the data on the local DB2 system. However, for many years, there was no common means of accessing data across systems on remote DB2 computers. To resolve this problem, IBM devised Distributed Relational Databases Architecture (DRDA) and has passed the architecture to The Open Group for publication and future extension.
DRDA offers both Remote Unit of Work (RUW) and Distributed Unit of Work (DUW) access to host data. RUW is used for read-only and simple updating of database tables using SQL statements and stored procedures. DUW is used when updates span multiple DB2 instances or computer systems and supports the two-phase commit (2PC) protocol. The 2PC protocol ensures that changes to multiple databases will either succeed or fail in their entirety. We will talk more about 2PC and transaction management in the section on the Application Layer later in this white paper.
Through its Universal Data Access (UDA) architecture, Microsoft supports two popular methods of accessing remote relational databases: the industry-standard Open Database Connectivity (ODBC); and the broader Object Linking and Embedding DB (OLE DB). ODBC is designed specifically for interoperating with SQL-accessible RDBMSs. ODBC is implemented by independent software vendors (ISVs) in the form of either a back-end data base driver, or as a front-end application (e.g., reporting or query tool). Microsoft and other vendors offer ODBC drivers for most of the popular RDBMSs. Microsoft defined OLE DB as a multi-tier distributed architecture for accessing both SQL RDBMSs and non-SQL data sources (e.g., mail folders, Internet server stores, flat file systems). In the OLE DB architecture, ISVs develop software that participates in one of three roles: (1) OLE DB provider, or back-end data source driver, (2) OLE DB service component (e.g., query processor, cursor engine), and (3) OLE DB consumer (e.g., Web service or application, GUI query or reporting tool). OLE DB is based on the Component Object Model (COM) and OLE DB providers are designed to expose a well-known set of interfaces. When a provider cannot expose specific, useful or often-required functionality, an OLE DB service component is employed to extend and standardize the abilities of the provider. In this way, OLE DB consumers can be written to access multiple data sources without knowing any of the vagaries or limitations of a given back end provider.
Host Integration Server 2000 implements access to DB2 via two features:
- Microsoft ODBC Driver for DB2
- Microsoft OLE DB Provider for DB2
The first of these methods is the ODBC Driver for DB2. It relies on an underlying DRDA application requester (AR) developed by Microsoft. The DRDA AR connects the ODBC driver to DB2 on popular platforms, including OS/390, OS/400, RS/6000-AIX, and Windows NT®, Windows 2000.
It provides a flexible way for developers using the ODBC API to create applications that can access DB2 records quickly and efficiently. The driver supports the DRDA Level 3 standard and ODBC 3.x interfaces, and allows application programmers to write C and C++ applications that issue dynamic SQL queries and call DB2 stored procedures.
The second method to access DB2 is through the OLE DB Provider for DB2. This component is also implemented to sit on top of the DRDA AR, and therefore supports the same target DB2 systems and substantially the same DB2 access features (e.g., dynamic SQL and stored procedures, 2PC, SNA LU6.2 and TCP/IP network connectivity). Developers can use C or C++ to integrate DB2 data with Web-based and Windows-based applications. Visual Basic® and Web developers (using scripting languages such VBScript) can use the higher-level ActiveX® Data Objects (ADO) to develop e-commerce solutions. Additionally, DB2 is directly accessible from productivity applications, such as Microsoft Office 2000 using Visual Basic for Applications (VBA) and ADO from within Excel.
Many organizations want to improve corporate decision making by centralizing data that is stored in a variety of formats in a number of different places. Database administrators can use Data Transformation Services (DTS), a feature of Microsoft SQL Server 2000 and Microsoft SQL Server 7, to import and export data between multiple heterogeneous sources using the OLE DB Provider for DB2. Using this tool, administrators can create a data warehouse using DB2 data, plus integrate most other data sources accessible via an OLE DB provider.
The Distributed Query Processor (DQP), another feature of Microsoft SQL Server, allows users to access data that resides on multiple, distributed databases across multiple servers. Using DQP, SQL Server administrators and developers can create linked server queries that run against multiple back-end data sources with little or no modification. DQP enables application developers to create heterogeneous queries that join tables in SQL Server with tables in DB2. Also, DQP can be used to create SQL Server views over DB2 tables so that developers can write directly to SQL Server and integrate both Windows-based and host-based data in their applications with ease.
Record File Access
Another rich source of legacy information is the large amount of data still stored in mainframe VSAM files, Partitioned Datasets, and AS/400 files. Host Integration Server 2000 supports the following services for access to non-relational host data:
- The OLE DB provider for AS/400
- The OLE DB provider for VSAM
The OLE DB Provider for AS/400 supports record level access to keyed and non-keyed physical files with external record descriptions, as well as logical files with external record descriptions. Also, the provider can use an optional Host Column Description (HCD) file to describe the format of the target file, mapping the AS/400 data types to OLE DB data types, allowing the developer to access AS/400 flat data files and source files.
The OLE DB Provider for VSAM, which relies on the HCD files to define the metadata of the target data set or member, provides access to most types of mainframe based VSAM files.
Sequential Access Method (SAM) data sets
- Basic Sequential Access Method (BSAM) data sets
- Queued Sequential Access Method (QSAM) data sets
Virtual Storage Access Method (VSAM) data sets
- Entry-Sequenced Data Sets (ESDSs)
- Key-Sequenced Data Sets (KSDSs)
- Fixed-length Relative Record Data Sets (RRDSs)
- Variable-length Relative Record Data Sets (VRRDSs)
- VSAM Alternate Indexes to ESDSs or KSDSs
Basic Partitioned Access Method data sets
- Partitioned Data Set Extended (PDSE) members
- Partitioned Data Set (PDS) members
- Read-only support for PDSE directories
- Read-only support for PDS directories
Using Visual Studio, developers can build dynamic Web applications that integrate host non-relational data sources with Windows data, allowing knowledge workers to publish needed information for use by their organization's decision makers.
Most 3270 emulators support the ability to transfer files between a mainframe computer and a workstation using the IND$FILE utility program. This program works in conjunction with a host operating system such as TSO or teleprocessing monitor software such as CICS running on the mainframe. This process, is often manual and is somewhat inefficient due to the need to use 3270 terminal emulation on the client and to have the host operating system act as an intermediary in the data transfer process. Host Integration Server 2000 provides several more efficient methods to perform file transfer. These methods are:
- Host File Transfer
- APPC File Transfer Protocol (AFTP)
- AS/400 Shared Folders
The Host File Transfer utility lets developers move files between a host system and a local Windows computer. Host Integration Server 2000 provides this service through a single ActiveX Control. This extends the ability of the client application to perform file transfer operations from a large number of client development environments. Using HCD files, the Host File Transfer can access the same mainframe data set types as the OLE DB Provider for VSAM, yet it is optimized to download or upload the entire contents of the data set or member. Other supported environments include the AS/400 and AS/36.
The TCP/IP based File Transfer Protocol (FTP) is often used to move files between computer systems running under UNIX, VMS, and other operating systems. This capability is typically provided as a utility program that implements a set of commands that can be used to connect to a remote computer, log on, navigate to specific locations in the local and remote computer file systems, and then transfer a file (or multiple files) to or from that computer. Unfortunately, to use this protocol to transfer files to a host computer would require TCP/IP on the host. (Most data center managers are reluctant to support TCP/IP on a host computer due to security and performance issues.) Because of the popularity of this protocol, however, IBM has implemented a similar SNA function, the APPC File Transfer Protocol (AFTP). This allows files to be transferred between SNA systems using commands that are so similar to FTP commands that anyone familiar with FTP can easily use AFTP to perform file transfer functions. Internally, AFTP transfers files using the LU 6.2 program-to-program protocol, which is quite efficient for transferring files. AFTP software can be installed either on the Host Integration Server 2000 server or client and used to transfer files to an SNA host.
The AS/400 Shared Folders feature of Host Integration Server 2000 allows a Windows NT or Windows 2000 administrator to re-share a file on an AS/400 host as if it is a local file system directory. Because the AS/400 shared folders feature uses standard operating system file sharing, it requires no software on the client. The client simply sees the folder as a standard Windows NT or Windows 2000 shared directory. This feature is implemented in Host Integration Server 2000 using the same AS/400 PC Support software that allows workstations to access AS/400 files in a pure SNA network configuration.
AS/400 Data Queue Access
AS/400 Data Queues are used on an AS/400 to send data records between separately executing programs. Multiple AS/400 client programs can send data records to a single server program running on an AS/400. Alternatively, a single client program can send records to an AS/400 Data Queue and multiple server programs can extract the records and process the data in parallel. This feature proved so useful in developing AS/400 applications that IBM extended the use of AS/400 Data Queues to PC workstations. Host Integration Server 2000 enables Windows 32-bit applications to access data queues via the AS/400 Data Queue COM Automation Control. Host Integration Server 2000 lets developers access AS/400 data queues from a PC running Windows, so they can move part or all of their AS/400 applications from an AS/400 computer to a PC platform and still use the PC-based program to access a remote data queue on the AS/400.
The Application layer provides the services that enable Windows and mainframe programs to work together. It defines how two application programs can participate in cross platform transactions and messaging, including distributed database updates involving the two-phase commit database protocol.
In Host Integration Server 2000, the Application layer is focused on distributed application programs where at least one of the programs is running on a mainframe and AS/400.
Integrating existing host-based data and applications with Web-based solutions can benefit organizations in many ways. This allows you to preserve your investments in existing technology while extending host-based resources to highly scalable, distributed, component-based and Web-based applications. It helps you to reduce your development costs by allowing you to draw on a large pool of qualified developers for Windows rather than a small group of host programmers with highly specialized skills. It also supports cutting migration costs by keeping host-based resources on mainframe and AS/400 computers or amortizing these costs by migrating slowly to the PC platform over time.
In mainframe applications, database management systems and transaction processing programs have always been tightly integrated. In applications developed using IBM's CICS or IMS, a communications front-end program normally retrieves data from and/or updates a back end database. Multiple interactions with the user are often necessary to complete a transaction and update a database. In the case where multiple database updates are required, then CICS and IMS support the concept of a Transaction. In the case of multiple updates to a database, the scope of a transaction ensures that all updates are successfully applied or that any partially completed updates are reversed. A CICS or IMS program can also indicate the success or failure of a transaction by issuing a command to indicate the end of a transaction or that a rollback of partially completed updates is required.
Mainframe transaction processing systems also support the definition of a transaction that can exist across multiple distributed databases. This feature is based upon a well-known standard called Synchronization Level 2 (Sync Level 2) also known as the Two-Phase Commit protocol.
CICS in particular can be used to write distributed applications where one CICS application program can link to another CICS program whether that program is on the same computer or a different one. CICS uses a special CICS data area, called a commarea, to pass data to the target program. It is the CICS commarea that plays the key part in passing data to and from the linked-to program.
When developing transaction-aware applications for the Windows and Web platforms, developers often write COM components that run under the Microsoft Transaction Server (MTS) in Windows NT or the equivalent COM+ feature in Windows 2000. MTS combines the features of a COM object broker and a transaction manager. An application can be written with COM components that run on different computers. The programmer can define how each component participates in transactions across these distributed components. Each COM component can specify whether it can be part of a new transaction or an existing transaction. The transaction management part of MTS is based on a component called the Distributed Transaction Coordinator (DTC). Once the transaction state of a set of components is defined, then MTS can use the DTC to enforce the same transaction and database update integrity over them that a CICS or IMS program can enforce over mainframe transactions. COM programs can indicate the success or failure of a complete transaction just as a CICS or IMS program can do.
In order to allow applications for Windows NT and Windows 2000 to make use of these pre-existing mainframe CICS and IMS programs, Host Integration Server 2000 offers COM Transaction Integrator (COMTI). COMTI enables mainframe CICS and IMS programs to participate in COM transactions.
Figure 3. COM Transaction Integrator. COMTI allows developers to preserve existing CICS and IMS environments while moving to a new Windows and .NET platform.
COMTI creates a COM+ or MTS "wrapper" (or proxy) component that makes a legacy CICS or IMS mainframe application program look like a COM component at execution time. Windows 2000 applications make method calls and pass parameters to what appears to be just another COM component. This call is translated under the covers to the appropriate CICS program call and sent to the mainframe via Host Integration Server 2000 and LU 6.2. As part of this process, the COMTI component converts parameters between mainframe and COM formats. COMTI transactions can also participate in cross platform transactions under the control of the Distributed Transaction Coordinator.
Using COMTI is a three-step process:
- Building the COMTI component
- Adding the component to MTS
- Running the application
First, the COBOL commarea description must be brought down to the developer's workstation from the mainframe using Host File Transfer or a terminal emulator. Next, the COMTI graphical user interface is used to import the COBOL data description and convert the COBOL parameter definitions into their COM equivalents. Next, COMTI will generate the COM component that will act as a proxy for the mainframe application program. The commarea is converted into a COM recordset definition that can be used to pass parameters into and out of the mainframe program. After the code is translated, the name of the program becomes the callable method of the MTS transaction and the variables passed to the original COBOL program in the commarea are translated into method parameters.
After the COMTI component is created, it can be packaged with other COM components to define the complete transaction. At execution time, calls to legacy programs appear to be calls to the COMTI component. Parameters are transparently converted and any required two-phase commit protocols are enforced across both systems.
Currently, COMTI uses the Distributed COM (DCOM) protocol to communicate between the COM components and Host Integration Server 2000. (Host Integration Server 2000 takes care of the conversion to the appropriate SNA protocol.)
Inter-Platform Message Queuing
In the section on Transaction Processing, we also discussed how Host Integration Server 2000 supports keeping remote databases in strict synchronization with each other using distributed transactions and COMTI. When synchronous transactions are required, COM and COMTI provide an excellent real-time method of implementing a distributed application.
There is a third scenario in which programs need to pass data between them, but where there is no need for the sending program to wait for the receiving program to process the data. In this case it is enough to know that the data will be delivered and processed eventually. Message passing software to support this capability is called Message Oriented Middleware (MOM). Microsoft's MOM product offering is the Microsoft Message Queuing System (MSMQ).
This system consists of agents running on the sending systems and message queues on the receiving system. A program that wants to send a message to a receiving system simply uses an API to place the message in a local send queue. Eventually the message is sent. Although the initiating program does not wait for the message to be successfully received by the recipient, it can assume that the message will be delivered. This is because the MOM system uses transactional integrity between the local sending agent and the receiving program.
Figure 4. MSMQ-to-MQSeries Bridge. The bridge provides asynchronous, messaging-based, communication integration between heterogeneous applications.
Microsoft's MSMQ is the MOM product that supports messaging between Windows platforms. Mainframes and other platforms, on the other hand, normally use a product developed by IBM called MQSeries. IBM has extended MQSeries to other IBM and non-IBM platforms in addition to mainframes and AS/400. Although a version of MQSeries is available for Windows NT and Windows 2000, MSMQ is native to those platforms. In order to support cross platform messaging between Windows and mainframe messaging systems, Host Integration Server 2000 includes the MSMQ-MQSeries Bridge. This bridge integrates the two messaging platforms and enables messages to be transferred in either direction across platforms.
In the preceding sections of this paper we discussed how Host Integration Server 2000 client and server components work together to provide access to mainframe and AS/400 resources. In this section we will cover the Management layer of Host Integration Server 2000. This layer concerns itself with how Host Integration Server 2000 servers and clients are installed and managed. It also discusses the integration of Host Integration Server 2000 with mainframe network management systems such as IBM NetView.
Host Integration Server 2000 Server Installation
The Host Integration Server 2000 server installation allows the administrator to specify the components to be installed and the various roles that a server will play such as primary or backup configuration server. Server installation can be performed via several methods such as:
- Local CD-ROM
- Network share point
- Unattended installation
- Systems Management Server
The default method of installing Host Integration Server 2000 is from a local CD. This type of installation is run at the server, and the installer must respond to all prompts.
Figure 5. Server Setup. Host Integration Server 2000 offers a Microsoft Software Installer setup program that allows the administrator to choose the most appropriate features.
Alternatively, the installation files can be located on a network share point. The installer must still answer all the questions during the installation process.
Host Integration Server 2000 also supports an unattended install process. This process uses answer files that remove the need for the installer to be present during the complete installation. They still need to be there to start the process, however. This type of install must be done from a network share point or diskettes since it requires that the installation files be customized. Once the process is started the installer can leave.
With Systems Management Server an installer does not even have to go to the server to start installation of Host Integration Server 2000. Systems Management Server can be used to push the server installation and configuration to a target server.
Host Integration Server 2000 Server Configuration
Once the server is installed it must be configured. The configuration process is used to define all the link services, connection types, LUs and LU pools. It is also used to define users groups and client workstations and allocate resources to them. Resources can be allocated globally to everyone or specifically down to a particular user, group or even a single workstation. Resource access can also be granted at different levels of granularity such as to a subdomain, a specific server, LU pools, or even specific LUs.
Host Integration Server 2000 Client Installation
The Host Integration Server 2000 CD also includes installable clients for Windows 98, Windows 3.x, Windows NT Workstation and Windows 2000 Professional. It also includes installation instructions or the source of clients for several other platforms.
There are three parts to each Host Integration Server 2000 client—not all of which need to be installed. These parts are the Base client, API support, and features such as the OLE DB providers, 3270 and 5250 clients. Most third party emulators only require that you install the Base support.
When installing Host Integration Server 2000 client, the installer can specify the components to install, select the client/server protocols that the client uses to communicate with the server, and define how the client will locate a server in the network. The methods used to install a client are similar to the ones used to install a server with one important new addition, the Web based install.
These methods are:
- Local CD-ROM
- Network share point
- Unattended installation
- Systems Management Server
- Web based installation
The first three methods are essentially the same. Just as in the case of Host Integration Server 2000 servers, an answer file can be used to simplify the installation process. In the case of the Systems Management Server installation there are also Systems Management Server Installation Packages on the CD for Windows 3.1, Windows 98, Windows NT Workstation, and Windows 2000 Professional.
With Web based installation, a Host Integration Server 2000 client can be installed by simply displaying an intranet or Internet Web page and clicking on a hypertext link. The Web-based installation provides three options. The installer can request the download and installation of the 3270 Client plus the full Host Integration Server 2000 Client, the 5250 Client plus the full Client, or just the Base Client. (The latter is useful in order to upgrade an older Base Client that came with a third party emulator.) This process can also be customized to provide additional capabilities.
Host Integration Server 2000 Client Configuration
Once the client is installed it must be configured. This configuration is normally limited to specifying how the client will locate a sponsor server when it connects. Options are to have the client broadcast a request for a sponsor to the entire subdomain, or to direct its request to a specific server or list of servers.
Host Integration Server Network Resource Management
The predecessors of Host Integration Server 2000 have always been the industry leaders in Windows to host network integration using standard networking protocols. Host Integration Server 2000 carries forward this tradition by enhancing support for a wide variety of SNA links, connections and logical unit types. Host Integration Server 2000 includes tools to manage the setup and use of these resources in a secure, loosely, or tightly controlled fashion. For instance, individual servers, Logical Units or Logical Unit pools can be set up to grant access to any client that requests access, or they can be restricted to specific users and/or client workstations.
The security mechanism for this access control is based on Windows NT and Windows 2000 security. User and Groups can be defined and Access Control Lists created for Host Integration Server 2000 resources that will allow or deny these users, groups or computer systems access.
Host Integration Server 2000 Management Tools
There are several administrative interfaces available to be used to manage Host Integration Server 2000 resources. These tools include:
- Microsoft Management Console
- Web Based Administration
- SNA Remote Access Services
- Mainframe tools
The Microsoft Management Console (MMC) is the standard Microsoft tool for assembling individual systems management utilities into customized toolsets that can be used to delegate administrative tasks and responsibilities to individual administrators. Host Integration Server 2000 installation provides snap-ins that can be added to any MMC console. Note that multiple Host Integration Server 2000 snap-ins can be installed in a console in order to manage multiple subdomains or servers.
Figure 6. Server configuration (click to enlarge). Host Integration Server 2000 offers an MMC-based snap-in for administering server configurations.
As an alternative to the GUI based MMC, Host Integration Server 2000 also comes with command line utilities that can be used to manage any Host Integration Server 2000 resource. The Windows Script Host is a powerful scripting language that is available as an add-on to Windows NT and comes standard with Windows 2000. The addition of this tool to the Host Integration Server 2000 command line utilities enables the administrator to create and modify any Host Integration Server 2000 resource from a batch script. Using a combination of the Windows Script Host and the SNACFG command line utility, any Host Integration Server 2000 management task can be automated and performed without resorting to the GUI.
Host Integration Server 2000 also supports administration using Web-based tools using Microsoft's Windows Management Instrumentation (WMI) technology. This is an implementation of the Desktop Management Task Force's (DMTF) Web-Based Enterprise Management (WBEM) initiative for Microsoft Windows platforms.
Figure 7. Web-based Administration. Microsoft Host Integration Server 2000 provides enhanced management capabilities for SNA administrators to view and control their SNA Server environment. Using WMI/COM, administrators can build their own Web-based tools to monitor, configure, and administer all SNA objects.
Normally an administrator will be able to access a server or subdomain using the client/server protocols that we have been discussing in this paper. In some cases, however, this may not be possible. SNA Remote Access Services (SNARAS) extends normal Windows NT and Windows 2000 RAS to operate over SNA links. This allows an administrator to connect to a remote SNA server over an SNA link.
In addition to integrating with Windows NT and Windows 2000 management tools, Host Integration Server 2000 also integrates with popular mainframe-based network management tools such as IBM NetView. Windows NT and Windows 2000 Event Log Alerts can be forwarded up to a mainframe NetView system using the NVAlert component. A NetView operator can also run Host Integration Server 2000 commands using the NVRunCmd command provided by Host Integration Server 2000. In addition, the NetView Response Time Monitor (RTM) can be used to capture information on client response time and forward the data back to NetView.
Active Directory Integration
Host Integration Server 2000 also takes advantage of the Windows 2000 Active Directory™ service. A client needing to locate a sponsor server when it connects to the network can use Active Directory. It can also use Active Directory to locate a server that can provide a specific Host Integration Server 2000 resource such as an LU or LU pool.
Host Integration Server 2000 uses Active Directory by registering services and resources with the Active Directory schema. The benefits of using Active Directory include:
- Client configuration and resource location on the network is simplified.
- A permanent LAN connection between Host Integration Server 2000 and Host Integration Server 2000 clients is not needed.
- The limitation of 8,000 sponsor connections that existed in SNA Server 4.0 is eliminated.
Host Integration Server 2000 client computers must be configured to communicate to a Host Integration Server 2000 computer using either sponsor connections or Active Directory. A client computer cannot be set up to use both at the same time. Host Integration Server 2000 extends the Active Directory schema to include Host Integration Server resources.
Host Security Integration
One of the problems with mixing Windows NT and Windows 2000 with mainframe and AS/400 computers is that each type of system has its own way of dealing with security. It is not uncommon to have one user account and password to access a local Windows NT or Windows 2000 domain while also having another user account and password to access the mainframe or AS/400. In addition, mainframe and/or AS/400 applications may also have their own user account and password. After a while, users begin to forget theses multiple passwords and begin to write them down and keep them in an insecure place. This defeats the purpose of having passwords in the first place.
To simplify the situation, Host Integration Server 2000 comes with a Host Security Integration feature, which consist of a set of processes that run on network servers to provide the following services:
- User account and password mapping and caching
- Password Synchronization
- Single Sign on to multiple domains and host security systems
The Host Account Cache is a database that maps Host and Windows NT/Windows 2000 users names and passwords. It supports two options: Replicated and Mapped.
The Replicated option is used where the user's name and/or password are the same on both platforms. The Mapped option is used where they are different. This information is used to translate between the local and remote user name and passwords.
The Host account synchronization service is used to intercept Windows NT and Windows 2000 password changes and send them to a host security system.
Figure 8. Host Security Integration. Host Integration Server 2000 allows administrators to synchronize the account information on the host with the Windows 2000 domain. Synchronized accounts allow for single sign-on, meaning that users only have to maintain a single user account and password to log on to Windows and the host system.
In the case of AS/400, password synchronization works in both directions. In the case of mainframes, a third party tool is necessary for complete bi-directional synchronization with mainframe security systems such as RACF, ACF/2 and Top Secret.
Traditionally Windows NT and Windows 2000 networks used Microsoft Networking that was based on NetBIOS. Most recently, TCP/IP has become the preferred network protocol used in Windows NT and Windows 2000 networks. In fact, with Windows 2000 the favored protocol is TCP/IP.
The most popular method of connecting networks with dissimilar protocols has always been to insert a gateway device between them that can convert from one protocol to another. To bridge the gap between a Windows 2000 network and an SNA network requires an SNA gateway. Host Integration Server 2000 is the most popular method of providing this function. Host Integration Server 2000 incorporates the traditional SNA gateway function, however, it goes beyond simple protocol conversion by providing a significant number of higher level application enabling services that work in conjunction with it's basic function.
The Network layer contains all the low level protocols used to transport data between the client and the Host Integration Server 2000 and between the Host Integration Server 2000 and the host computers in the SNA network. It also includes support for 3270 and 5250 terminal emulation as discussed below.
SNA-to-PC LAN connectivity sits at the heart of every integration project, and Microsoft is committed to providing companies with efficient, flexible SNA gateway options. Host Integration Server 2000 builds on the industry leading network connectivity features of SNA Server 4.0 to provide companies with the greatest number of options for connecting SNA systems and PC-based networks.
Host Integration Server 2000 connects PC-based LANs to IBM System/390 mainframe and AS/400 midrange systems. With Host Integration Server 2000, users with desktop operating systems such as Windows 2000 Professional, Windows NT Workstation, Windows 9x, Macintosh, UNIX, MS-DOS and IBM OS/2 can share resources on mainframe computers and AS/400 systems. Administrators can provide this connectivity in many cases without installing SNA protocols on the PC or deploying software on the host system. The following diagram illustrates the network connectivity capabilities of Host Integration Server 2000.
Figure 9. Host Integration Server 2000 Network Support. Host Integration Server 2000 builds on Microsoft SNA Server's strong platform of protocol and connectivity options. As an SNA gateway solution, Host Integration Server 2000 runs on Windows NT Server and Windows 2000 Server to connect PC-based local area networks (LANs) to IBM System/390 mainframe and AS/400 midrange systems.
Host Integration Server 2000 Software Architecture
Host Integration Server 2000 has been designed with a modular Client/Server architecture.
The Server component of Host Integration Server 2000 runs on Windows NT 4.0 or Windows 2000 Server and provides gateway and protocol conversion services. It contains most of the SNA protocol stack and is also responsible for notifying the attached clients of the configuration of the servers, available services, and network status. It consists of the following components:
SNASERVER runs as a Windows NT or Windows 2000 Service. It is the protocol conversion engine of Host Integration Server 2000. SNASERVER provides PU 2 and 2.1 node emulation. It communicates status changes with other server, clients and host computers. It also allows the SNA Manager to display the status of Links, Connections, and LUs in the network. It uses the following components to communicate between clients and other servers.
SNABASE runs as a service on the server. It is responsible for building and maintaining a list of available servers, links, LUs and invokable Telecommunication Programs (TPs). It also sends this list to other Host Integration Server 2000 servers and receives updates from those servers. It maintains this information in a local configuration file (COM.CFG).
When a client first contacts the Host Integration Server 2000 server, SNABASE uses this information to determine the server actually hosting the desired resources for which the client is looking. Then the server will send the client the list of available servers holding the desired resource; this initial connection is called a Sponsor connection (see below).
After connection, SNABASE directs the client to the LU or LU pool that can provide the client with the desired resource.
SNADMOD is a common communications module used by the server to communicate with clients and other servers. It uses a remote Procedure Call (RPC) protocol that is proprietary to Host Integration Server 2000.
The architecture of the Host Integration Server 2000 client includes:
- SNABASE (or equivalent)
The Host Integration Server 2000 client provides APIs needed by SNA applications such as 3270 emulators and APPC applications.
The architecture of Host Integration Server 2000 clients differs depending on whether the Host Integration Server 2000 client is for Windows NT, Windows 2000 or another operating system. The Windows NT and Windows 2000 clients also use SNABASE below the API layer. Other clients use a callable DLL instead of a service to perform the same functions, but all the clients use DMOD to implement common communications between clients and servers.
Initially Host Integration Server 2000 clients are configured to attempt to contact any server in the subdomain (see below), or a list of specific Host Integration Server 2000 servers. If the configuration specifies a list of servers, then one will be chosen at random each time a client attempts to connect. This design causes requests to be spread across multiple servers, in effect implementing an efficient form of load balancing across the servers. This design also provides a degree of fault tolerance. If a server or resource is unavailable, then the client can automatically choose a resource from another server. This load balancing and fault tolerance is inherent in the design of Host Integration Server 2000 and does not have to be added using any external form of Windows NT or Windows 2000 clustering or fault tolerance.
Host Integration Server 2000 servers are organized in logical groups called Subdomains (to distinguish them from Windows NT/2000 Domains). There can be any number of Host Integration Server 2000 Subdomains. Each Subdomain can contain up to 15 Host Integration Server 2000 servers whose roles in a Host Integration Server 2000 network can be defined as Primary Host Integration Server 2000 servers, Backup Host Integration Server 2000 servers or Member Host Integration Server 2000 servers. These designations are somewhat analogous to the Primary, Backup and Member server designation of Windows NT and Windows 2000 Servers. In this case, however, instead of ownership of the security accounts database, Host Integration Server 2000 server roles define ownership of a configuration database that describes the state of all servers, their controlled resources, and the status of connected clients.
All three types of servers can host resources for clients to use. A new client looking for resources can contact all three types of servers. Primary servers can also update the configuration database. Backup servers, on the other hand, have only a read-only copy of the database for local use. Member servers cannot provide a client with information on network resources since they do not have a copy of the configuration database. They can, however, host specific resources, such as LUs, for clients to use.
Status information is replicated between Host Integration Server 2000 servers to allow all Host Integration Server 2000 servers to maintain a configuration file that describes the complete status of all servers and other Host Integration Server 2000 managed resources in the network.
When a client computer connects to the network, it contacts a server near it based on it's own configuration file. This connection is called a Sponsor Connection. The sponsor server can provide the client with a list of resources in the network or refer it to another server in the network. From this connection the client retrieves the status of existing servers and other network resources such as individual Logical Units or Logical Unit pools that the client can request.
The Client component of Host Integration Server 2000 is a fairly slim software component since most of the protocol conversion and enabling services take place on the server. A wide range of clients are supported, including Windows 2000, Windows NT, Windows 98/95, Windows 3.X, MS-DOS, and OS/2. In addition, Host Integration Server 2000 client software is available for Macintosh, UNIX and VMS clients via third parties.
Server Deployment Models
Another important aspect of the Host Integration Server 2000 network architecture is how Host Integration Server 2000 servers and clients can be deployed in a network. Using Host Integration Server 2000, organizations can deploy SNA gateways in an enterprise network in one of three deployment models:
- Centralized Deployment model
- Branch Deployment model
- Distributed Deployment model
Centralized Deployment model
Figure 10. Centralized Deployment model. In a centralized deployment, Host Integration Server 2000 computers support local and remote split-stack SNA clients, server-based applications, and TN3270 emulators.
The Centralized Deployment model locates the Host Integration Server 2000 servers at the data center near the host computer in the network. In this model the SNA gateways are located at the data center and connect to the host using native SNA protocols, such as a high-speed token-ring or channel attachment. In the centralized deployment model, Administrators can isolate the SNA traffic to the data center to avoid supporting SNA traffic on the WAN. Centralized SNA gateways provide split-stack or TN3270 service for local and remote desktops that connect to the gateways using standard LAN protocols.
The major advantage of this model is that the Host Integration Server 2000 server has high-speed access to the host computer via a common LAN and front-end processor, or even direct channel attachment. This location offers many advantages; because the servers are located in a single location, clients can take advantage of the designed-in load balancing and hot backup capabilities provided by multiple Host Integration Server 2000 servers. In addition, MIS personnel can service and administer the centralized servers.
In the case of an organization with clients located at remote branch offices, several disadvantages that must be considered. Because most of the protocol conversion is performed on the server, there will be quite a lot of low-level data traveling back and forth between the clients and servers. One of the other two models may be more appropriate in these cases.
Figure 11. Branch-based Deployment model. Host Integration Server 2000 supports the traditional way to deploy SNA gateways in branch offices, via SDLC leased lines and X.25 connections to the host.
Branch Deployment model
The Branch Deployment model places the SNA gateways close to the clients at branch offices. The advantage of this location is that the heaviest data traffic will occur between the clients and the servers over the local LAN connection at the branch office. Only highly compressed and relatively efficient SNA traffic will occur over the Wide Area Network between the branch office and the central site.
Another advantage of this organization is that local branch personnel can administer the servers located at the branch. (This can be viewed as an advantage or a disadvantage depending on whether you want the servers managed centrally or remotely.) One of the enhancements of Host Integration Server 2000 over its predecessor, SNA Server 4.0, is that Host Integration Server 2000 servers can easily be administered remotely. This makes non-centralized Host Integration Server 2000 servers less of an issue compared with SNA Server 4.0.
A disadvantage of this organization is that there is no high-speed connection between the server and the host. WAN connections and routers in this type of organization will have to be sized to handle the traffic between the servers and the hosts. Because servers are not centrally located, it is also not possible to take advantage of the load balancing and hot backup features of Host Integration Server 2000.
Distributed Deployment model
The Distributed Deployment model combines the best aspects of the previous two deployment models at a slight increase in setup and administration complexity. With this model Administrators can deploy Host Integration Server 2000 concurrently in the branch and central sites. The branch-based Host Integration Server 2000 computers provide client-to-server support and connect to the centralized computers running Host Integration Server 2000 using native TCP/IP, or IPX/SPX protocols. The centralized servers provide server-to-host support and connect to the host with a high-speed token ring or direct channel attachment using native SNA protocols.
Figure 12. Distributed Deployment model. Host Integration Server 2000 offers a distributed deployment model that makes better use of available WAN bandwidth than centralized or branch-based configurations.
In this configuration the links between the central server (or server pool) and the host computer is a fast LAN to Front End Processor or direct channel attachment. The links between the clients and their local server (or servers) can also be a fast local LAN connection. Only relatively compact SNA traffic travels between the remote and central servers. This retains the advantage of pooling Host Integration Server 2000 servers at the central site while giving remote clients a local sponsor connection and local LU pools.
The only disadvantage of this approach is that there are more servers to deploy, administer and maintain. This is not a serious drawback, however, because they can be administered from a central site if necessary using the Host Integration Server 2000 remote administration capability. This model is a little more expensive because more servers will have to be deployed. This is not a serious impediment, however, because Host Integration Server 2000 servers run on modest hardware.
In general the Distributed Deployment model is more flexible and cost-effective than the Branch-based or Centralized models. Compared to a Branch-based deployment, the Distributed approach eliminates the time-outs associated with bridging or tunneling 802.2 using routers, improves host response times and simplifies network management. Compared to a Centralized deployment, the Distributed approach decreases WAN usage and supports NetView management of the Branch-based servers.
Of course the preceding discussion of deployment models assumes that the host is a single mainframe or AS/400 computer located at a central site. It is also possible that the network includes more than one host computer and/or that host computers and clients are distributed at multiple sites. Here, too, the Distributed Deployment Model can be used to combine the best of the Centralized and Branch organizations by placing some of the Host Integration Server 2000 servers near their hosts for high speed access, and placing some of the servers near the clients that they service. For example, assume that two companies merge, and that each company has a community of users and their own host computer. Eventually each company will require access to its own host computer and that of its partner. In this case the Distributed Deployment Model can be used at both companies to give symmetric access to both hosts from clients at both companies.
In addition to these deployment models, Host Integration Server 2000 can also act as a proxy for other network attached SNA devices that need to access a host computer through Host Integration Server 2000. This is supported by Host Integration Server 2000 Downstream Connection support and PU passthrough connections. These capabilities may be useful in some specialized cases.
Host integration Server 2000 supports a wide variety of protocols for communicating between clients, the server, and host computers. This allows Host Integration Server to fit into whatever networking architecture you currently have in place.
Server to host protocols
Host Integration Server 2000 supports several protocols for communicating between the server and the host computer. Link Services—provided by Microsoft, IBM, and other third parties and installed in the server—implement these Link Services.
For mainframe host access the most popular protocols include:
- Channel attachment
- LAN connection via the DLC 802.2 protocol
- Synchronous Data Link Control (SDLC)
Direct channel attachment is used to connect centralized Host Integration Server 2000 servers to a host using Escon or Bus and Tag channel connection methods. LAN Attachment via DLC 802.2 is used to connect servers to hosts over Ethernet, Token Ring, or Fiber Distributed Data (FDDI) LANs. Synchronous Data Link Control (SDLC) is used to connect them over wide area dial-up or leased line connections. X.25 is used to connect Host Integration Server 2000 server and mainframe over an X.25 network.
In some cases a company may already have coaxial cable installed to support 3270 terminals attached to existing cluster control units such as the IBM 3741. In this case the DFT link protocol can be used to connect clients to Host Integration Server 2000 over these cables. Now that most companies have converted from coaxial cables to LANs, however, this method of attachment is becoming more rare.
For Server to AS/400 access, Host Integration Server 2000 supports the same protocols discussed above. Instead of DFT, however, Host Integration Server 2000 supports the Twinax coaxial cable connection method that was originally used to connect IBM 5250 terminals directly to an AS/400.
Client to server protocols
In order to allow Host Integration Server 2000 clients to communicate with Host Integration Server 2000 Servers, Host Integration Server 2000 supports the following protocols:
- Microsoft Networking (named pipes)
We discussed TCP/IP and DLC 802.2 above. IPX/SPX is used primarily in a NetWare network, while AppleTalk is used to connect Macintosh clients to Host Integration Server 2000.
In addition to the server-to-host and client-to-server communications discussed above, Host Integration Server 2000 servers also need to communicate directly with each other. They need to do this in order to exchange information on network resource changes as well as to support other inter-server features of Host Integration Server 2000 such as the Distributed Link Service, Downstream connections support and PU passthrough. Host Integration Server 2000 supports a subset of the Host Integration Server 2000 Client/Server protocols for this purpose. Normally Host Integration Server 2000 servers will use TCP/IP for this. IPX/SPX is available for use in a NetWare based network for backward compatibility when Host Integration Server is running under Windows NT.
Terminal Emulation Services
In addition to providing network protocols, the Network layer also includes terminal emulation services.
Starting in the early 1970s IBM produced the 3270 family of display stations, printers and terminal cluster control units. Terminal devices such as displays and printers were normally connected to a cluster control unit via coaxial cables, which were then connected directly to the mainframe of to a front-end processor. Support for these devices came via the LU type 2 support that we discussed earlier in this paper. Somewhat later IBM also introduced the AS/400 mid-range computer system. These systems supported the IBM 5250 family of terminals. The 5250 fulfilled the same role as the 3270 in mainframe applications. Instead of using LU 2, however, it used LU 6.2 as a communications protocol.
Over time these relatively unintelligent terminals were replaced with personal computers. To continue to run the same applications, special client-based software was developed to emulate the functions of the original 3270 and 5250 terminals. IBM and other companies subsequently provided client-based terminal emulators such as Attachmate Extra! and Rumba. These client-based terminal emulators run completely on the client computer performing all protocol conversion and display/printer services locally.
Figure 13. 3270 Emulation Sessions. Host Integration Server 2000 offers a simple, multi-session, 3270 Client, while supporting popular third-party 3270 client programs.
Other emulators however, make use of a gateway approach to put part of the protocol stack on the client and part on a server. Host Integration Server 2000, and emulators that work with it use this approach. This splits the protocol stack and allows the emulator to have a smaller footprint on the client. Host Integration Server 2000 comes with basic 3270 and 5250 emulators that can be used to verify the correct installation and configuration of Host Integration Server 2000. These emulators are generally not suitable for production use, so one of the third party products needs to be acquired for this purpose. The Host Integration Server 2000 emulators also support file transfer and the operation of multiple terminal sessions on one desktop
The Host Integration Server 2000 emulators (and most third party emulators as well) also support the ability to automate mainframe sign on using a scripting language. This allows the emulator to work with the Host Integration Server 2000 Mainframe Security Integration features such as the Single Sign On feature discussed in the Management section of this paper.
To allow for even lighter weight clients, Host Integration Server 2000 also supports a version of 3270 and 5250 emulation that operates directly over TCP/IP. Since TCP/IP is the only client-side requirement and it normally already exists on the client, there is no need for any part of the SNA stack of Host Integration Server 2000 client to be located on the workstation. TN3270E and TN5250 allow a user to access the host computer TCP/IP network using a variation of the TCP/IP Telnet protocol.
Most 3270 emulators also support the ability to transfer files between a host computer and a workstation using the IND$FILE utility program. This program works in conjunction with a host operating system such as TSO or transaction processing monitor software such as CICS running on the host. It allows the client to request a file transfer manually and monitor the results.
In addition, Host Integration Server 2000 networking provides support for most of the 3270 and 5250 printing protocols such as those supported by LU types 1, 3 and 6.2 (APPC) devices.
Host Integration Server 2000 extends and enhances the already dominant support of network interconnections provided by prior versions of SNA Server.
Host Integration Server 2000, represents the latest evolutionary step on the way to a complete mainframe and peer host interoperability solution. Moving forward, Microsoft will focus on providing bi-directional interoperability with AS/400 and IBM mainframes computers at key interoperability layers. Additionally, Microsoft will work with third parties to provide add-on products to Host Integration Server 2000 that enhance cross-platform interoperability. As you can see, Host Integration Server 2000 is a product with which you can build your Web solutions today, while using it as a solid platform to support Microsoft .NET tomorrow.