Extending Mainframe Applications for RIA and Mobile

Mainframe applications and Rich Internet Appliations (RIA) may seem like strange bedfellows. But enhancing and extending mainframe applications as Rich Internet Applications may be an important requirement for organizations seeking to modernize business applications in the Web 2.0 age.

As younger workers used to social media and other Web 2.0 dynamics enter the workforce, pressure will increase on mainframe IT organizations to enhance and extend their applications in a manner that makes them look and act like Web 2.0 applications. Not to mention the demand for mobile access to the same core business functions.

While uniPaaS is an ideal RIA development tool for Windows, Linux, UNIX and IBM i operating systems, the uniPaaS server itself does not run on the mainframe. In a post on my JD Edwards integration blog, I discussed Mainframe Integration Patterns that can be used with iBOLT. I represent the same discussion here, but in the context of creating uniPaaS RIA extensions for mainframe applications:

When using the uniPaaS application platform to meet the needs of RIA and Windows Mobile users, it will be necessary to find the right point of access to the mainframe. Challenges to be considered in mainframe integration include fundamental differences between systems such as EBCDIC versus ASCII text character set encoding. Finding metadata information about file structures is also fundamentally different between mainframe and other systems. On the mainframe, most of the programming is performed in COBOL and data is defined and contained in the COBOL copybook. Often, the copybook is the only source of metadata as well. In addition, consideration must be given to whether processing on the mainframe occurs in online processes, batch processes or some combination.

Extending a mainframe application by adding new RIA clients will cause the application architect to consider whether the application requires synchronous real-time, semi-synchronous near real-time or asynchronous batch methods.

Mainframe database adapters. A database adapter connects directly to the mainframe database and polls for changes in the database or responds to database triggers. These adapters can normally read, write, erase and update data in the mainframe database as well as deliver the mainframe data via certain protocols. Database adapters are very powerful and low-level solutions but have the fairly significant disadvantage of requiring the integration architect to have extensive knowledge of the database structures used and the application processes. While reading from a database is less problematic, writing directly to a database is problematic and could even void vendor support obligations for off-the-shelf software.

Mainframe ODBC adapters. Another approach is to use an ODBC driver, such as the one built-in to the SNA server or one of many available from third-party software vendors. The ODBC driver has the advantage of being more widely accessible by third-party software vendors, but in the end has the same fundamental limitations or risks associated with direct database adapters or access.

FTP. File Transfer Protocol (FTP) uses TCP/IP and provides a way to transmit files between diverse systems including mainframes, Linux systems, IBM i, UNIX systems and Windows servers. On IBM mainframes, the z/OS operating system includes capabilities for both get and put commands to transfer files. Serious limitations exist for FTP based integration, however: 1) The amount of parsing required to get to the relevant data is often extensive. 2) Security exposures are not trivial and require painstaking attention. 3) FTP is resource inefficient by requiring a separate data connection for each file transferred. 4) Parsing of the FTP directories is also complex. 5) For high volume integration requirements, managing all of the FTP files can become problematic.

Proprietary APIs. Proprietary APIs may at first seem attractive based on the specificity of their integration to a specific application. This may also be a point of weakness, however, as a great deal can be invested in terms of licensing and labor to make these APIs work and they are essentially single purpose. If you later find that you need to extend a different RIA application, you are back to the drawing boards in you search for the right integration pattern. A better approach would seem to involve a generalized integration solution on both the mainframe side and the non-mainframe side of the integration scenario.

3270 Emulation. Another option for mainframe integration is 3270 emulation. Clearly this is a strong candidate for RIA extension as it provides entry to the user interface itself. Adapters are available that will publish a secure Web service that enables bi-directional communication with mainframe systems and applications via the user interface stream known as 3270. The advantages to this approach are the relatively small amount of integration work required on the mainframe side. An expert user can spend a few hours training the emulator to find the right workflow to reveal the data or conduct the transactions and other I/O needed. However, the integration possibilities will be limited to those provided by the application to the user. If there is a need to go outside of these limitations, then this might not be the best integration pattern. In addition, the risk of inappropriate integration design needs to be carefully considered. Even expert users may be completely unaware of the ramifications of a particular interaction. Nevertheless, this will be a method chosen in many instances. The trick is to avoid the trap of just stuffing the mainframe application into the browser using one of these screen scraping type tools. Security concerns and usability issues are not trivial.

Messaging Queues (MQ). With JMS or WebSphere MQ on the mainframe, a messaging protocol can be observed that includes message brokering capabilities and greatly enhances the integration system. In many respects, messaging is the best gateway to application-to-application integration. But it should not be mistaken as a great solution for RIA extensions. Not all mainframe systems are equipped to handle MQ and certainly yhe investment required off the mainframe would be considerable. Unless you alrady have MQ present in both mainframe and non-mainframe servers, I would skip this approach. Other protocols such as CICS may be preferable not only for their relatively greater presence, but also because of the strong knowledge base in the mainframe IT community regarding their use.

CICS. Customer Information Control System (CICS) is a mainframe transaction server designed for mostly interactive rapid, high-volume online processing and can also perform background processes. With a CICS Adapter, the uniPaaS application platform can be made to appear like another CICS server (including its clients) to a mainframe system. CICS support for multi-region operation (MRO) provides a simple and secure entry-point into the mainframe application environment without the need for extensive programming. Some CICS integration solutions utilize Web Services to interface CICS on the mainframe to the outside world. So with CICS we have another excellent pattern for mainframe RIA extension to utilize the CICS adapter to connect to the uniPaaS application platform, thereby eliminating the need for multiple interface development and simplifying the deployment of the refactored mainframe applications as RIA applications.

To manage RIA development and RIA mobile development of Rich Internet Business Applications, the uniPaaS application platform is an excellent solution. More information on the uniPaaS Application Platform is available from Magic Software Enterprises.