For the first 30 years of business computing, IBM stood alone as the dominant provider of enterprise systems. Although the rise of the minicomputer in the late 70s and the introduction of the PC in the early 80s each promised to challenge IBM's dominance, it wasn't until the late 90s that systems based on these architectures could actually deliver similar performance and throughput. But the capability to deliver the same "speeds and feeds" isn't enough to convince most IS managers to abandon the systems and databases they've been building for years on IBM mainframes and AS/400s. Given that these systems aren't going anywhere for a while, it makes sense to consider ways to reuse their data and processes for new applications that are deployed using newer microprocessor technology and advanced operating systems, such as Windows Server 2000 and the newly released Windows Server 2003. Host integration challenges
Using data and processes from a legacy system allows enterprises to maximise their current investments. Moreover, given that these systems are fully debugged and have been running in production for months or years, companies can build new systems based on these legacy systems at a significantly lower cost and can mitigate a significant amount of risk. This integration can take place at one or more levels. If the legacy system was developed to support messaging protocols such as MSMQ, a new system can reuse existing data and processes by participating in the same messaging conversations. Many legacy applications were also developed using transaction monitoring and control systems such as IBM's CICS. CICS transactions give developers a single entry point to execute an atomic transaction that will be managed by the host but can participate in a broader transaction initiated by a controlling host, such as a .Net application. Both of these methods allow .Net architects to reuse the legacy code and the underlying data. In many cases, the applications weren't written to use these facilities. But even in these situations, designers can use the data stored on the host system directly, whether it's stored in a database such as DB2 or in flat file systems such as VSAM. The last -- but not the least -- consideration is security. When using any of these facilities, the application designer must consider the context in which they will be called. Will your system have to pass through an individual's security credentials, or can the host system accept group credentials? How do you transfer credentials securely? In fact, how does the new .Net system connect to the host to begin with? Microsoft's host integration solution
Once Microsoft realised that it wasn't going to replace the mainframe but had to find ways to interoperate with it, its old SNA Server product moved from a simple terminal emulation solution to a full-blown legacy integration server that was renamed the Host Integration Server (HIS). HIS allows a Windows Server running COM+ to communicate via APPC or TCP/IP over an LU 6.2 or IP network to host systems (including IBM mainframes running CICS or IMS and AS/400s). This communication can take place at the messaging, transaction, or data access level. For newer architectures designed for speed, efficiency, and maximum reusability, implementing your integration at the transaction level holds the most promise. Transaction-level integration
The HIS Transaction Integrator (TI) allows you to develop wrappers that run in the CICS client context and expose legacy applications as .Net servers. For example, I recently worked with a large insurance company that was developing a .Net-based customer support centre application. Rather than trying to move customer information from the mainframe to the local SQL database, we designed the system to use existing CICS calls to the mainframe to retrieve and update customer information. By creating HIS-TI wrappers for all of the key customer transactions, the application developers were able to access mainframe customer data using classes that shielded them from the complexity of host access and integrated seamlessly into the application. In the past, HIS has been focused on one-way reuse from the network application to the host. But the new version of HIS supports two-way reuse. Using HIS, a COM+ or .Net server can be configured to listen for calls over the wire from CICS, IMS, or AS/400 applications. Using this technology, host applications can integrate objects from newer network applications. In either scenario, HIS takes care when converting between host and .Net CLS data types as a core function of the TI designer. The TI designer is an HIS tool that can process host source files (in RPG or COBOL) or interrogate host services to create the base wrapper that a developer can turn into a managed assembly. In cases where a messaging or transaction interface doesn't exist to create the managed wrappers, you can still go after the data directly using the managed provider for DB2 included in the new release of HIS. Aren't Web services the future?
With all the hype around Web services, you would expect that the standard answer to this problem is to wrap both systems with Web services. However, until the security, coordination, and routing standards mature, Web services are best used for read-only or noncoordinated transaction scenarios. Until IBM implements Web services interfaces on its legacy systems, you can expose the HIS wrappers as Web services and publish host services using HIS. This is a quick and inexpensive way to reuse mainframe facilities without having to make any modifications to the legacy systems.