Jun 1 ’05

Speaking Web Services: .NET and the Mainframe

by Editor in z/Journal

In the ’90s, gloom and doom predictions repeatedly said the mainframe was dying. These predictions were clearly way off; mainframes are far from dead, as they still host most business transactions and enterprise data.

Microsoft has wanted to get into the game for some time and has developed numerous products that ease and enhance application development. But can Microsoft, with its .NET development and server environments, provide a true value-added function to today’s complex enterprise z/systems? This article examines the mainframe’s recent “comeback.” While other viable development environments for creating mainframe-based Web Services exist, our focus is on the Microsoft-centric environment. We’ll highlight available products from several vendors and explore Microsoft’s Host Integration Server 2004 (HIS 2004) to deploy a Service-Oriented Architecture (SOA), which uses both mainframe and .NET technologies.

Setting Your Objectives

Many consider SOAs to be the source of a major change in computing. The World Wide Web Consortium (W3C) defines SOA as “a set of components that can be invoked, and whose interface descriptions can be published and discovered.” Dr. Annie Shum, corporate architect at BMC Software, has been an SOA evangelist since SOAs first emerged. Annie, like many others, goes beyond the W3C definition to tie in design and business concepts. She defines an SOA as “a set of prescriptive design principles for building composite software applications based on autonomous services with standardized interfaces to leverage reusability and interoperability—independent of protocol, platform, language, and internal data or algorithms. In a nutshell, SOA facilitates the design, deployment, management, and governance of software that mirrors business processes.”

SOA-based Web Services provide a new mindset for mainframe users and new uses for the mainframe. But Web Services alone aren’t an SOA: The former is a technology, while the latter is a set of nimble design principles and architecture blueprints. If you blindly apply SOAP and XML toolkits, you may not achieve an SOA. Worse, you can incur substantial overhead (with things such as SOAP wrappers) without gaining ground in interoperability and reuse.

So, before we take the plunge into the Microsoft .NET tank, consider that Java is a major mainframe SOA enabler - even more so than .NET. WebSphere is a prime example and IBM is making sure of that. CICS is all Java-enabled for the Web Services piece. IBM’s zSeries Application Assist Processor (zAAP) provides a specialized z/OS Java execution environment; it’s designed to attract more Java development on the mainframe for SOA. So don’t put all your eggs into the Microsoft basket, so to speak, before taking a look around!


With double-digit growth for the past two years, and five consecutive quarters of growth, IBM is enjoying a virtual monopoly on big iron. Although it appears sales may be stabilizing, this is still impressive growth in a market once thought to be declining. Why does this technology thrive even when MIPS, memory, and storage cost substantially more than those of Unix or Windows servers? Years of capital investment, incredible reliability, and astronomical switching costs are the usual reasons. But the most compelling reason is the enormous business value of mainframe applications, most written in COBOL or PL/I.

We went through the last decade with many industry watchers advising everyone to get off the mainframe. But organizations have discovered that moving host applications to Windows, Unix, or other platforms just isn’t cost-effective. Some companies saved money on hardware and software, but they spent it on administrators, and there simply weren’t huge savings to be had. The mentality now is simply to get the most from your existing assets. So, rather than retiring big iron, enterprises seem more intent than ever on disseminating the core business value. By developing SOAs that treat applications as reusable services, mainframes promise to play a central role. But the key is in selecting the right integration tools for exposing mainframe-derived services.

The Mainframe Exposed

One of the quickest, easiest ways to expose mainframe data and applications is by using software that emulates a 3270-mainframe terminal and rolls mainframe data into robust HTML presentations or XML documents. One of the simplest variants is software that pulls data from the 3270 green screens and pops it into the browser, or transmits XML via HTTP. This approach is non-intrusive in that mainframers don’t need to be involved in development, and all the business rules the applications and data depend on are already embedded in the time-proven, reliable application. This approach can also deliver the quickest, most cost-effective payback as compared with new development.

Being able to publish the application as a Web Service lets one developer build the front-end of an application using Microsoft’s .NET, and another build a Java application to consume the same Web Service. A simple mainframe function becomes part of an emerging SOA, enabling the application to roll out across the enterprise.


Let’s examine several products that provide a simple approach to ramping up your existing applications for Internet data availability. Some argue it’s time to think about exposing your host applications and data using a completely different approach—one that affords more integration, albeit with greater development efforts and costs. Happily, a wave of host integration vendors, including IBM and Microsoft, are eager to oblige you. While this philosophy sounds great, the real truth is that, depending on your requirements, these terminal emulation products may well be a simple, effective solution. Sometimes, simple is best.

