Inside Babylon

The last best hope for Microsoft's enterprise interoperability server

Microsoft's newest enterprise interoperability server, code-named Babylon, is the company's planned replacement for the BackOffice suite's SNA Server product. As with SNA Server, Microsoft designed Babylon to integrate Windows networks with IBM mainframes and AS/400s. However, one of Microsoft's primary goals for Babylon is to move past the constraints of SNA Server and fully embrace TCP/IP as the underlying networking protocol. Microsoft's secondary goal for Babylon is to deepen the integration level that the server provides. Microsoft intended SNA Server to provide basic host connectivity, but Babylon will warp past the basic connectivity layer and into the realm of application integration. Microsoft's newest enterprise interoperability server includes many significant new features, some of which leverage existing SNA Server technology, but Babylon is still missing pieces of the enterprise-interoperability puzzle.

SNA Server Enterprise Roots
Babylon is an evolutionary but not revolutionary change from SNA Server. Although Babylon moves beyond SNA Server's connectivity constraints and extends SNA Server's integration level, the upcoming release includes many of SNA Server's enterprise-level features.

SNA Server has always provided great enterprise scalability, and Babylon will inherit this quality. Babylon will support up to 30,000 host sessions and provide load balancing and hot backup. Also, Babylon's hot backup and dynamic load balancing don't require Microsoft Cluster Server (MSCS). As in SNA Server, Microsoft built these features into Babylon.

Hot backup requires at least two enterprise interoperability servers—a primary server and a backup server. The primary server maintains the configuration files that define the hosts and connections, and the backup server maintains a read-only copy of the configuration files. You use the primary server when you first establish a connection between the client and host. If the primary server is unavailable because of a network or system outage, the client system can immediately reestablish a connection to the host through the backup server. When the primary server comes back online, any new client sessions will connect through the primary server.

Dynamic load balancing is closely related to hot backup. When multiple enterprise interoperability servers are available, you can configure the servers to dynamically split client demands between the servers. As an organization requires new connections and services, Babylon automatically uses the server with the lightest load to optimize performance. Dynamic load balancing helps ensure that the host connections operate optimally without user or operator intervention.

Network Interoperability
Microsoft targeted Babylon to provide host integration at three levels: network, data-access, and application. At the networking level, Babylon will provide full TCP/IP support. SNA Server has supported native TCP/IP for client connections since version 3.0, and SNA Server 4.0 Service Pack 2 (SP2) and later provide host connectivity over TCP/IP. However, mainly because of the product's name, users have always perceived SNA Server as an SNA-centric product in a TCP/IP world. One of Microsoft's main goals in relaunching SNA Server with a different name is to distance the product from the aging SNA moniker.

On the server side, Babylon will support Windows 2000 (Win2K) and Windows NT 4.0. On Win2K servers, Babylon will be able to take advantage of Active Directory (AD) and Win2K's security enhancements. Babylon's AD integration will include the ability to perform LU assignments and configure host security by means of AD tools. AD will also eliminate the need to configure the Babylon server names on each client, which will simplify client configuration. Babylon's security-integration features include password synchronization between Win2K or NT and the host and single sign-on (SSO) support.

On the client side, Babylon will provide network-gateway functions for terminal emulation, printing, file transfer, and shared-folder file support. Babylon will also support the same client-side networking protocols that SNA Server supports, including TCP/IP, IPX/SPX, NetBEUI, Banyan VINES, AppleTalk, Data Link Control (DLC), and DECnet. Figure 1 provides an overview of the network support that Babylon will offer.

Babylon will also provide a new management interface. Babylon's management console is a Microsoft Management Console (MMC) snap-in.

For configuration and management, Babylon will provide support for Windows Management Instrumentation. WMI technology is an implementation of the Web-Based Enterprise Management (WBEM) initiative for Windows platforms. WMI lets you access Babylon services and management data through a COM programming interface. Babylon provides support for scripting in the WMI-scripting interface. To implement custom applications for automated management, administrators and developers can use a variety of COM-compatible languages, including Microsoft Visual Basic (VB), Visual Basic for Applications (VBA), VBScript, JScript, and Perl.

Data-Access Interoperability
One of the major data-access enhancements in Babylon is support for IBM's Distributed Relational Database Architecture (DRDA). IBM developed DRDA to let you perform database operations across distributed databases. Babylon will be able to function as a DRDA server, routing incoming DRDA requests to a Microsoft SQL Server system. This functionality will let IBM hosts and products that support DRDA (e.g., Data Propagator) access SQL Server databases in the same way they access data on other remote DB2 hosts. Administrators can also use this DRDA support to let remote applications running on IBM hosts and AS/400s perform a remote SQL Connect to SQL Server. In addition, Babylon's DRDA support lets the applications use a peer-to-peer connection to access SQL Server databases as if the SQL Server system were an IBM host.

Babylon also provides several ODBC drivers and OLE DB providers that extend the data access of Microsoft Office and BackOffice applications to DB2, Virtual Storage Access Method (VSAM), Oracle, DB2/400, OS/400, and Sybase. Babylon will provide ODBC drivers for DB2, Oracle, and Sybase and OLE DB providers for VSAM, DB2, OS/400, Oracle, and Sybase. Babylon's ODBC driver and OLE DB provider for DB2, VSAM, and OS/400 will all work over TCP/IP and SNA. The ODBC driver and OLE DB provider for Oracle will require you to install Oracle client runtime support.

