14.2 Analysis of Alternatives


The most important consideration in developing an incremental modernization approach is how to support the gradual evolution of the system. We can safely assume that at any given point after the initial incremental deployment, some functionality and data will remain in the legacy system and some will be migrated to the modernized system. However, this can be achieved in many ways. For RSS, code is migrated first and then data is migrated , according to the selected trail map. Having functionality and data exist in both the legacy and modernized systems means that distributed transactions will be executed across the two systems, that is, partly in the HVTIP environment and partly in the EJB environment.

The approach selected for evolving the system will affect the technologies that can be applied during modernization. Again, depending on the modernization approach selected, it may be necessary for modern logic to access legacy logic or data or for legacy logic to access modern logic or data. But we cannot select the technology until we understand the modernization approach, and we cannot select a modernization approach until we have established technical feasibility. To resolve this catch-22 situation, we initially focus on the desirability of the approach and then evaluate the technical feasibility of the most desirable approach, because establishing technical feasibility can be a time-consuming , expensive process.

In addition to simply identifying a modernization approach that supports the incremental development and deployment of the system, it is necessary to ensure that the system can meet the interim quality objectives, as recorded in Section 4.4. These objectives include performance, availability, and security. Some common questions that must be answered follow.

  • Performance: What volume of data is extracted? How frequently is data extracted? How many transactions need to be supported per second? What is the size of these transactions? What response time is required?

  • Availability: What are the requirements for system availability? Does the system need to be constantly available, or can it be taken down for periodic maintenance? How long can these outages last?

  • Security: What levels of security are required? Does the system need to support multiple classes of users, each with a different level of access?

In the following sections, we analyze and contrast several plans. Although they are potentially viable , we have not validated all of them in practice and do not recommend that they be applied without further consideration. These plans fall on a continuum from least to most aggressive . All the alternatives take into account the prior work on Web enablement and the reports database on Oracle (see Section 2.2 for more details). Selecting a final plan requires a risk-benefit analysis.

Plan 1: DMS on OS 2200

Plan 1, illustrated in Figure 14-1, is the least aggressive system preparation step. The legacy system is retained largely intact, with various middleware components used to integrate modern and legacy elements. After code migration, data will be migrated from DMS to Oracle. Adapters can have logic on either platform, both platforms, or even be a middleware solution. Logic adapters transfer control from the OS 2200 environment to the Solaris environment (COBOL to Java), and inverse-logic adapters transfer control from the Solaris environment to the OS 2200 environment (Java to COBOL). EJBs use a data adapter to access the legacy DMS database. The Oracle database used for report generation and data mining is populated daily from data residing in the DMS database. Applications are accessed from a Web browser.

Figure 14-1. DMS on OS 2200

After the construction of several model problems, it was agreed that transactions would always start from the OS 2200 environment and then execute functionality in the Solaris environment before returning to the OS 2200 environment to complete the transaction. Once a use case is completely migrated, transactions execute entirely on the Solaris environment.

Data Access

Plan 1 requires that enterprise beans, running on the Solaris platform, access data stored in the DMS. This can be accomplished in many ways.

The first option is to allow the enterprise beans to access the database directly, bypassing any existing application programs. In this case, an enterprise bean directly formats a database access request, using JDBC. This request is then sent to the OS 2200 Data Access via a JDBC-to-ODBC bridge. OS 2200 Data Access provides the relational view of the nonrelational DMS data structures.

A second option is for the enterprise beans to invoke a data adapter program that runs on the same system as the database. In this case, the database is not accessed directly by the remote requestor : The database adapter provides functionality that can read or update the DMS as necessary. This option has only one point of contact to the database instead of embedded DMS data-access code in all beans.

One way to implement this second option is to use RMI to invoke a Java method running on the Java Virtual Machine (JVM) on OS 2200. The Java method, running locally on OS 2200, can access the DMS, using JDBC. [1] To be successful, the version of RMI running on the Solaris JDK must be compatible with the version of RMI running on the OS 2200 JVM. This can best be determined through a small model problem or prototype.

