Getting CICS on the Web -- ADTmag

Getting CICS on the Web

By Sally J Cusack
June 26, 2001

In the last two years, companies across the globe have implemented Internet technology faster than you can say "CGI scripts." In fact, information technology firms rank exploiting Internet/intranet technology as their top initiative or mandate. Companies such as mail-order houses and retail catalog stores are now regularly using the Internet to achieve a return on investment (ROI).

However, users of "hard-core" transactions -- banks, mortgage lenders, insurance firms and stock brokers, for example -- are only beginning to see real dollars and cents attached to their company's investment in the Web.

These organizations, almost without exception, have many of their mission-critical corporate systems anchored on IBM MVS mainframes running CICS or IMS. But before these companies can truly exploit the power and capabilities of next-generation front-end systems and universal connectivity, some critical behind-the-scenes work must take place.

A recent survey of more than 350 I/S professionals across leading industries reveals the hurdles I/S departments must overcome in order to meet objectives. The study, conducted by SPG Analyst Services, Natick, Mass., found the top five obstacles to be:

Developer inexperience with new development tools/paradigms;
Difficulty integrating new technology with
existing systems;
Need to retrain I/S staff;
Excessive rate of change in technology standards and/or products; and
Complexity of the development process.

These types of issues have led many enterprise organizations to leverage the value of mission-critical systems by front-ending them with newer technologies capable of Internet access. One such early Internet transaction processing success story is Charles Schwab & Co. Headquartered in San Francisco, Schwab was the first discount stock brokerage firm to offer customers the ability to trade via the 'Net. The firm provides a wide range of financial products and services -- from the purchase of mutual funds and equities trading to asset allocation and investment information -- to more than 1.4 million active Web accounts, and services 6 million Internet transactions per day.

Schwab currently has five mainframes in operation: three are located at its data center in Phoenix, and two are in the San Francisco office. Transaction throughput is mind-boggling, with an average of 1 million transactions per hour processed under CICS for MVS/ESA 4.1 software. This makes Schwab one of the largest CICS-based shops in the United States.

According to Adam Richards, director of technology integration at Schwab, the trading giant's early entry into Web-based transactions can be credited to Charles Schwab himself. "He said, 'I want to be on the Web, and I want to be there in a couple of months,'" said Richards. "We were fortunate. We had the CICS infrastructure, which enabled us to go from Web to desktop to mainframe. This technology base allowed us to say this is just another channel."

Of course, Richards added, there is a difference. Internal and external customers require different displays, and online customer needs are different from those of the inside representatives. Writing the content and designing the front-end material is important, he said, but to get real transaction processing onto the Web, most of the development time is devoted to the back end. To help ease this task and to avoid rewriting proven, bet-your-business systems, Schwab decided several years ago to port selected transaction systems from the mainframe to the IBM RS/6000 server platform running CICS for AIX.

The company restructured its existing Cobol programs by running Cobol on AIX; this also allowed Schwab to retain actual CICS transactions. DB2/AIX was used for the database, while External Call Interface (ECI) acts as a gateway so that non-CICS servers can gain access to this platform. This setup has also allowed Schwab to extend its existing CICS infrastructure and CICS-driven business functionality to the distributed environment. According to Richards, being able to restructure Cobol code as exposed APIs has simplified programmer access and contributed to productivity improvements. In the future, Schwab plans to encapsulate Cobol programs within Java wrappers.

Using this approach, Schwab's I/S staff was able to port the firm's Sentry gateway to the RS/6000 platform. This allowed the staff to implement the initial Internet trading application in approximately 90 days. Five months later, Schwab was processing more than 60,000 transactions per day in the Web-trading environment.

From the customer's point of view, Web-trading business transactions are merely transactions that also include simple queries, such as "How much am I worth right now?" In the stricter transactional definition, that of two-phase commit, Schwab does a fair amount of read-only two-phase commit transactions, said Richards.

"In Web trading, we don't run a transaction every time you check the Dow. You sign on, [and] we manage a conversation of transactions thereafter," he said. For example, Schwab will superimpose a conversational motif on top of the inherently non-conversational Web environment. In effect, this overlays a conversation on top of the Web browser. While the CICS box is essentially responsible for managing a conversational session between the Web customer and Schwab, some engineering is required to make that happen.

When a Web customer signs on, said Richards, Schwab needs that to be a stateful operation. "We want to know when they signed on, and for how long. In addition, we also have to implement security mechanisms, such as authentication and verification." Users sign on to the Web site using tokens, which are then checked. Once a token has been verified as valid, the level of service the customer is entitled to is then determined.

Schwab does not view the migration to CICS for AIX as an on-again, off-again project, but as an evolving strategy to provide additional functionality to all of its customers. "We are continuing to add to the infrastructure," said Richards. Everything is constantly changing, he said, from content providing at the front end to increased capacity for handling greater transaction loads on the back end. Because of this, it is an on-going process to maintain and manage the infrastructure.

Reface, refine, reuse

