In-Depth

The SNA Server Model: Integrating Mainframe Hosts and NT Server Environments

• 12/01/1998

The latest wave of application development involves less the creation of new applications than the extension of legacy applications - those traditionally hosted on IBM mainframe and AS/400 platforms - to the World Wide Web. Whether as part of an effort to build private extranets with select business partners or to extend workhorse transaction processing applications to new customers worldwide via the Internet, many companies are seeking reliable methods for integrating the old with the new.

Integration means different things to different people. To some, integrating legacy applications and databases with Web front-end apps involves a technique referred to as "screen scraping." The legacy, or back end, application is operated on its host platform while a new process captures relevant screen information and forwards it to a Web application for presentation to the end user. End user input is submitted to the legacy application by a similar process.

In other cases, integration translates to interapplication messaging. Interaction by the end user of the Web application is forwarded as a series of messages, handled typically by messaging middleware, to the back-end host. There, the messages are translated for use by the legacy app and resulting work is messaged back to the Web application.

In still other cases, direct object links are established between elements of the old and new application so that the two become a single application delivered for use by end users. Between this "tight integration" option and the "loose integration" option favored by screen scrapers are many hybrids and combinations that reflect the preferences of the developer, the capabilities of the development tools and the budget for the project.

Clearly, with the Web extension of legacy applications, there are - to paraphrase the axiom - many roads to Rome. At least some of these roads pass through Redmond, Wash.

According to Mike Gilpin, Vice President of Giga Information Group, more than 50 percent of Fortune 500 companies are actively engaged in the Web-enablement of their legacy applications. He notes that two strategies currently predominate the market.

"There are different integration approaches that are appropriate in different cases. Some companies can make do with new shrink-wrapped products that are coming to market that offer an end-to-end Web-enabling solution in a box. The productized approach involves a mix of code and middleware pre-configured for a specific business application, usually a popular application, and therefore requires minimal time to deploy. The other option is to roll your own solution, which is the method preferred by many large financials. I call these infrastructural solutions and I would say that in the companies I work with, fully a third of them, involve the use Microsoft SNA Server."

Gilpin says that Microsoft’s SNA Server plays well in environments where the predominant platforms are Windows and mainframe technologies, "Using SNA Server and custom-coded Visual Basic programs, you can directly invoke mainframe transactions from the front-end application. This is an extremely tight form of integration. The added benefit is that the communications (COM) area definitions that are established with SNA Server let you get even more creative. You can combine COM interface inputs from multiple applications running on the mainframe and on other NT platforms to create entirely new applications. Infrastructure solutions are more flexible than productized solutions and offer companies more capability."

Against this backdrop, Microsoft’s Kevin Kean and Vesa Suomalainen are quick to assert that SNA Server is a platform or an enabling technology for integration rather than a product.

"Simply put," says Kean, Group Product Manager for Communications Products at Microsoft, "SNA Server exists because a lot of applications continue to reside on legacy platforms. Companies want to preserve their investment in legacy technology, but they also want new capabilities, such as Web-to-host integration. SNA Server provides a software bridge between legacy application software and NT Server."

Historically, Kean observes, legacy applications were accessed via dumb terminals distributed throughout the business environment. SNA networks provided the protocols for communications. "Fifteen years ago," adds Suomalainen, a director within Microsoft’s Interoperability Group, "Direct connections gave way to gateways. This trend has continued with the rising popularity of TCP/IP networks."

Microsoft’s SNA Server, introduced in September 1990, was one of a cast of many gateway products available to support terminal emulation and mainframe access within Windows environments. There was little to distinguish the product from its competitors save perhaps for implicit assurances that it would interoperate with Microsoft desktop and server operating systems in a Microsoft-sanctioned manner, resulting in fewer problems.

Like most early gateways, SNA Server addressed a very specific requirement: the sharing of a fixed number of communications ports among a growing population of LAN-connected users. Over time, however, connectivity capabilities were augmented by a growing set of features aimed at enhanced application access.

Kean notes that application programming interfaces (APIs) and services were added to versions 2.0 and 2.11 of the SNA Server that began setting the stage for application integration at a deeper level –- the level of the CICS transaction. "Since that time, as customers have increasingly sought to build applications that integrate data sources from both legacy and distributed platforms, the capabilities of SNA Server have been expanded to meet the need."

For example, says Kean, SNA Server supports Open Data Base Connectivity (ODBC), an API that allows a programmer to abstract a program from a database. ODBC calls enable programmers to access data in legacy databases without needing to learn proprietary database languages. Programmers need only need to use the ODBC language (a combination of ODBC API function Calls and the SQL language) and an ODBC Manager will figure out how to contend with the type of database that is being called.

Another integration approach cited by Kean entails the building of an "object-based bridge" between a legacy-based application like CICS and the Microsoft Transaction Server, which is part of Windows NT. Kean notes that SNA Server enables these types of tight application integration between NT hosted applications and those residing on mainframes and AS/400-class host systems.

The latest rendition of the product, Version 4.0, offers features that make clear the direction of SNA Server as much more than a simple communications gateway. For example, the product includes the Microsoft COM Transaction Integrator for CICS and IMS (COMTI), which provides client applications with access to the two most popular mainframe Transaction Processing (TP) environments - CICS and IMS/TM. Working in conjunction with Microsoft Transaction Server (MTS), COMTI makes CICS and IMS programs appear as typical MTS components that can be used with other MTS components for building distributed applications. COMTI brings drag and drop simplicity to developing sophisticated applications that integrate Web transaction environments with mainframe transaction environments.

Central to this feature is the COMTI Component Builder, which provides a COBOL Wizard to help the developer determine what data definitions are needed from the COBOL program and to generate a component library (tlb file) which contains the corresponding automation interface definition. When the component library is dragged and dropped into the MTS Explorer, a COM object is created that can invoke a mainframe transaction. This allows developers to build applications using Active Server technologies that can easily include mainframe transaction programs (TP).

Similarly, mainframe developers can avail themselves of mainframe TPs available to Microsoft Windows-based Internet and intranet applications. Developers do not have to learn new APIs, nor do they have to program custom interfaces for each application and mainframe platform. Moreover, since COMTI does all of its processing on the NT Server, there is no COMTI executable code required to run on the mainframe, and developers are not required to rewrite most mainframe COBOL programs. Client application calls are treated by mainframe TPs simply as if issued by another mainframe program.

In addition to COMTI, SNA Server 4.0 expands on its earlier capabilities intended to support "seamless access to host data." In prior releases, SNA Server offered an ODBC/DRDA driver for DB2, and file access mechanisms like the Shared Folders Gateway and AFTP. With version 4.0, Microsoft has added the OLE DB Provider for AS/400 and VSAM, which allows record-level access to mainframe VSAM files and the AS/400 native file system.

Microsoft says that the OLE DB provider enhances ease of use when developing applications for discrete data access. This component provides record-level access to both physical and logical files on the AS/400. On the mainframe, the feature delivers record-level access not only to most types of VSAM files, but PDS and PDSE files, too. No retraining is required: programmers who are familiar with Active Data Objects (ADO) can use it. Further, developers do not have to learn the intricacies of APPC programming because the new technology hides the complexities of SNA.

Given the new features of SNA Server 4.0, Kean asserts that it is less a product in itself than a platform for developing other solutions. In addition to direct links to legacy applications and databases, SNA Server can be used in conjunction with Microsoft’s MSMQ messaging middleware, for example, to build a bridge to MQSeries middleware from IBM, creating a seamless message-queuing environment.

Another simple, yet popular application for the platform, Kean notes, is to distribute reports via networks and the Internet rather than using paper printouts, "Whatever application a customer wants to build on a front-end system, whether for internal use or use across the Web, can be facilitated using the SNA Server."

In addition to the diverse uses for the platform made by customers, Kean points out that Microsoft’s business partners and independent software developers have built a variety of third-party capabilities around SNA Server. Most use the product deliver emulated 3270 screen data to the Web or across internal intranets.

Clearly, SNA Server has moved far beyond the original definition of an SNA Gateway. Today, it is a centerpiece of legacy integration efforts. One caveat to its almost universal appeal is suggested by Giga Information Group’s Gilpin.

"SNA Server plays well in companies that primarily use Windows and mainframes. For companies with an investment in UNIX systems that must also be integrated, SNA Server may not be the best or only choice. They may also want to explore platforms that make UNIX the first citizen. While some capabilities are being added to SNA Server to include UNIX systems in integrated solutions, additional support for load balancing and transaction monitoring in the UNIX environment isn’t there yet."

Gilpin says that Microsoft’s past project with Software AG, and their subsequent decision to move the project in house, suggests that UNIX support is being developed for SNA Server. For now, he says, one may need to consider additional products from IBM and third-party providers to compliment SNA Server in order to obtain all of the support required for a tightly integrated solution.

ABOUT THE AUTHOR: