Jun 1 ’09

Optimizing Mainframe Applications for Reuse: Can You Really Gain Flexibility Without Sacrificing Security?

by Editor in z/Journal

Key Terms

• State: conveys the session status of interactions between two computing devices or between a computer application and a user ID, or a service and the service client. State refers to the degree of information retained and available about ongoing communications for the duration of the session.

• Stateless interactions: describe communications in which services don’t retain information, such as stored state variables or their values, between one event and the next. Each user-initiated action is treated as an isolated incoming application request with no extraneous information needed or kept.

• Stateful interactions: describe communications in which services retain certain information (or histories) between one event and the next, usually to track status and context in the application. For example, an application might let an authorized user ID perform multiple actions against it while maintaining a single continuous session with the user ID for the duration of the activities. —RN

The first mainframes were built for use in trusted environments. Security concerns focused more on ensuring proper application access than on locking down the network. That’s because the applications ran on platforms that were totally self-contained; the concept of a distributed environment wasn’t even on the horizon.

But today’s IT staffs are under increasing pressure to open System z and other host applications to various settings outside that original realm. There are many options for doing this. However, you must address significant security implications when you extend your legacy assets beyond their original use. This is especially important when opening a legacy application to a distributed and more open network infrastructure.

Mainframe Modernization Via SOA

In uncertain financial times, cost considerations drive many business decisions. IT decisions are no exception, which is why IT organizations worldwide are tackling mainframe modernization with an increasingly popular method: Service-Oriented Architecture (SOA) enablement. SOA enablement is cost-effective, efficient, mitigates risk, and yields a rapid ROI; it also doesn’t require rebuilding or replacing legacy applications.

IT professionals considering SOA enablement of mainframe assets typically want to address concerns such as:

• How can I make mainframe data more useful without invasive changes to my legacy application inventory?

• How can I leverage and append the proven safeguards already in place?

• When I start distributing access, how can I maintain control, pass audit, and ensure security remains adequate?

• What level of risk is appropriate to get the quality of service I need?

• How will I know if I’ve broken or invalidated the security that’s in place?

• Will I be able to limit levels of visibility once application x is talking to application y?

• Who will be able to gain access and what systems will ensure proper access?

Forms of SOA enablement, specifically front-ending legacy applications with a “wrappered” service tier, can help you address these concerns. This article doesn’t focus on service-wrapping technologies, but provides guidelines on reconciling the use of services against your own IT environment with the right application-integration solution. We’ll examine several ways to safely reuse mainframe application data and logic in an SOA and cover best practices for ensuring proper host application involvement.

SOA vs. the Mainframe Application

The power of the pure SOA approach lies in its flexibility through service composition and reuse. Services in a formal SOA, by nature, don’t know how they’ll be used because their use isn’t yet determined. Developers employ them as needed, in different ways for different purposes. This ambiguity is by design.

To provide oversight to critical resources, an SOA counts on forms of governance to track services and ensure proper usage. The oversight is external to the services and beyond the control of the services themselves. It’s a trust relationship in the sense that the services “trust” some part of the infrastructure is protecting them.

This characteristic fundamentally differs from the traditional legacy security infrastructure, which knows directly who and what is using it from end to end. Mainframe applications, and the systems they reside on, typically track and control use of their data themselves. This dissimilar method for securing mainframe applications can complicate the building of an enterprise SOA.

Five Options for Mainframe Access Using Services

Before creating services that front-end legacy applications, you should assess the importance of tracking and guarding the use of the legacy components exposed as services. If that importance is high, then you must determine the accepted method of tracking and protection.

From the mainframe perspective, all application users are, at some level, users of mainframe sessions. It’s a relationship that lasts for the duration of the legacy application’s use. By having a strong authentication method to grant use of a session, the mainframe and legacy application can track the exact who, what, and when of any legacy interaction. The business operations that depend on these applications typically count on this trust relationship and the guarded methods for use.

Let’s now discuss five general options for allowing services access to the mainframe. With each approach, you’ll see a technical description, accompanying diagram, advantages, disadvantages, and appropriate use.

1. Open/stateless with no locking: The most basic approach is to create stateless services that access and drive a legacy application for the client or user. These services create their own session to the host, and then make themselves externally available for use. The mainframe application talks indirectly to the client application via these stateless services over existing open lines without regard to the location of the client. This approach is a simple extension of the legacy application, with no changes made to the legacy application or the network. It assumes the same safe network environment that most legacy applications were built with (see Figure 1).


Advantage: This method is non-invasive and lets you reuse valuable assets without rewriting or rebuilding host code, which can be risky. It has the lowest level of change to system and application access, so you can enjoy rapid ROI.

Disadvantage: Because the lines are open and unencrypted, a safe network is assumed. Because the legacy interactions are stateless with no tracking, the application-client communications are anonymous.

Appropriate use: This method is suitable for tasks where security is implicit by the nature of the data and the current network layout. While it supports quick use of legacy application assets that don’t need extended session state, its use can’t be taken beyond the existing safe network zone in IT. It’s often used in a protected or “glass house” environment, where all users with network access are known and have their credentials.

For example, a system administrator might use a Web console that accesses legacy applications through a set of stateless services, to facilitate management. With this approach, the data, which pops up on a browser, is totally unavailable to the outside world because the system administrator’s network is protected. Even though the lines aren’t locked down per se, the communications are locked down by virtue of the users involved and the limited scope of the network.

2. Open/stateless with lines locked down: To remove the risky assumption of a safe network, you need to add a layer of security by, at minimum, locking down your lines. You still indirectly access the mainframe through a set of stateless proxy services in the same way as previously mentioned, with the services opening and controlling the sessions to the mainframe. With this method, line security, via Secure Sockets Layer (SSL) or equivalent, is introduced (see Figure 2).


While this change seems simple, it significantly contributes to the usefulness of an SOA. The SOA is distributed; locking down line communications at the application-to-service and service-to-service client removes restrictions on the location of the service client or user.

Advantage: With this approach, you get flexible services that leverage needed parts of your legacy applications. The services are also fast because their session to the mainframe application can be established before they make themselves available for use. That way, the clients of the services can access mainframe assets without waiting for session creation. This approach also lets you extend the use of services to remote locations while ensuring safe data delivery. Your services can enforce legacy authentication as part of their use.

Disadvantage: Stateless application use implies that the mainframe or its applications don’t directly know who their users are. Any authentication happens in the mid-tier infrastructure, or not at all. Although lines are locked down and the service might have authentication that points to Active Directory, for example, there could still be a possible security loophole; when legacy assets are unaware of their use, audit concerns can arise. This method requires a trust relationship with the mid-tier service clients.

Appropriate use: When the application extends beyond the safe network zone, this approach works well, as long as usage of the application services is known and trusted. The assumption is also that the services are visible and available only to those who have the right to use them. Even without explicit protection or tracking of service usage, the services aren’t expected to be able to perform harmful activities; their use is innocuous.

If you have complete control of business data and logic in your enterprise, you can implement stateless access and lock down lines as you see fit. If your usage extends beyond the glass house, and you’re opening mainframe applications to trusted session pools or trusted external sources, this method also might be adequate.

3. Stateless with logging in place: Organizations needing more stringent security measures might consider adding a security log to methods 1 or 2. With this approach, you match service clients to service sessions for application access. This is easily implemented with available service-creation applications. Using logs stored on the mid-tier and controlled by service-wrapping technologies, user identities are recorded and matched to the use of the host application services when they’re invoked. With services using established session pools, multiple users can call to get server-controlled, dedicated sessions in a many-to-one relationship (see Figure 3).

The stateless model with logged service use works best for a true SOA, but still contains risk from a mainframe perspective. When you create wrappered services where use is controlled by the mid-tier, you need a trusted infrastructure in front of the mainframe. SOA governance, combined with service-use logging, helps mitigate the risk. In this scenario, the mainframe itself isn’t required to know who’s gaining access because the mid-tier is recording user credentials and actions.

Advantage: This method provides fast, flexible use of established stateless services and provides an accounting of how the services were used. Logging of stateless access also lets you capture who invoked the services and what the services provided.

Disadvantage: If SOA governance and mid-tier service logging aren’t trusted or reliable for flow and authentication, the mainframe can’t always be sure who’s gaining access.

Appropriate use: This method is most appropriate when the data made available by the services can justify the risk associated with mid-tier tracking of mainframe resource usage. Both government regulations and auditing procedures typically require a log analysis, so this is a good, basic business practice for various uses. However. for many vital functions, such as general ledger or other accounting operations, a proxy log from the mid-tier may not be considered adequate.

A major U.S. newspaper is successfully using this stateless-interaction approach to implement a new SOA-based, self-service classified and business advertising system. Credentialed users can interact with services that interact with the designated mainframe application to initiate and pay for ads. Security is considered good, as the users are known, the lines are locked down with SSL, and all interactions are recorded at the service level.

4. Stateful session-based services: In some IT settings, the mainframe application needs to directly control its user access. When that’s the case, you need to provide a service that identifies users and their level of security. For example, in a customer-service application, first-level customer care access to customer data might be unique to the user’s credentials on the host application; the data presented by the mainframe application is specific to their login ID. For situations such as this, you can set up access services that obtain a host session using the client’s credentials. To invoke those services, users must provide a specific set of data to have the service initiate a unique host session that lasts for the duration of the service invocation. You can set it up to have the service pass the user identity and password—for both RACF and, if needed, the destination application used by the service operation.

Once the mainframe and the application verify those credentials, the service runs as normal using the authenticated session. When the user’s series of service operations is complete, the service terminates the host session and waits for its next use. This approach provides the mainframe and application complete control over access and direct visibility into users throughout the duration of the service (see Figure 4).


Advantage: Stateful access lets you leverage anything in your enterprise with the same security you had before enabling SOA. Because it uses the mainframe’s existing security infrastructure to manage host sessions, you mitigate access risk.

Disadvantage: Although stateful connections can directly leverage the host resources, they consume a proportionally higher mainframe resource use for every service invocation. In a scenario where the mainframe may need to accommodate 1,000 simultaneous client requests, it would need to create and maintain 1,000 host sessions, each lasting the duration of the calling client’s interactions. This is significantly different from stateless models that can handle similar workloads with just a few host sessions. Also, slow initial response times can result from the need to create unique session states—waiting for execution of the built-in security steps and instantiation of the host session for the service to use.

Appropriate use: This approach works best when the mainframe application needs direct control over its resource use or when sequential activities by the service are unique to the client’s identity. For example, an IT enterprise on a college campus is successfully using this method for class registration. When a student needs to use the registration application, a security routine launches, the service asks for the user name and password, and then, using these credentials, creates a unique host session—one with a specific view of the student’s data. The mainframe application requires a one-to-one match between user and action taken during the session. In essence, this approach makes the service client an extension of the host application.

5. High-speed stateful services: For applications that reside entirely in CICS, there’s a hybrid option that’s worth exploring, as CICS accounts for most mainframe applications today. With CICS, it’s possible to create wrappered services that don’t have host sessions behind them. They instead create a direct link to the CICS application—one that retains control over all application logic and flow. This approach relies on products that leverage a route to CICS applications through the IBM Link3270 bridge. With this access method, direct mainframe authentication is possible but not required; you can bypass security or, depending on the level of security needed, create a routine that requires authorization from RACF and the application itself. Although these authentication routines are the same as in approach 4 (with logging, usage, and visibility handled directly by the mainframe), you skip the session creation and associated authentication processes. Instead, you build your services to create a direct mainframe-authenticated link to the CICS application, from scratch, for each service operation. With this direct-access approach, when a client application (such as a Website) calls a service, mainframe security parameters can be passed as part of the service operation. Then the service can create a direct, authenticated link with the destination CICS application, perform the service interactions, disconnect, and terminate the link (see Figure 5).


Advantage: This method eliminates the costs of creating host sessions for stateful purposes that have a short life. You can use it for stateless services—with many of the same performance benefits. It also can remove any middle-tier component, so you can simplify the locking down of communications with SSL. Typically, such a process would result in high overhead and slow configuration, but with this hybrid access approach available to the service, the whole interaction is faster and less mainframe-intensive than a standard host session-based stateless service. 

Disadvantage: There are two concerns with using direct application link as the access method for services. First, the host application must be entirely in CICS. Although it can span CICS regions or even mainframes, all application components the service directly interacts with need to be in CICS. The second concern is the requirement to add a third-party product into one or more of the CICS regions. Because this method uses a CICS host-based component, it can complicate the approval process for implementation. (However, like the services using host session-based communications, it doesn’t require any modification to the host applications themselves.)

Appropriate use: Suppose a bank has a network of Automated Teller Machines (ATMs). This setting calls for a combination of speed and security. When users hit the keys on an ATM, they expect to instantly get back data; long response times are out of the question. High-speed, stateful services provide that speed. For optimum security, the mainframe demands full insight into the user’s identity, with the program requiring an ID plus a PIN.

Finding the Right Solution

To find the correct solution for your IT environment, you need to explore the available access options while keeping security a top consideration. Here’s a recap:

• If you’re a system administrator working in a trusted IT environment, open/ stateless access with no locking will be adequate.

• If you’re extending mainframe access beyond the glass house, you can have a secure deployment by simply locking down your mainframe conversations with SSL.

• If strategic operations are involved, you’re better off tracking service interaction with service logging in place.

• If you need direct mainframe visibility into users and their actions, stateful access with specific host sessions will work for you.

• If your environment is CICS-dominated and you have access to the infrastructure, you can eliminate actual sessions and instead consider fully stateful, sessionless mainframe access.

The most secure approach will emerge when you perform a thorough analysis of your business demands and your particular IT architecture; then, match those requirements with a solution that gives you no more—and no less—functionality than you really need.

Guidelines for Division of Labor

As you sort through these five access options, keep the skills of your technical staff in mind. Almost every IT enterprise has an inherent skillset divide that leads to questions about how and where services are created, the ownership of the resulting services, and, perhaps most important, who is responsible for keeping the services in line with current business needs.

This divide centers on the skills of those who maintain legacy host applications vs. those who work with mid-tier components. Before handing off services built from mainframe assets, be sure to have a plan for division of labor. IT specialists must parse the host application in such a way that mid-tier specialists aren’t given services too granular for their needs. This could have security ramifications; there are few reasons for Web developers to need direct access to general ledger information on the mainframe.

Don’t put change control of critical host business logic in the hands of mid-tier specialists who don’t have the needed context to maintain it. Instead, consider having COBOL specialists retain control of services that require host changes and keep the services up-to-date. Mid-tier control can cover use of the services such as orchestration, security, policy needs, and other SOA-specific concerns.

When mid-tier specialists get business objects generated at the right level, they’ll know how to use them. When ownership stays in the hands of mainframe experts, you don’t have to worry about keeping the services maintained.


When dealing with sensitive mainframe data and logic, a non-invasive methodology is critical to your short-and long-term success. Changing valuable host code or associated business processes could result in catastrophic business losses. Any of the approaches discussed here can be non-invasively performed.

Your present mainframe security is another factor. If you have a security system that’s working for you, that’s the one you should use for authentication in any access scenario. Bypassing your mainframe security is a practice that should never be taken lightly. In addition to working with your current security programs, any application integration method should support federal regulations, including the Federal Information Processing Standard (FIPS), a guideline used to authenticate cryptographic modules.

So, when optimizing mainframe applications for reuse with modern technologies, can you really gain flexibility without sacrificing security? The answer is yes. But let the buyer beware. The business operations controlled by your mainframe have never been more critical.

The best application integration approaches have options for both stateless and stateful access, letting you decide what would work best in your individual IT environment. In fact, modernizing your mainframe applications isn’t as hard as some IT professionals might assume. The key is to do it in a way that protects the integrity of your valuable mainframe assets.