New Online Processing
Last time, we looked at the forklift option: burning the legacy infrastructure to the ground and building it back up again using different technology. In this post, we’ll take a close look at an alternative solution that leverages some of what exists, but creates all new online processing components.
The New Online Processing solution is a database integration / parallel transaction processing framework. Legacy interfaces interact with existing transaction programs running on a legacy transaction server as before. In a parallel but separate environment, web and mobile interfaces interact with completely new transaction processing on a new business logic server.
To the original mainframe configuration in Part 1, we have added two new components. This image shows a completely new business logic server running servlets and/or widgets that service a completely new set of web and mobile interfaces. Here is a summary of what the environment looks like in this scenario:
- Data Storage (Db2, IMS, VSAM, IDMS, QSAM, Oracle, etc.) – This will remain unchanged from before.
- Multiple Programs that are linked together with JCL that define the batch jobs that process the data – This will also remain unchanged.
- Multiple Transaction Programs that are managed and sequenced by the online processing environment, Transaction Server (CICS, IMS-TS, etc.) – This will also remain unchanged.
- New Servlets / Widgets that are managed and sequenced by the new business logic server and deliver new web / mobile GUI interfaces.
This solution creates purpose-built applications that will drive new interfaces for web and mobile, but will leverage existing data stores and other existing legacy assets. This approach will also leverage the existing investment (in code) and provide the rich experience needed for mobile and web users.
Benefits of New Online Processing
- Readily available interfaces for data storage to enable generating new functions that would be accessed by web and mobile scenarios.
- The new business logic server can be put on a different platform, allowing a choice of platform that best suits the workload.
- Many web / business logic servers are available for consideration, although they are often part of a web server such as WebSphere, WebLogic, Apache, JBoss, etc.
- The existing mainframe application should be able to function relatively independently without significant impact.
- It can grow over time, delivering only the functionality that is needed immediately for web and mobile with more functionality added as required, even eventually replacing the existing legacy transaction server.
Drawbacks of New Online Processing
- The requirement to recreate functions that are already running in the legacy transaction server will duplicate function, essentially reinventing the wheel.
- An ongoing dual code path complicates support and future enhancements, and may require parallel development teams, testing teams, support, maintenance teams, etc.
- Significantly more difficult than some other solutions.
- Need to understand the existing functions of the legacy transaction server (where similar functions need to be on the new business logic server) with few tools and nothing comprehensive enough for a solution.
- Needs further consideration of the necessity to manage security, reliability, availability—now spread onto two systems.
Development Details
The new business logic server needs to create a new set of functions that would run in parallel with what the existing transaction server, transaction programs and screens provide. However, it does interface directly into the existing data storage. The good news: readily available interfaces (or tools) exist for data storage, providing the new online processing environment with a ready interface through which to operate, both on and off the mainframe.