In-Depth

Java Migrates Legacy to the Web

• 08/01/1999

Mainframe-based CICS and IMS systems remain the application backbone infrastructure of many corporations, and often specify the rules by which the business operates. They are valuable, represent a huge financial investment and support the timely operation of the business.

Why, then, are so many companies in need of a cost-effective way to migrate legacy applications to new architectures? There are two fundamental reasons.

First, changing business needs are driving organizations toward e-business. They are using the Web to provide seamless interaction with customers, partners and vendors, and are deploying employee intranets to streamline communication, increase productivity and reduce costs. These changes demand that information on legacy systems be made available to more people in newer contexts.

Second is the advancement to superior software engineering technologies. Multi-tier architectures and distributed object technology can reduce application development and deployment costs while offering much-needed flexibility. Migrating legacy data to these new architectures meet the business need while controlling application ownership costs.

In both cases, Java provides a flexible, complete and cost-effective solution.

Java is a programming language developed by Sun Microsystems and designed for use in the distributed environment of the Internet. Java is revolutionary in that it views data as objects, rather than procedures. Java programs are a collection of collaborating objects, with each object responsible for carrying out a set of related tasks.

Object-orientation is one of the features that gives Java its tremendous portability. Other features like garbage collection and array index bounds checking help programmers write correct code and make their applications more reliable than other languages.

Java also cuts costs. Distributed Object and Components technologies, such as Java, lower application development costs, primarily, by distinguishing between the component-writer and the component user. The writer writes and sells useful, reusable and sophisticated components with well-defined interfaces, and the programmer uses the blocks to develop an application. Component technologies claim to be elegant, scalable software design. They are commonly adopted by developers of new applications, and can also benefit existing legacy applications.

Sun developed Java on an enterprise platform that integrates the programming language with enterprise requirements such as networking, database connectivity, transactional applications, mail, naming services, distributed objects and others. Whatever functions are to be included in the Java environment can be written into the supporting software by the company’s programmers, who simply specify Application Programming Interfaces (APIs). This ability to build on standard protocols, open enterprise APIs and Access Methods to Java components, makes the Java enterprise platform a rich, flexible system.

The enterprise Java platform can also serve as the foundation for migrating existing legacy systems to achieve the two goals identified earlier: serving the business need and taking advantage of newer technologies.

In the first scenario, the company launches their Web site, and the first capability customers expect is checking the status of their orders. This information is stored on a legacy system, which wasn’t designed for customer-centric views of the data. Typically, an employee requested the information, viewed it on a terminal and reported to the customer. For the customer to view the data on the Web, new applications must be built using the legacy components. Java is the tool of choice for building these applications.

In the second scenario, the organization needs a system that will allow multiple users on different systems to access information from different sources. For all the users to read the data, it must be extracted, filtered, transformed and presented to the requester in a readable, coherent application. This transformation requires much more than a simple Web-enablement tool.

Organizations that are serious about adopting Web technology as part of their information strategy must invest in a Web application framework that will allow extending its internal systems, as well as integrating back-end databases and workflow processes, to the Web.

A migration effort using the enterprise Java platform allows the organization to build new, low-development overhead applications that can rapidly integrate information from disparate sources and present it as dynamically built Web pages in a Web application.

This framework is more than Web connectivity, Web middleware or a Web authoring tool that has interfaces to applications and databases. The framework is the convergence point for all databases and applications within the enterprise network.

This is the point where the essential functionality of the legacy application is extracted and transformed to a more evolvable system. While the enterprise Java platform doesn’t guarantee an evolvable system, it does provide an architecture to support it.

Web-enablement solutions must connect to legacy applications, as well as access data stored in relational and non-relational databases on enterprise networks. All solutions are compatible with the multi-tier architecture of the Web.

The Web browser component provides limited validation of the data before presenting it to the end user. The presentation is deployed as HTML pages on the public Internet, or as a mixture of HTML and Java applets in an extranet environment. In the latter, the application also may include a layer of authentication and access control.

The middle tier, consisting of data access logic and business logic, is implemented by server-side Java. This tier is typically deployed as Java servlets running off a Web server and servlet engine.

IBM’s WebSphere application server is an example of a servlet engine, and Apache is an example of a Web server. Server-side Java is a preferred middle tier because of its portability. Servlets are essentially Java programs that deliver all the benefits of Java programming, the most important being portability.

The Web server can run on an NT box, AIX box, or even low-cost or no-cost Apache Web servers on a Linux box. This flexibility makes the server-side Java solution both efficient and scalable.

The middle tier connects to the back ends, either databases or applications, via one or more technologies. The back ends provide the server-side data access logic, and implement stored procedures in accessing data or transactions. In the case of a database, the middle tier (Web server + servlet engine) would use JDBC to connect to the database server.

Numerous technologies and tools can be used to implement Web-based connectivity to host applications. Three basic approaches are screen scraping terminal sessions and changing the interface, wrapping the application by writing interface code callable by communication programs, or completely rewriting the application using middleware like MQSeries or CORBA.

Screen scraping terminal sessions and changing the interface involves implementing GUI interfaces to existing console-based applications. Web-based emulation Java or ActiveX applets are downloaded from the Web server to the desktop browser on demand. Users are presented with a standard terminal screen, and interact with the host application just as they would with traditional emulation software.