If the goal is to expose legacy data and applications, many vendors have introduced genuine host integration platforms—complete with support for both the J2EE and .NET environments—designed to complement their existing terminal emulation and Web-to-host products. For example:

Most users are looking for only one development environment, so if you’re a Microsoft shop, you’ll likely want to use Visual Studio .NET. Since .NET is a mobile-friendly application architecture, it’s actually a better choice for organizations that want to expose host applications and data to Personal Digital Assistants (PDAs), SmartPhones, and other wireless clients. Microsoft really hits a home run here because the .NET framework goes right down to those devices, through the Compact .NET framework that’s packaged with Visual Studio .NET. It’s easy to develop clients for those devices; the code and Graphical User Interfaces (GUIs) developed require minimal, if any, changes to work on mobile devices.


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 a 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. These methods let Web Services .NET and Java 2 Enterprise Edition (J2EE) developers reuse the legacy code and underlying data.

Often, applications weren’t written to use these facilities. But even here, designers can directly use the data stored on the host system, whether it’s stored in a database, such as DB2, or in flat file systems such as VSAM.

Consider security issues in this type of environment. Web Services application developers must consider the context in which their code is called. For example, will the system have to pass an individual’s security credentials through, or can the host system accept group credentials? How do you securely transfer credentials? How does the new .NET application connect to the host to begin with?

As today’s applications rely on Web Services technology to conduct transactions such as back-office financial trades, significant security considerations and challenges emerge. Web Services help organizations work together by automating business processes at incredible speeds. It’s up to IT executives and managers to recognize new information security threats posed by Web Services-enabled activity and put appropriate measures in place to maintain order and control.

J2EE, .NET, Web-based, and legacy applications assume that authentication has filtered out the bad guys. However, these applications aren’t ready to detect new breeds of malicious application activity. Web Services layered on top of legacy applications will immediately expose underlying application logic vulnerabilities, probably raising the security exposure to a new level. Data-level validation steps in client/server architectures exist primarily in the user interface logic. This type of security is no longer relevant in Web Services-oriented architectures and must be updated. Packet-filters at the network level were never designed to recognize and diagnose the behavior of Web Services consumers.

The need to guard Web Services-oriented systems from malicious activity is real. Information assurance measures for both threat protection and trust management must be considered. Threat protection focuses on protecting information content from vulnerability to attacks. Trust management deals with whether someone can be trusted to perform a particular action on a specific object.

Development Environment Products

Security is a big issue for SOAs and Web Services. Assuming security can be managed, what development products can help create GUI interfaces and Web Services from existing mainframe applications?

What About Microsoft?

HIS 2004 is Microsoft’s mainframe integration server software that enables applications, data, and systems hosted in midrange and mainframe environments to be integrated into Windows networks and applications. The latest version of HIS 2004 is intended to assist in the integration of Windows-based applications with IBM mainframe systems such as CICS and IMS, and midrange OS/400-based systems. HIS 2004 allows access to VSAM files, DB2 databases, and stored procedures. It also features a gateway from Microsoft Message Queuing (MSMQ) to WebSphere MQ.

Here are some HIS 2004 functions and features:

The Bottom Line

With the new TI, HIS 2004 becomes of potential interest for host users— including those committed to the J2EE platform—looking at Web Services to support SOA projects. For these users, HIS can be viewed as a “black box” that exposes Web Services interfaces and J2EE developers potentially won’t have to become proficient with .NET.

HIS has some limitations such as it doesn’t support integration with non-IBM proprietary platforms such as Unix. Its value proposition is being lost in the marketing noise generated by its competitors. Several Independent Software Vendors (ISVs)—including NEON Software, Farabi Technology, NetManage, and WRQ—provide addons to HIS 2004.

Some contend that .NET is too closely tied to Windows. Certainly, for those organizations using Unix or Linux to front-end their mainframes, .NET has a way to go before it becomes an integral part of large enterprise-integration projects. Gartner’s Mark Driver put it this way: “While .NET will remain closely tied to Windows in the near term, it may take on a more platform-independent form within the coming decade. It’s inevitable that .NET will move beyond Windows. If Microsoft doesn’t do it, someone else will, through reverse-engineering or cloning the platform.”


The mainframe remains vibrant. What’s changing are the development environments and the variety of robust integration strategies. Today, these are centralizing around Web Services technologies. Gradually, developers and vendors alike will be forced to adopt a more fluid SOA approach. What won’t change is the pivotal role of the mainframe.