In a recent Gartner survey, 48 percent of enterprises worldwide reported plans to adopt Microsoft .NET technology. Considering that .NET entered the marketplace as recently as February 2001, this survey sends a resounding message ­ Microsoft technology has established a strong foothold in the enterprise computing arena.

Microsoft .NET is the future direction of the Microsoft software machine. With over 6 million Visual Studio .NET developers in the market and the stated goal of allowing these developers to create "reliably built, hosted, deployed, and utilized solutions using Web services," .NET has been or will be integrated into all Microsoft products.

Determined to make its mark in a space long dominated by IBM and other Java-centric vendors, Microsoft has devoted a great deal of resources to rounding out its overall offering to the enterprise. Furthermore, Microsoft's commitment to user-friendly, application development technology that requires significantly less coding than rival platforms only means that this adoption rate will continue to climb in the years to come.

Mainframe Computing Remains Steadfast
As the battle between Microsoft and Java continues to heat up, interestingly enough there are more transactions processed by IBM CICS (Customer Information Control System) and IMS (Information Management System) systems than by the Internet in its entirety. Of the Fortune 500, 490 companies leverage CICS alone to process more than 30 billion transactions, or $1 trillion worth of business, each and every day.

IT departments in large corporations manage over 50,000 CICS code modules written in COBOL, Assembler, or PL/I. The oldest modules are 25 to 30 years old, but still continue to process mission-critical data every day ­ and due to the extraordinary level of customization these applications have endured ­ they will continue to function for many years to come. Reinforcing this position, organizations devote approximately 75% of yearly IT budgets toward maintaining and evolving this mainframe code.

Despite the continued reliance on legacy computing, enterprise technology has evolved at an exponential rate over the past decade ­ especially in the case of Microsoft. While many of these new technologies have failed to make the leap from theory to practical adoption and on to persistence, one vision ­ the .NET service-oriented architecture (SOA) ­ has revolutionized the way developers think about building enterprise applications. In short, .NET offers more than just technological hype, instead promising to deliver a standardized way to develop and deploy modern enterprise applications.

Organizations today are already building modern components and Web services using .NET technologies, but the reliance on legacy applications is ever present. Therefore, the challenge for enterprise organizations lies in the need to incorporate legacy applications within the modern service-oriented architecture of .NET. Once this is accomplished, the next hurdle is performance ­ getting the most out of the mainframe via the SOA.

Since it is too costly and risky to simply recode core mainframe applications in .NET-centric programming languages, enterprise developers must leverage a tool to isolate specific business transactions from within multiple legacy systems and expose these transactions as reusable components and Web services within .NET. Furthermore, these components and Web services must communicate with mainframe logic in a manner that optimizes performance at runtime. Only by doing so will enterprise organizations truly realize the benefits of .NET and the service-oriented architecture.

The Pathway to Mainframe Logic
Central to this challenge is the manner in which developers access core host logic from the .NET Framework. In the past, enterprise organizations have employed a variety of products to help incorporate mainframe applications into more modern computing paradigms. From simple emulation tools to advanced extension solutions to message queuing software, these products are still in use at many large organizations today. However, as technology evolves, so do the technical and business requirements that influence the enterprise adoption cycle.

Direct to Raw Data
Direct database calls to raw mainframe data sound like an ideal solution. They deliver lightning-quick response times, and allow the developer to repackage the data upon retrieval in any format needed. Unfortunately, all is not as it seems. The original developers of mainframe systems were faced with a shortage of hard-drive storage space. To get around the tremendous costs of storage on the mainframe, developers stored most mainframe databases within various types of compressed files built with very confusing formats.

Additionally, by accessing the data directly, developers lose the real benefit of most mainframe applications ­ the business logic. In legacy mainframe systems, the business logic is tied into the user interface layer, so by going directly to the raw data, developers lose the ability to decipher the meaning of that data. This approach also runs the risk of corrupting the data when writing back to the mainframe database, since many applications have data that is updated from batch (or offline) applications.

