Legacy programs can be roughly categorized as online update, online inquiry, batch or report programs. In general, these programs do not maintain separation among UI logic, business logic, utility logic and I/O logic. Moreover, the functional modules of the online system are often tightly integrated and therefore highly coupled. This situation presents problems for enhancement and maintenance, to say nothing of reuse or re-engineering.
Initial Re-engineering
The most successful strategies for re-engineering legacy applications are evolutionary, not revolutionary. The best plan is usually to approach re-engineering through a number of projects that are limited in scope and duration. In each, the architect will select a functional subsets of the application and the team will re-engineer the programs in this subset to accomplish a specific objective. After testing and deploying the subset, the team moves on to the next objective.
This strategy requires that re-engineered sections of the application co-reside with unaltered sections. In particular, the display terminal user interface will be used until practically all of its functions are available in any replacement. The implementation tactics chosen for initial re-engineering projects must accommodate this requirement.
Online update programs have a greater proportion of business logic in addition to their required user interface and I/O logic. The higher degree of risk involved in changes to these programs means that, in general, the team should prefer to re-engineer them by moving the UI logic into a separate program, but making only minimal changes necessary to internally structure the business, utility and I/O logic. The UI program should invoke the main program through a well-defined service interface defined as a COBOL structure. Web services should access the main program through this same interface via native facilities (such as the AS/400 Java Toolbox API on the iSeries). As the architect identifies routines that are common across a number of programs, the team should separate these into service-enabled utility programs.
Generally, online inquiry programs will have a much smaller proportion of business logic, if any at all. The higher proportion of I/O logic and lower degree of risk involved in such programs gives the architect the option to use techniques such as Embedded SQL to replace the legacy I/O modules -- especially when it would be more straightforward to re-write the program. In such cases, the architect should design SQL views to abstract the programs from the actual database schema.
Once the team moves the UI logic into a separate program for a given online inquiry function, they may well find that only minimal utility logic remains. In such cases, the team should still provide a well-defined service interface in a main program to encourage proper separation of concerns. However, the architect might choose to access the database views directly from Java web services using a JDBC connection to the mainframe database, rather than going through the service interface.
Batch and report programs can be re-engineered along similar lines as for online inqury programs.
Embedded SQL Pros and Cons
The use of Embedded SQL in re-engineered programs should be carefully considered, as it brings both benefits and risks.
Pros
- Directional industry standard
- Allows set operations vs. row operations
- Improved performance
- Reduced number of separate source components
- Allows tight coupling of data to source
- Allows tight coupling of data to source
- Diffuse responsibility for performance
No comments:
Post a Comment