A commercial product is used to initiate a terminal session to the back end while presenting a Web-interface to the user and translating user-inputs to the mainframe as keystrokes. Typically, one would have described the console application to the product, which uses the definition to create the Web interface that is presented to the user.

This approach is recommended when the goal is limited to extending a single application to the Web. It does not require a significant investment to review the existing application, or build new interfaces. While it may be considered by some to be sloppy, inelegant and inefficient, the benefit cannot be denied – no changes are needed to the back end.

Wrapping the application by writing interface code callable by communication programs is primarily providing a set of more open interfaces. This allows the application to be accessed by the Web, or an open standards-based approach.

Depending on the business need, one may choose to use middleware, such as remote procedures or messaging, between the middle tier and the wrapped-up back end.

This approach is recommended when mission-critical or complex applications must coexist with a new user interface or business logic client, but the organization doesn’t want to invest in rewriting the application. Instead, an interface is provided that allows the new client to interact with the application to perform operation, such as information revival or updates.

The third method is when the legacy application is completely rewritten. The user-interface and business logic components are separated, and a middleware layer is added to provide the connectivity. If it was an online application requiring a constant connection between the user and the host, middleware products would employ technologies like queueing messages to enable communication over the connectionless protocol of the Web. This is what middleware products like MQSeries from IBM do.

While screen scraping doesn’t require any changes to the original legacy application, a middleware solution may require the APIs on the legacy program to be modified for compatibility. This would be the equivalent of white-box re-engineering, where an understanding of the legacy program is required to modify the API.

This approach is used for extremely critical applications, when control needs to be centralized or when the application is prone to change in its implementation with the access methods remaining the same, and the business needs a Web-deployed solution.

The following are three "architecture-level" examples for putting together the enterprise technologies in connecting to legacy applications.

Connecting to AS/400. AS/400 Toolbox for Java is a set of Java classes that allows you to access AS/400 data through a Java program. You can write client/server applications and applets that work with the data that resides on your AS/400.

You also can run Java applications that use the AS/400 Toolbox for Java on the Java Virtual Machine. The AS/400 Toolbox for Java uses the AS/400 servers as access points to the system. Each server runs in a separate job on the AS/400, and each server job sends and receives data streams on a socket connection.

Connecting to IMS. The IMS TOC Connector for Java allows Java programs or servlets to access IMS transactions. The application requires a TCP/IO OTMA connection and needs IMS 5.1 or above.

Connecting To CICS. The CICS Gateway for Java allows Java programs to access CICS applications using programming interfaces. The External Presentation Interface (EPI) provides a 3270 CICS data stream to the client program. EPI can be used to extend existing programs to provide a more productive user interface.

The External Call Interface (ECI) provides a mechanism to call existing or new CICS programs. ECI exchanges data through communication areas, and existing programs may have to be modified.

The considerations for implementing a Java strategy are similar to those considered in implementing any IT strategy. The organization should assess its available skills, identify the specific applications involved, and evaluate all potential solutions and tools.

It is wise to deploy a pilot project first, preferably a small, low-risk application in a low-risk environment, to gain direct experience with Java technologies.

And it is always recommended to work with a provider that takes the time to learn your needs, your systems and your objectives. Java is an extremely useful tool for migrating legacy systems to the Web, but your IT provider must understand your business goals to know if Java is the right solution for you.

About the Authors: Prasad Thammineni is VP of Specialized Software’s Enterprise Solutions Group at Specialized Software.

Suresh Madhu is a software engineer and Java developer at Specialized Software (Worcester, Mass.; www.Specialized Software.com).

**** Sidebar ****

Understanding what the system does and how it can be improved, falls under the domain of Software Re-engineering. Distributed Object Technology is having an impact on the nature and economics of re-engineering by shifting focus from traditional "deep" program understanding (White Box) to "shallow" interface understanding (Black Box).

Program understanding is difficult. Research has largely focused on understanding monolithic systems by top-down cognition models and expensive CASE (Computer Aided Software Engineering) tools. The cognition models are reverse-engineering techniques to create higher level abstractions of program structures, recovering at various levels the implementation, architectures and design concepts. CASE tools are used to gather data from programs, structure the data for domain-level reasoning, and as navigation and presentation tools. The traditional view is that understanding the system will help transform it to a more evolvable system over a period of time.

Instead of trying to understand the Black Box program through its structure and control flow, one tries to understand the interfaces and data formats that the original program provides. This sort of "dynamical analysis at the system level" yields large-grained artifacts that need no modification, but can be wrapped and reused. The cost/benefit ratio of migrating a mainframe application using this technology is 1:10 and rising, to the cost of replacing a legacy program based on a "deep" understanding.

Reuse in a component-based architecture is initiated when the re-engineered legacy assets would provide equal or greater functionality than building the original asset from scratch. If migrating toward a component-based architecture, one would identify the re-usable artifacts of the legacy as either Black Box or White Box components at the beginning of the reuse effort. Black Box components would simply be reused. White Box components would require more generality or newer functionality, and need to be opened up and modified. One could then use program understanding technology for the White Box components, and interface analysis for the Black Box components for deep or shallow understanding before component wrapping them.