Screen-Based Entry to Logic
For years, because of the failings of direct database access, screen scraping was the accepted method of accessing mainframe logic from Windows or ASP applications, and in some cases today, screen scraping is still necessary. If, due to technical reasons, a screen-based approach is needed, there is a significant number of vendors that can fulfill these requirements and provide rapid access to a variety of mainframe systems.

It may be that there is no tool available that offers an alternative to a screen-based approach for a particular type of mainframe environment (this is true for many types of systems), or it may be that the customer does not own the mainframe. Whatever the case, in these situations the mainframe integration engine will act as a stand-alone application server and reside somewhere within .NET.

However, complicating this type of installation is the proprietary nature of most mainframe integration technologies. Most enterprise organizations would rather not paint themselves further into a corner, so it is important for architects to find as open a solution as possible so that they may truly utilize the benefits of the .NET Framework.

To this end, certain vendors in the Microsoft camp have written their integration tools in .NET programming languages such as C#. By doing so, these vendors allow the enterprise to deploy the integration engine natively within .NET. Additionally, the source code enables developers to script custom code and easily extend functionality to disparate applications.

While these types of tools offer good flexibility, sometimes the level of runtime performance provided by a screen-based approach is simply not enough ­ especially when developers are dealing with the enormous number of transactions characteristically handled by large mission-critical mainframe applications.

Uninterrupted Approach to Logic
However, as discussed, technological evolution continues, and as they attempt to incorporate mainframe processing functionality into the .NET SOA, enterprise organizations are ready to take a strategic step forward. By allowing organizations to easily and cost-effectively migrate from a screen-based approach and middle-tier deployment, certain technologies represent this step forward.

When working with CICS on the mainframe, there exists today a much more attractive mainframe integration option ­ native deployment within CICS (see Figure 1).

With this option enterprise organizations have the ability to leverage several secure, high-performance application programming interfaces to CICS and IMS logic as they build and deploy modern .NET components and Web services. These interfaces include:

Front-End Programming Interface (FEPI): FEPI allows for much broader coverage of older CICS, Natural, CA-IDMS, CA-IDEAL, as well as IMS applications. FEPI provides access, by means of simulated terminals, to CICS or IMS applications available through a communications network, and then enables developers to write CICS application programs that access other CICS or IMS applications. FEPI is the solution of choice for older CICS systems that do not allow DPL access.

When accessing CICS logic on the back end, the COMMAREA option is the best option (approximately 30 percent of CICS programs support DPL access), in that performance increases up to ten times over screen-based solutions. However, if accessing CICS logic through the COMMAREA is not an option, the 3270 Bridge and FEPI provide substantial gains as well, often more than four to six times the performance of screen-scraping solutions.

On the IMS side, OTMA is the preferred option when possible, offering performance gains five to eight times better than screen-based solutions. If not, FEPI is still a viable choice, allowing access to all visual IMS applications as well as mainframe applications that do not utilize BMS (Business Message Standard) maps, such as Natural, CA-IDEAL, and CA-IDMS. While FEPI does simulate screen scraping, all processing is done inside of CICS on the mainframe, allowing this approach to achieve a two to three times performance gain over typical screen-based solutions.

These four direct approaches (see Figure 2) fall into two distinct categories ­ linkable modules (COMMAREA and OTMA) and 3270-oriented (3270 Bridge and FEPI). Linkable modules, the two options that offer the highest performance, are stand-alone programs without a presentation interface. Other programs that implement the presentation interface generally call (link) these modules, which then expect a formatted structure on input and produce a formatted structure on output. The called program does not see a device-dependent data stream.

On the other hand, 3270-oriented applications ­ which offer less in performance ­ are manipulated only by their user interface. These applications expect data entered on a keyboard and, in return, format screens back.

By working within CICS and using any one of these approaches to bridge between legacy applications and .NET, enterprise organizations can enjoy a number of benefits that they would normally not have if leveraging a screen-based solution, including: