IBM Destination Z - Group home

A New Way to Modernize Applications

By Destination Z posted Mon December 23, 2019 03:43 PM


Over the last three months, I’ve created three related articles on application modernization. The first was about modernization as an ongoing activity and it included a method to manage the process. The second was centered on traditional approaches to application modernization. This article, on a new way to modernize, is about some emerging nontraditional approaches.


What Is a New Way to Modernization?

Java with representational state transfer (REST) and simple object access protocol (SOAP) are building blocks for a non-disruptive way of harvesting data and application functionality without actually changing the application. The ideas and practices about nontraditional approaches are dominated with discussions of REST and SOAP.

Both protocols were developed decades ago with SOAP emerging in 1998 (deployed as XML-RPC) and REST in 2000 (Roy Fielding Ph.D dissertation). The use of REST and SOAP involves programs that “sit on top of” or “outside of” the application. Java often plays a role in this as the module that invokes the REST and SOAP API calls. However, other languages besides Java are also used.

This interface-based approach is part of a process of opening up, in new ways, the engagement possibilities of operational applications. Before we explore REST and SOAP, consider the interfaces that IBM has developed over the years to open up CICS transactions and programs to broader, multisystem use.  

Interfaces to CICS Transactions and Programs

CICS has an intense variety of interfaces that have been developed over the decades. This variety gives programmers a tremendous diversity of ways to work with CICS transactions and programs. In the overview of CICS external interfaces, more than 10 different powerful interfaces are discussed. Here is a quick view:

1. WebSphere MQ users can use the CICS 3270 bridge to access CICS transactions.

2. MVS applications running in MVS address spaces can use the External CICS Interface (EXCI) to access CICS programs.

3. ONC RPC clients can use CICS ONC RPC support to access CICS programs.

4. DCE RPC clients use the Application Support server to access CICS programs.

5. User socket applications can use the CICS Sockets feature of CICS Transaction Server.

6. Web browsers can use a variety of methods, including the CICS Web support as a CICS-provided facility for supporting Web browsers.

7. JVM applications can use a local gateway connection that uses the EXCI to pass requests to CICS.

8. Java-enabled web browsers can use applets that communicate with CICS.

9. CICS client applications use a distributed CICS client (either CICS Transaction Gateway or the CICS Universal Client) and the ECI or the EPI.

10. Programs running in CICS servers on any platform can use EXEC CICS LINK to call a CICS program, or they can use transaction routing to send transaction requests to CICS Transaction Server. Programs running in CICS Transaction Server can use the CICS front end-programming interface (FEPI) to start transactions in the same or another instance of CICS Transaction Server. 

11. Telnet clients can use TN3270 to start transactions.

If you’re seeking to modernize a CICS application, this list of interfaces is a good place to start. Certainly, these interfaces aren’t the only factors to consider but it would be foolish to overlook these areas of opportunity.

The “Outside in” Approach

The “outside in” approach to modernizing an application can start with a program that uses APIs like REST or SOAP to invoke existing business functionality. It might be as simple as gathering data and presenting it in a new way on an intelligent device. No COBOL updates, just a new presentation layer. This approach is gaining traction, but it’s not for use in every situation.  

Why REST and SOAP?

RESTful web services are more descriptive than just REST because it puts this way of proving interoperability clearly in the context of the web as a service—a way to get what you want using resources on the web. RESTful web services support interoperability between devices running software like browsers and web pages on the internet. REST is an architectural style, a flexible way of doing things on the web, not a strict standard. REST is mindful of important characteristics including performance, scalability, simplicity, changeability and reliability.

SOAP is more likely to be preferred by financial and business applications, but it’s not that black and white. A financial company might prefer SOAP because it has a capability, through WS-Atomic Transactions, to support two-phase commit transactions. Two-phase commit is the accepted way to handle many types of financial updates because this feature enables databases to be returned to the pre-transaction state if some error condition occurs during update processing.

Figure 1, below, contains some key points of comparison between REST and SOAP.



Ease of use

Smaller learning curve

Can be more complex


Required HTTP

Language, platform and transport independent

Additional tools

Generally, none needed

Others useful to mask XML complexity

Speed of execution


Longer path length requires more processing power

Error handling

Programmer needs to handle, (e.g. HTTP Status Codes)

Built in


Uses small message formats

XML used for all messages


More like other web technologies

Unique design


Flexible set of conventions


Figure 1: A comparison of REST and SOAP

Web Native Versus Web Unaware

Applications built for the web already have the opportunity to be used with REST and SOAP immediately. When an application is web unaware, often you can install middleware like IBM CICS Gateway to provide support for desired interfaces like REST.  Other products, like z/OS Connect Enterprise Edition (EE), provide more comprehensive means.  This article on creating an API from a CICS application is a good example of the comprehensive solution approach provided with z/OS Connect.

Why Should I Use the New Way?

This new way of modernizing applications is not a replacement for traditional methods but rather an additional approach that should be used when appropriate. If the existing application has strong functionality and a new interface is needed then this new approach could be explored. This is not the only use, but it’s an easy-to-understand example. The new way would make use of Java and the web interfaces that have matured significantly over the decades.

This approach, for this use, is lower risk and likely faster to implement. Alternatively, you might set up an environment for microservices with discovery, monitoring and management support and see how well it works with your in-house skill set and drive to innovate.  Alternatively, you could select a packaged solution like z/OS Connect EE as it provides a unified, extensible approach for discovery and invocation of RESTful APIs and services for z/OS-based business applications, opening up these assets to new and inventive uses.

You can try the most basic approach of writing programs and establish an environment in which your programming thrives, or you can employ a commercial product to do much of the work for you. There’s a rich set of alternative approaches and tools you can use to explore this new approach to application modernization.