Realizing that "one size" or solution does not necessarily fit all, IBM has worked to provide its CICS enterprise customers with other ways to integrate legacy systems with newer applications via rapid application development (RAD) techniques. This allows users to deploy Web browser front ends capable of leveraging Java. Using a concept IBM has dubbed "application mining," customers will be able to reuse in-house skills and systems, while leveraging newer technologies in order to meet business objectives.

Application mining is the result of a partnership between IBM and leading tools vendors, including Planetworks, a software development firm based in New York City. Planetworks' Interspace Release 5.0 product, for example, provides an application architecture and development framework that simplifies the process of building Web-enabled applications on top of transaction processing or messaging-based middleware environments. Users can construct applications using Java, PowerBuilder, C, C++ or emerging Web development tools, such as those offered by NetDynamics Inc., Menlo Park, Calif.

Applications built in this manner provide true three-tier capabilities by spanning from the desktop to the server and onto the mainframe. Furthermore, Planetworks' Interspace shields developers from the middleware layer, allowing them to write middleware-integrated applications without having to deal with middleware code. The product provides a variety of features, including 3270-based CICS transaction support. Using the Interspace 3270 Extended Programming Interface (EPI) feature, customers can use basic desktop developer skills to reface and refine any CICS application. This requires no actual change to the application itself. Additionally, Interspace allows for the import of BMS maps and Cobol copybooks into the Service Catalog. Version 5.0 also provides full support for all messaging options of IBM's MQSeries, allowing for more complete testing of MQSeries applications.

Targeted primarily at mainframe CICS customers looking to migrate 3270 "green screen" interfaces, application mining is designed to provide a best-of-both-worlds option. The core business and data logic can remain untouched, while customers decide the most optimal path to move it out to the desktop. For some customers, this may involve the interim development of graphical user interface (GUI)-style PowerBuilder or Visual Basic front ends, but all of these roads ultimately lead to full-fledged Web enablement.

Mining for sales

An early adopter that has had success with this approach is UniSure Inc., Cincinnati. Part of E.W. Blanch Holdings, UniSure develops, markets and supports the Universal Reinsurance System (URS), software that manages reinsurance transactions for major insurance institutions across the country. In order to win more sales among PC-based customers, UniSure needed to find a way to put GUI front ends on its existing mainframe CICS 3270 application, without having to rewrite the application itself. After looking at several products, the firm chose IBM's Application Mining Starter Kit, which includes Planetworks' Interspace for Sun Solaris and Java, as well as Sunlink SNA connectivity.

David Sauer, senior systems analyst at UniSure, focuses on Cobol/CICS application development. He was brought into the company a little over a year ago to help facilitate the organization's move to a three-tier environment. While UniSure knew it needed an easy-to-use GUI front end, it wanted to achieve this while maintaining its extensive and stable business logic on the back end. The solution was to develop GUI front-end data that could be passed through middleware to the back-end system. Sauer was tasked with taking code on the existing system and transforming it to take data calls on an ECI path. This triggers CICS programs to do data processing and updating, and to then send the data and updates back along the same path.

Referring to this process as a mirror transaction, Sauer describes the ECI call as similar to a CICS program linked to other CICS programs. The Java portion builds and packages the data in a class and then calls through the middleware. The middleware, in this case, consists of the CICS Gateway for Java, Web software, the CICS client and Planetworks' Interspace software. Through these programs, data is "massaged" into a package and then put into a format that the back-end Cobol program can understand. The CICS client allows the program to initiate an ECI call into CICS, while an SNA server is used to communicate with the mainframe.

The insurance industry still maintains a large contingent of OS/2 users, said Sauer, and the CICS/OS/2 combination allows for the use of TCP/IP. The middleware portion runs on a Microsoft NT or Windows 95 platform, while the front end will ultimately run on any Web browser with JVM 1.1. The back-end platforms will remain as is, running MVS or IBM CICS OS/2.

A particularly useful portion of the Interspace middleware is the Painter feature, said Sauer. It allows the developer to build request/reply interfaces that pass through a commarea (a CICS term denoting a common data area) and then from program to program without having to go to an external data field. According to Sauer, users first define their data elements and attributes. In Java, for example, a data field can be any size on a string. When Java passes in this string of data, Cobol might expect 20 bytes, yet Java may only pass 5 bytes. The Painter will then "pad out" everything expected by the Cobol program.

"We're still in the development phase," said Sauer, "and the speed of the software is not where we want it to be." He added that his comfort level is increasing with the recent improvements to Java, and technology like the JIT compiler will help. "The relative infancy of the [Java] language and the war between the vendors has hindered us," Sauer said.

In an effort to speed the development process, UniSure has gone to third parties for class libraries. "Java allows us to give our clients flexibility," said Sauer. "Being able to offer Java and the JVM to our customers ... they don't have to change their entire network and operating system. They simply put the middleware on NT and run a Java 1.1-compatible browser."

UniSure's application mining proof-of-concept took approximately three weeks to complete. Two weeks were spent looking at the program and decoupling the 3270 interface software from the program itself, and an additional week was spent working with Planetworks consultants who provided expertise in interacting with the middleware portion.