[1] Performance problems may occur when JDBC is used from within the JVM on the OS 2200 system. Performance may be improved by using a native OS 2200 program to extract the data from the DMS.

A third implementation approach is to send messages to data adapters, using MQSeries invoked with JMS from an enterprise bean. The data-access routines, in this case, would likely be written in COBOL, because MQSeries on Unisys provides bindings for this language.

Control Integration

Legacy program elements are written primarily in COBOL. As a result, MQSeries is a reasonable mechanism for control integration because it is available for both the Solaris and Unisys platforms, and because both Java (JMS) and USC COBOL bindings are available.

Another possibility is to use the JNI to interface between Java shells running in the OS 2200 JVM and COBOL programs on the legacy system. EJBs running on the Solaris platform can simply invoke methods in these Java shells, using the RMI.

Transactions

Because transactions will include logic and database access from the legacy program elements and modern system components, a transaction context must be maintained across both systems. To support transactions across both systems, COBOL programs must be modified to use Open/DTP. This change will allow any X/ Open -compliant transaction monitor to maintain transactions, using, for example, the Java Transaction Service (JTS) interface. This approach might be used in conjunction with Java RMI methods to perform database access on the DMS.

A second approach is to use MQSeries on OS 2200 to support queued transactions, as described in Section 8.4. Given that transactions start on the OS 2200 side and continue in the EJB environment before returning to OS 2200 to complete, MQSeries is the only available option. As of December 2001, the Unisys Transaction Integrator did not support OS 2200 applications invoking enterprise beans, although Transaction Integrator now supports this. If the transactions originate on the EJB side, the Transaction Integrator currently supports connections to the OS 2200 system, using Open/DTP. MQSeries supports this scenario as well.

Evaluation

Plan 1 is the easiest plan to implement. However, its success depends on the level of integration necessary between the legacy and modern systems.

Plan 1 requires migrating the legacy system from HVTIP to Open/DTP. This migration is usually relatively easy but depends to some degree on the HVTIP feature set used. The Open/DTP code is temporary scaffolding that will eventually be replaced .

Plan 1 adds initial complexity because of the need for enterprise beans to use JMS and MQSeries to access data in the DMS. There is also a performance risk in using an asynchronous messaging system to distribute data access across two platforms. Ideally, collocating the two platforms and establishing a high-bandwidth LAN connection between them can minimize performance issues. Interaction between the legacy system and the modernized system is greatest when functionality is equally split between the two systems.

Another, somewhat political, issue is the selection of an EJB server. In the RSS modernization effort, there are organizational pressures to use IBM WebSphere as an EJB server. However, Unisys has qualified the BEA WebLogic to work with Transaction Integrator and Open/DTP [Bye 01]. This pressure to use IBM WebSphere creates uncertainty and risk. If the IBM WebSphere EJB server were used, there is uncertainty as to how well it would integrate with Unisys software. Although in theory this software should work well, our experience has taught us that untested component ensembles seldom integrate seamlessly. Ensuring that IBM WebSphere could be integrated with the Unisys software requires the development of one or more model problems.

There is one other possibility: We could use BEA WebLogic for the modernization effort. This possibility shifts the uncertainty to compatibility between BEA WebLogic and IBM WebSphere, which may be used for other modernization efforts within the organization. Again, ensuring that BEA WebLogic can interact with IBM WebSphere requires the development of one or more model problems. In the case of RSS, it may also require organizational approval to select an EJB server other than the preapproved one.

The greatest disadvantage of Plan 1 is the business expense of maintaining the Unisys system during the entire modernization process.

Plan 2: RDMS on OS 2200

Plan 2, shown in Figure 14-2, involves migrating the data from the DMS to the RDMS for the OS 2200. The data remains on OS 2200 but is converted into relational form. The RDMS schema should be closer, if not similar, to the eventual Oracle schema because differences between the network and relational database models, discussed in Section 7.4, must be resolved.

Figure 14-2. RDMS on OS 2200

Data Access

Enterprise beans running on the Solaris platform can access data in the RDMS either directly or indirectly through data adapters on the legacy platform. Instead of using Unisys Data Access to access the DMS, data in the RDMS can be accessed via JDBC, using the UniAccess ODBC Server. (UniAccess ODBC, an Applied Information Sciences product that provides SQL access to the RDMS, is described in Chapter 7.) Using UniAccess to access the RDMS has an advantage in that there is no need to define a relational-to-network mapping layer; therefore, the UniAccess solution can be more efficient.

Programs on the legacy side need to be modified to access the RDMS. Ideally, a data-access layer can provide the mapping between the old and new schemas and provide a single point of contact to the database instead of rewriting all the data-access code in the legacy programs.

The implementation options for accessing data through data adapters are unchanged from Plan 1.

Control Integration

The options for control integration are unchanged from Plan 1.

Transactions

This approach is similar to Plan 1 in that COBOL programs are modified to use Open/DTP, allowing transactions to be maintained across both systems, using any X/Open-compliant transaction monitor.

Evaluation

Plan 2 is similar to Plan 1 except that the data is migrated from the network database (DMS) to a relational database (RDMS) on the Unisys platform. This requires changing the schema to accommodate the differences between network and relational databases. In turn , this requires changing COBOL program elements on the legacy platform, in addition to the changes required to support Open/DTP.

Changes to the legacy system are always troublesome ; this is one of the reasons it is being replaced. Although the migration from the network to the relational database structure requires modifying the schema, these modifications are minimized for this intermediate step. Enterprise beans on the modernized platform will need to provide a mapping between the modernized data structures and the legacy structure of the RDMS database. This mapping layer and modifications to the legacy code and to the database will all contribute to the overhead of Plan 2.

Plan 3: Oracle on the Solaris Platform

Plan 3 calls for porting the database from the DMS on OS 2200 to Oracle on Sun Solaris. This approach also requires Open/DTP to allow distributed transactions to be maintained across both systems. An architectural view of this approach is illustrated in Figure 14-3.

Figure 14-3. Oracle on the Solaris platform

Data Access

Moving the database from the DMS to Oracle requires modifying the legacy COBOL code to access data in Oracle or creating data adapters. Figure 14-4 illustrates one way in which this can be accomplished. This approach requires that both control and data pass through multiple components.

Figure 14-4. Accessing the Oracle database from an OS 2200 application

Moving the database from the DMS to Oracle also requires restructuring the database schema to support a relational model. Beyond this, any modernization of the schema is optional but not without consequence. Migrating this schema toward the target schema requires adapting the legacy code to work with the modified data structures. Maintaining the legacy database schema requires a mapping between the objects in the modern system and the legacy data structures, possibly in the persistence layer of the enterprise beans. Both cases require developing scaffolding code that will later be discarded, and both have performance implications because data being accessed will now also need to be transformed.

Control Integration

The options for control integration are unchanged from the first two plans.

Transactions

With all the data in Oracle on the Solaris platform, it is no longer necessary to support distributed transactions or two-phase commits. This simplifies transaction management, particularly if BEA Tuxedo can be used as the transaction manager for both the OS 2200 applications and the EJBs.

Evaluation

Plan 3 has many of the same complications and difficulties as Plan 2. Both plans require migrating the data to a relational database. Plan 3 has some potential advantages over Plan 2 in that Plan 3 may simplify transaction management. Our assumption that two-phase commits can be eliminated in this scenario must be verified by using model problems or other techniques. BEA Tuxedo may function as a transaction manager for both the legacy application and EJBs running in the BEA WebLogic EJB server, which is tightly integrated with BEA Tuxedo. The same may not be true of the IBM WebSphere EJB server, which incorporates the Encina transaction manager.

Overall, Plan 3 may require relatively expensive modification of the legacy code to work with Oracle. Further, the overall effort falls short of eliminating the dependency on the legacy hardware.

Plan 4: Everything on the Solaris Platform

Plan 4 is to migrate everything to the Solaris platform but to do so as quickly and inexpensively as possible. This eliminates the dependency on the legacy hardware and gets everything into a Solaris environment, where it will be, theoretically, simpler to integrate with the modernized components.