Another data-access integration feature that Microsoft has planned for Babylon is a heterogeneous replication service. This service enables support for bidirectional replication between SQL Server and DB2, DB2/400, and Oracle, using snapshot, incremental, and merge replication technology. As its name suggests, snapshot replication periodically transfers an entire copy of the current data publication to the subscriber. Incremental replication distributes incremental changes to the subscriber on a near realtime interval. Merge replication lets autonomous sites periodically merge all database changes in a bidirectional manner.

Babylon's heterogeneous replication extends SNA Server and SQL Server 7.0's basic replication scheme. SQL Server 7.0 provides one-way snapshot replication to VSAM, DB2, Oracle, and DB2/400. Babylon extends this functionality by supporting the incremental and merge replication types and the ability to replicate data that originates from DB2, Oracle, and DB2/400 to SQL Server. Microsoft will also add support for replication from SQL Server to Sybase. Figure 2 shows current SQL Server 7.0 replication functionality and how Babylon's heterogeneous replication service will extend it.

Babylon's heterogeneous replication runs as an NT service and works by creating a set of triggers that you must add to the host database. These triggers then populate a host-based transaction table that you access by using one of Babylon's OLE DB providers. OLE DB providers let Babylon's heterogeneous replication service access host data without an additional host-based replication component. Babylon then integrates the host transactions with SQL Server's Distribution database, which SQL Server's Distribution Agent controls. Figure 3 provides an overview of Babylon's heterogeneous replication architecture.

Application-Integration Features
At the application-integration level, Microsoft will ship Babylon with COM Transaction Integrator (COMTI) support, which is a part of SNA Server 4.0. COMTI lets developers quickly build e-commerce and n-tiered applications that are integrated with existing IBM CICS and Information Management System (IMS) transactions. Using COMTI, Windows developers can hook into existing IMS or CICS host transactions without any host programming. Babylon will provide a COMTI Component Builder that can read the linkage section of existing COBOL source code to automatically generate COM components. Developers can then incorporate these COM components into Microsoft Transaction Server (MTS) packages that provide synchronous transaction coordination between MTS and CICS and IMS with support for two-phase commit (2PC). On the host, COMTI requires CICS 3.3 or later or IMS 4.0 or later. IMS's 2PC support requires IMS 6.0. On NT 4.0 systems, COMTI requires MTS 2.0 from the NT 4.0 Option Pack.

Babylon will extend the existing COMTI support to include support for the 3270 terminal-oriented space, host-initiated transactions, and COM+ load balancing and queued invocation. To implement COMTI for 3270 terminal-based applications, Babylon will intercept and parse an incoming data stream, letting the COMTI components fill the data stream sections that a terminal user usually fills. In other words, COMTI for the 3270 data stream will provide a sort of on-the-fly screen-scraping interface for existing 3270 applications. However, server-based parsing of the data stream adds overhead to the server, so Babylon's COM+ load balancing optionally distributes the COM components to another application server, moving them off the primary Babylon server. Microsoft also plans to include COMTI support for the 5250 data stream, but not in the first Babylon release. Babylon's COMTI implementation includes support for host-initiated transactions over both SNA and TCP/IP.

The first Babylon release will include a software development kit (SDK) that Microsoft has oriented toward independent software vendors (ISVs) and other advanced application developers. The SDK will include interfaces and example programs for common environments.

Microsoft plans to support Extensible Markup Language (XML) and BizTalk server in Babylon. Babylon's XML support will add bidirectional XML support for host transactions. Babylon will map the CICS or IMS host transaction to an XML document, then send it to the BizTalk server. On the way back to the host, Babylon will map the XML response from the BizTalk server into the native format that the host's CICS or IMS application expects.

Another application-level integration feature that Microsoft carried over from SNA Server to Babylon is the Microsoft Message Queue Server (MSMQ)-MQSeries bridge for cross-platform messaging support. Babylon's MSMQ-MQSeries bridge connects MSMQ messaging middleware and IBM's MQSeries messaging middleware. Both software products provide guaranteed asynchronous message delivery to implement highly reliable distributed applications on their respective platforms. However, these products can't interoperate. Babylon's MSMQ-MQSeries bridge provides the hooks required to send messages between MSMQ and MQSeries. Babylon's MSMQ-MQSeries bridge supports MQSeries on AS/400, MVS, Virtual Storage Extended (VSE), UNIX, Digital Equipment's OpenVMS, and Tandem NSK.

Beyond Babylon
One of the main components missing from Babylon is network-level support for UNIX. Microsoft's definition of enterprise interoperability seems to include IBM but not UNIX. Rumors circulated that Babylon would include Microsoft Windows NT 4.0 Services for UNIX (SFU); however, at the time of this writing, SFU will remain a separate product. The UNIX support that Microsoft included in Babylon is primarily at the data-access level through the ODBC and OLE DB support for Oracle and Sybase.

The lack of UNIX services leaves Babylon a bit short of true enterprise-level interoperability, but Babylon promises to provide a new level of integration—especially for IBM mainframe applications. Microsoft recognizes that IBM mainframes and AS/400s might be out of vogue but will be key computing platforms for many years to come. Business from big enterprise customers will require Windows integration with these platforms. Babylon promises to provide the interoperability glue needed to join Windows Distributed interNet Applications (DNA) architecture and the enterprise. Microsoft scheduled Babylon for release to beta sites in fall 1999, with general availability scheduled for spring 2000.