As far as UniSure is concerned, the ability to utilize a Java front end is critical to its long-term success. As a software development company, UniSure, like many of its counterparts, has no way of controlling customer configuration. Some customers might elect to use Microsoft Windows, and as previously mentioned, many are currently on IBM's OS/2. UniSure even has one client in an Apple Macintosh environment. Because UniSure did not have to rewrite core applications, the company saved untold amounts of time and money. The application mining approach also allows developers at the host and front ends of the application to work in their own environments, interface with each other when necessary, and does not
require them to be familiar with each environment.

"Customer ease of use is critical for us," said Sauer, a sentiment echoed by Schwab's Richards. Gone are the days when companies could afford to spend years writing and rewriting application systems. For long-term success, organizations need to put their efforts into creating and maintaining strong but flexible infrastructures that meet today's needs and provide extensibility for tomorrow's demands. The ability to "value extract" business logic from core systems, without rewriting code, and to reformat this logic to newer platforms, could be a critical factor in many time-to-market decisions.

Management and scalability

At Schwab, the volume of Web trading is moving forward in leaps and bounds, said Richards. While this is good for business, he points out another effect: As the number of Web transactions grows, so does the number of nodes in the Unix mid-tier layer, and correspondingly, his management issues. He offers a rule of thumb for Web-enabled transaction processing management: "The difficulty of managing a set of objects is related, in some way, to the square of the number of those objects. Objects, in this definition, could be logical tiers or processing units."

But whether you manage dumb terminals, PCs or the Web, the same fundamental problems -- the growing demand for processing power, and the need to cope with scalability issues, replication, myriad transient links and unit failures -- occur. Companies therefore need sophisticated
algorithms that route around failures and implement load balancing. Fortunately, mainframe developers have some of this experience, Richards said.

Environments such as IBM CICS have been built from the ground up to deal with load balancing, session management, persistence, scalability and other issues that are now becoming more apparent to the I/S world at large. Customers familiar with CICS functionality and reliability are not eager to trade this off to move to "new world" distributed applications. Fortunately, they may not have to.

At the most basic level, there is a need to optimize client access and "modernize" the existing back-end CICS application. As far as client access is concerned, simple refacing of the CICS applications involves the CICS External Presentation Interface (EPI), which is designed to effectively utilize the original 3270 datastreams. How-ever, a method such as CICS ECI or MQSeries, which uses program-to-program style calls, can be far more efficient.

Enabling CICS applications to be ECI-callable can be done in two ways. The first approach is when the presentation logic is decoupled from the business and data logic, and interface code is then developed to support ECI calls. The second way is to "wrapper" the entire CICS program with another program that supports interfacing to 3270 datastreams. The choice in the second scenario is between using the CICS Front End Programming Interface (FEPI), or for customers with CTS 1.2 systems, the CICS Bridge Program for 3270 applications. While individual circumstances dictate which choice the customer employs, the most advantageous method for the majority is to decouple the presentation logic on the back-end CICS application and then move to thin-client technologies at the front end.

In addition to the technology offerings mentioned in this article, IBM is working to provide a specific gateway product with functionality based on current CICS client and Java gateway technologies. Currently referred to as the CICS Transaction Gateway (CTG), this product is positioned as an e-Business Connector within IBM's Network Computing Framework. The initial launch is scheduled for late 1998.

CTG's function will be based on advanced Java and HTML functionality, with an emphasis on performance, security and manageability. At press time, word is the gateway product will include support for browser, network station and equivalent clients; support for standard front-end protocols, such as HTTP, SSL and IIOP; and enhanced interfaces and consistent object APIs. However, this is only a partial list of product features to date; the gateway will provide many ease-of-use features, such as wizards, smartguides and installation aids, that have hitherto not been found in the CICS environment.

Enhancements to the CICS Transaction Server (CTS) will include support for the execution of Corba-compliant Java applications in release 1.3. IBM has also made
a serious commitment to supporting the Enterprise JavaBeans (EJB) spec.

In order for the CICS framework to support Java Application Components, CTS will be modified to support EJBs. These modifications, built upon the basic Java and Corba support found in CTS 1.3, will initially enable support for the EJB concept of "session beans." Session beans are beans that behave in a manner similar to today's existing CICS transactions (for example, clients access servers, do some work and then disappear). If clients in this scenario have a transactional context, then executable behavior is similar to a CICS conversational application. Conversely, when no transactional context exists, behavior follows a pattern similar to a pseudo-conversational transaction.

The bottom line is this: IBM mainframe users may not have to give up the comfort, reliability and security of their CICS applications to move into "New Age" distributed object computing. In the short term, this could mean immediate savings in retraining and redevelopment costs. Over the long term, it could save firms millions of dollars in dealing with distributed computing's infrastructure maintenance and scalability issues. These savings cannot be ignored as Fortune 2000 firms search for new and better ways to beat the competition via a technological advantage.