Retargeting the code from OS 2200 to Solaris requires the following changes.

  • The code must be ported to Solaris.

  • The DMS must be replaced with Oracle.

  • HVTIP must be replaced with an open-systems transaction manager.

  • Dependencies on the DPS must be eliminated.

  • All remaining dependencies on OS 2200 must be eliminated.

To minimize changes because of language differences, the code must be compiled for the Solaris platform, using a COBOL compiler, such as Micro Focus COBOL. This will eliminate the need to transform the code into another language, such as Java or C++. Unfortunately, differences between Micro Focus and Unisys COBOL could make this translation challenging.

Once the legacy system is ported to Solaris, development of the modern components can begin. Although both legacy and modern components can now operate on the same platform, it is still necessary to integrate legacy and modern components. Ideally, integration issues can be solved to allow flexibility in deployment ”for example, having both the legacy and modern systems run on the same server or on different servers.

Data Access

Data is stored entirely in Oracle, greatly simplifying data access.

Control Integration

Control integration can be handled using a variety of mechanisms. Previous options for control integration, such as MQSeries and RMI, are still viable, but other mechanisms may now be possible as well. One such potential solution is to use CORBA and IIOP. The Java ORB is unsuitable for this application because it lacks a Micro Focus COBOL-language binding. However, suitable language bindings may be available from another ORB vendor. Another control integration option is to use JNI to invoke Java methods directly from COBOL and/or COBOL methods directly from Java. Unless combined with a distribution mechanism, using the JNI would require both the legacy and modernized systems to run in the same process space.

Transactions

Maintaining transactions in the context of Plan 4 is the subject of Chapter 10. In Chapter 10, we considered several alternative solutions and established the somewhat qualified feasibility of one approach.

Evaluation

Plan 4 completely eliminates the need for the legacy Unisys system. This saves dollars that would otherwise be spent on legacy system maintenance. Moving both the code and the data to Solaris brings us closer than previous plans to our eventual goal of replacing the legacy system architecture. In addition to sharing many of the complications of earlier plans, porting the legacy system to Solaris requires that all dependencies on OS 2200 be eliminated.

Anecdotal evidence suggests that moving from a Unisys platform to a Solaris system by using an Oracle database improves the performance, although simply assuming that this is the case is ill-advised. All performance and response-time issues rely, however, on how well the entire system is set up and tuned . This means that the operating system, the database, and the applications programs must all be properly optimized during the testing phase to ensure good performance in production.

Plan 5: Everything on Solaris+

Plan 5 is a slightly more aggressive variant of Plan 4. Code and data are still ported from the legacy platform to Solaris. However, instead of using Micro Focus as a target language, we convert to the Java programming language and J2EE environment to further narrow the gap with the target environment. This conversion is a direct mapping, with no architectural transformation.

This approach has several advantages. In narrowing the gap between the modern and legacy systems, we simplify control integration and data access, as well as support for transactions that span legacy and modernized system components. This approach reduces the entire problem to a Java development effort rather than requiring the development staff to be proficient in two significantly different languages and development environments.

Evaluation of Alternatives

Migrating the existing system off the Unisys hardware turned out to be the overriding issue in selecting a plan, because of the high cost associated with maintaining the system on the legacy hardware. In the case of RSS, computing services were being provided by an independent third party. The yearly bill for operating the Unisys platform at full capacity is $15.5 million a year, whereas the cost of operating the Solaris platform at full capacity is $6.9 million. Any modernization plan that incrementally migrates functionality from the legacy system to the modernized platform would require that both systems be operational at the same time. In some cases, this meant yearly operational costs exceeding $23 million. Money spent on maintaining the existing system came out of the overall budget, with the result that high operational costs resulted in fewer funds remaining for modernization.

All the plans considered in this section may be valid under different circumstances. The RSS team selected Plan 4 as the least-aggressive system preparation plan that accomplished the goal of migrating the existing code base off the Unisys hardware platform and onto a Solaris platform before starting componentization.



Modernizing Legacy Systems
Modernizing Legacy Systems: Software Technologies, Engineering Processes, and Business Practices
ISBN: 0321118847
EAN: 2147483647
Year: 2003
Pages: 142

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net