| Host Integration Server 2000 Released to Manufacturing |
| Sep. 18, 2000 |
Host Integration Server (HIS) 2000 is an upgrade of SNA Server 4.0 and joins Microsoft’s new 2000-series server lineup. Although the product contains only modest improvements over its predecessor, its new name reflects a change in focus: Microsoft is de-emphasizing the product’s function as a System Network Architecture (SNA) gateway and is instead focusing on HIS’s role as middleware, integrating Windows DNA server-based applications with legacy host applications and databases. Organizations are rapidly redesigning their systems to meet the needs of a new generation of Web and e-commerce applications. For large, established firms, this normally requires linking data and legacy applications running on IBM mainframes and AS/400s with these new server-based applications. HIS 2000 provides key services needed to link applications running on Windows 2000 Server, Internet Information Server (IIS), Commerce Server, BizTalk Server, or AppCenter with those legacy back-end systems. Without HIS 2000 and future upgrades that bring HIS in line with its .NET initiative, Microsoft risks losing much of its server business with mainframe-dependent customers to competitors, especially IBM, that are focusing on platform independent Java-based solutions. This article explores changing requirements for legacy host integration, the approach competitors are taking, and how HIS 2000 integrates Microsoft’s Windows DNA architecture with legacy IBM systems. The sidebar "What’s New in Host Integration Server 2000" details the changes in HIS 2000 compared with SNA Server 4.0. The diagram, "Levels of Host Integration" illustrates the different ways HIS 2000 can integrate PC LAN-based systems with host-based databases, applications, and security systems. Mainframe Use Is Changing Although client/server and Web applications have together dominated the information technology (IT) industry’s attention over the past decade, the fact remains that the vast majority of business-critical data owned by large organizations still resides on IBM-compatible mainframes and IBM AS/400 minicomputers. Large organizations can have tens of millions of lines of 10- to 30-year-old COBOL code tied up in applications that use IBM’s Information Management System (IMS) or Customer Information Control System (CICS) transaction systems and databases. Even as relational databases such as IBM's DB2 gained greater acceptance in the nineties, they continued to be hosted primarily on mainframes and AS/400s. Although mainframe numbers appear to be static, these systems are critical to their owners, and migrating them to a more modern architecture—with data on server-based relational databases accessed by server-based middleware that incorporates business and application logic—is usually prohibitively expensive and risky. Yet, competition and changing business needs demand that these legacy-based applications and data be Web-accessible today. When PC LANs first became popular, a class of products (of which SNA Server is a member) evolved to connect LANs to legacy hosts, especially IBM mainframes and AS/400s. The original focus was on using more versatile PCs to replace dedicated dumb terminals. PC-based software emulated IBM 3270 and 5250 terminals and connected to a gateway server on the LAN. The gateway translated between the LAN protocols that PCs use and the SNA protocol used by the host. Many of these gateway products also supported a technique called "screen scraping," which links the position of text on a terminal display with data required by other applications. For example, the first eight characters on the second line of a specific terminal screen might be a customer number. Although this technique worked, it was not robust or scalable. Any change to the screen layout of the text on the terminal would possibly break the link to other applications. Screen scraping was primarily used to layer a graphical interface on top of a legacy terminal-based interface. In recent years, the focus of host-to-LAN integration has shifted away from workstation-based terminal emulation and SNA connectivity because of two developments: Hosts running TCP/IP. Many legacy systems are now connected directly to TCP/IP-based LANs and no longer require SNA, essentially making big "servers" out of legacy hosts. In these cases, workstations or application servers that want to access host-based data or applications no longer need an SNA gateway to access them. The shift to Web and e-commerce applications. Most organizations are now developing multi-tier application architectures consisting of a presentation layer (usually Web-based) that provides a user interface, one or more business logic layers that massage the data according to business rules, and a data layer that accesses raw data. In cases where the data layer and business logic still reside on legacy host systems and redesigning the entire application is unfeasible, these organizations need host integration tools to link their Web servers or other middleware applications with the hosts. Developers favor host integration solutions that allow them to use familiar tools, languages, and programming interfaces without having to learn the intricacies of the host system’s applications and databases. Competitors Push Java Solutions for Host Integration One way to integrate hosts with modern e-commerce and Web-based intranet applications is to build middleware applications with Java "servlets" or Enterprise JavaBean objects, and to use commercial host integration solutions based on these Java technologies to get at the data. Attachmate, BEA, IBM, WRQ, and other vendors have taken this approach in creating a rich assortment of host integration products. Although nearly all corporate and independent software vendor developers face the "Windows DNA vs. Java" development path decision, the threat to Microsoft is most acute when customers need to integrate Web-based solutions with legacy systems. If successful, the Java-centric strategy favored by most Microsoft competitors threatens Microsoft for the following reasons: Windows 2000 is not needed. Java- and Enterprise JavaBean–based host integration products rarely require Windows 2000 or any of its services. Because corporations and solutions providers have not yet built up a rich installed base of middleware products that utilize Microsoft’s COM component technology, these customers are not anchored to Windows DNA and could be swayed by the platform-agnostic Java-centric approach. Other Microsoft server products will be impacted. A shift to Java-centric host integration middleware not reliant on Microsoft-specific technologies such as COM and Active Directory (AD) will also hurt sales of other Microsoft server products—especially Commerce Server, BizTalk Server, and AppCenter Server—that only run on Windows 2000 and are meant to integrate with other products using COM. Although the XML-based Simple Object Access Protocol (SOAP) should eventually eliminate this issue, COM is the only feasible way that these new Microsoft server products can link with host integration middleware today. Developers could move away from COM. The decision to go with Java or with Microsoft’s COM technology for creating middleware is a critical fork in the road for developers. If they take the Java path, Microsoft will have a difficult time getting them back. Windows.NET is not ready. The recent .NET announcements make clear that the .NET framework will replace the COM-based architecture of Windows DNA. Since .NET is one to two years off and many developers are concerned that Microsoft could fail to deliver on its ambitious promises, this "COM limbo" could motivate middleware developers to abandon the Windows DNA platform for Java. Furthermore, the current Visual Studio tools still don't provide the same depth of support for writing middleware business logic compared with what they provide for desktop and client/server applications. Better support won't come until Visual Studio.NET ships next year. The IBM Threat IBM in particular poses a special threat to Microsoft for the following reasons: Ownership of the host software. IBM controls nearly all of the major mainframe operating systems, the OS/400 operating system for its popular AS/400 minicomputers, the DB2 relational database, and the IMS and CICS transaction systems. Together, systems utilizing these technologies contain the bulk of all host-based data and applications. IBM has both the knowledge and incentive to develop a rich set of host integration tools so that they can keep customers on these systems. Customer relationships. IBM has maintained close ties with its mainframe customers and knows how these customers use IBM products. IBM can deliver very focused products and relevant marketing messages to a well-defined customer audience. Linux and AIX focus. Although IBM’s NetFinity servers, WebSphere e-commerce product, and host integration tools will all work with Microsoft server operating systems, it is not a requirement. Given the opportunity, IBM will push servers running Linux or AIX (IBM’s Unix) as the preferred middleware platform. Because of these obstacles and threats, Microsoft clearly needs a strategy to keep these customers in the Microsoft camp during the .NET development cycle. How HIS 2000 Affects Microsoft’s Host Integration Strategy Microsoft has long been pragmatic about the longevity of the mainframe and AS/400 markets. While Microsoft is trying to create "enterprise class" server products (especially SQL Server 2000 and Windows 2000 Datacenter Edition) that can replace mainframes, they understand that they must integrate well with existing legacy systems for many years to come. Since their largest and most prestigious customers are most likely to depend on legacy systems, having a good host integration story is a crucial part of Microsoft’s server strategy. SNA Server has been around for many years and is an "enabler" technology. Although it does not generate much revenue to Microsoft directly, host integration software is too important to Microsoft’s strategy to leave to third parties. HIS 2000 improves Microsoft’s host integration story by rolling in features introduced in SNA Server 4.0 Service Pack 2, and adds Windows 2000 support, new integration features, and improved performance and manageability. For more detailed information on the differences between HIS 2000 and its predecessor, see the sidebar "What’s New in Host Integration Server 2000." Microsoft’s thrust with HIS 2000 is to offer a competitive alternative to Java-based host integration approaches and to make sure that developers can write COM-based middleware that robustly links the most popular host-based databases and transaction environments without requiring any changes on the host. HIS 2000 focuses on two types of integration: access to host data and access to host applications. Access to Data HIS 2000 provides developers with COM and ODBC programming interfaces that allow them to access mainframe-specific data storage, such as Virtual Storage Access Method (VSAM) files, AS/400 files, or DB2 databases, without requiring any changes or additional software on the mainframe or AS/400. These interfaces shield middleware developers from having to understand the host’s native programming interfaces. In most cases, the mainframe data is used in a read-only manner, but HIS 2000 can also write to these files and databases and even supports two-phase commit DB2 transactions. Access to Applications If the host data and application logic is contained in IBM’s IMS or CICS transaction systems, or the host is running applications utilizing IBM’s MQSeries message queuing, HIS Server also provides facilities that allow COM-based middleware to transparently access the host’s CICS or IMS applications, again shielding developers from the intricacies of host programming and eliminating the requirement for changes to code on the host. Microsoft’s partnership with Software AG has produced an add-on product to HIS 2000 called the "CICS 3270 Adapter." This product allows COM-based middleware to access older monolithic CICS applications. Prior to this technology, screen scraping was the only other way to integrate them. Will Microsoft’s Host Integration Strategy Work? Because of Microsoft’s recent shift to its .NET initiative, it is particularly difficult to predict whether Microsoft’s host integration strategy will stem the flow of developers to Java. Many factors work for and against Microsoft’s approach. Factors Supporting Microsoft Strong developer base. Microsoft has an enviable base of third party and corporate developers with deep skills and experience on the Windows DNA platform and Visual Studio 6. Even if HIS 2000 and Visual Studio 6 do not address their host integration needs quite as well as competitive Java-oriented offerings, sheer inertia gives Microsoft a degree of breathing room while they execute on their .NET plans. High share of e-commerce Web servers. IIS is the leading Web server for e-commerce and intranet Web applications. It should be easier for developers to link IIS-based applications with legacy host data using HIS 2000 than for them to drop their Web server infrastructure in favor of a new Java-based platform. Commitment to the Microsoft platform. Windows 2000 is finally maturing and organizations want to reap the benefits of their substantial IT investment in Windows-based server infrastructure. For this reason, they will resist a move to Java on Linux or Unix unless Microsoft and its partners cannot provide competitive solutions to their host integration needs. Immaturity of Java. Java-based technologies are relatively new. Skilled Java developers are still scarce compared with Visual Studio developers. Java development tools and technologies are also immature. Sun finalized the Java 2 Enterprise Edition API specification only recently, so organizations risk many pitfalls if they choose development tools that do not succeed commercially. Factors Working Against Microsoft Marketing by competitors. Nearly all of the major system vendors are promoting Unix or Linux-based middleware platforms and have embraced Java technologies for server applications. Their flood of marketing messages could start to make Microsoft customers question their commitment to the Windows DNA platform. Confused message. Microsoft’s customers are just now grappling with what .NET really is and whether it will be successful, but they need to build systems today that integrate host data. They could decide that the risks of jumping into the Unix/Java camp are lower than muddling through the transition period to .NET. Time. As mentioned earlier, .NET is several years off. While Visual Studio.NET promises great tools to build middleware applications, it will not be available for another year. During this time, competitors will have a window of opportunity to woo Microsoft-centric developers. Microsoft’s lack of mainframe skills. Outside of its small HIS development team, Microsoft has little in-house mainframe knowledge, skills, and experience, especially when compared with firms like IBM and BEA. This may make it difficult for Microsoft to offer total host integration solutions that work better than the competition’s. However, by partnering with other firms such as Software AG and Level 8, Microsoft has offset some of this limitation. Pricing and Resources Unlike its predecessor, HIS 2000 uses Microsoft’s new per-processor pricing model. The estimated retail price is US$2,500, and no other pricing model is supported. As described in "Some Windows 2000 Server Products Get Per-Processor Pricing" on page 10 of the Aug. 2000 Update, this will make HIS 2000 more expensive in some scenarios and less expensive in others. The cost is not affected by the features that customers use; the only question is how many servers and CPUs are required to deliver the desired services. For more information on technologies contained in SNA Server 4.0 and in HIS 2000, see "SNA Server 4.0 Final Beta Available" on page 5 of the Dec. 1997 Update. For more information on HIS 2000, see www.microsoft.com/hostintserver. |