Myth & Reality

The Common Object Request Broker Architecture (CORBA) has a common interface definition language (IDL) that supports both Java and C++. CORBA is commonly used to provide distributed component services for a smaller number of users with high-performance requirements. CORBA’s IDL facilitates the creation of networked distributed applications by simplifying the definition of interfaces that allow components to call one another that reside anywhere in the network, and may be implemented in any language that supports IDL. A component architecture such as J2EE provides standardized, extensible server-side and client side components to provide multi-tier distributed services. Java more typically uses remote method invocation than CORBA IDL for transferring data between distributed components.

Support for both CORBA and Enterprise Java Beans for distributed component management services can coexist in large applications. For instance, CORBA with C++ can be used for highly optimized transaction-oriented database applications, while Java Enterprise Java Beans and Java Applets are often used for highly interactive distributed applications

Given the multiple business processes performed by the applications within large confederated legacy systems and the tradeoffs between several possible alternative distributed component Web-based architectures, the definition of the most appropriate transformation approach is a complex decision to be evaluated. The decision requires an in-depth analysis of the customer’s applications, analysis of the implications of alternative solutions, and possibly some amount of iteration to define an appropriate transformation pathway.

This decision process is driven by

the current system architecture;
the target architecture objectives;
the technical infrastructure, including overall tool-set capabilities;
and personnel resources available to support this transformation process.

Conclusion

While transforming legacy source code to C++ at an automation level of 99.99 percent is achievable using the approach described here, experience has also shown that it is unwise to take too many steps along the modernization pathway at one time. Hence, one should regard the initial transformation into C++ as an easily achievable goal that provides the staging point for subsequent phases, including system refactoring, confederated system consolidation, and Web-enablement.

It should be emphasized that while high levels of automation are achievable for transformation tasks, a modernization project also involves development and adaptation tasks that are manually intensive such as infrastructure API layer development for unfamiliar legacy or target platforms. In addition, there are a number of tasks that by their very nature require human guidance or description such as certain forms of domain analysis and refactoring tasks that require specific domain expertise. We have however, been successful at minimizing the effort associated with these tasks by providing high levels of machine support for them as well.

Nevertheless, as today’s organizations address the critical structural, cultural, and financial issues surrounding the migration of their often irreplaceable legacy software applications and databases to modern platform-independent computing environments, it is essential that they understand that a new automated low-risk approach is available. Exceedingly advanced tool-sets and processes for rapidly reengineering legacy system software into modern computing environments provides organizations with a valuable new alternative that is faster, lower cost, lower risk, and higher quality than other methods currently available.