Technical Resources

Breathing Life into Legacy

September/October 2001
Frank P. Coyle

Legacy is an inevitable part of the technology curve: The new becomes old, and the software the company has relied on for years becomes cumbersome and difficult to integrate with newer systems. A decade ago the problem was how to connect mainframe applications—typically Cobol, data-intensive, and transaction-based—to client-server systems. Today, the problem is how to make both mainframe applications and client-server systems work with the Web.

E-commerce, in particular, has redefined the importance of legacy data. As the industry realizes the potential of wireless technology, the killer applications will be those that can get the data to the mobile customer, employee, or partner.

Both Y2K and the Web revolution have set the stage for an unprecedented leveraging of legacy code. Ironically, although the threat of Y2K put most software development on hold, the intense code assessment and cleaning also culminated in an up-to-date inventory of systems and applications. As a result, most companies are in better shape to exploit the Web environment than they were pre-Y2K .

Many companies are using a component technology—the Common Object Request Broker Architecture (Corba), Enterprise Java Beans (EJB), or the Distributed Component Object Module (DCOM)—to move data across the enterprise. The problem is that all variations of this technology are code-centric: The software must fit into a specific, often proprietary, program infrastructure before integration can take place. This limits the possible solutions to integrating legacy code.

With the Web revolution have come three technologies that offer legacy code a new dimension of freedom. Extensible Markup Language, or XML, describes data through the use of tags, eliminating the need to conform to a specific programming infrastructure. Web services let companies wrap software and tailor its distribution, allowing innovative code configurations. Wireless technology offers the ability to get legacy content to mobile workers and clients.

Each technology is part of the new arsenal for leveraging existing applications and data, perhaps realizing the elusive goal of anywhere, anytime services.

Extensible Markup Language

XML ranks high among data-enabling technologies—as high as relational database technology and Cobol’s Data Division. But unlike other technologies, XML puts data, not code, at the center of the computing universe. A metalanguage defined by the World Wide Web Consortium (W3C), XML is a set of rules and guidelines for describing structured data in plain text instead of a binary representation. It covers a range of hierarchical markup languages, and because it uses a text format to describe data, both programmers and users can examine the data without referring to the program that produced it.

These qualities make XML essentially code independent—a radical idea in distributed computing. They imply that XML offers companies extreme latitude in making data available to a Web-connected platform.

Designers of XML took the best parts of its predecessor, Standard Generalized Markup Language (SGML), to produce a technology that was just as powerful but much easier to use. Like most W3C initiatives, XML was created as a building-block technology, and its designers, like others who have created Web technologies, did not anticipate all its applications. XML’s unforeseen potential had much to do with its roots, as the "XML and the Culture Factor" sidebar describes.

Effects of data centricity

Because both XML and the Cobol Data Division are hierarchical, programmers can easily render Cobol data descriptions in XML. The following example shows the similarity between XML and a corresponding Cobol record:

‹ShoeOrder›

‹OrderNumber›3832‹/OrderNumber›

‹color›Brown‹/color›

‹size› 9 ‹/size›

‹width› AA ‹/width›

‹/ShoeOrder›

01 ShoeOrder.

05 OrderNumber pic 9(04) value "3832".

05 Color pic x(10) value "Brown".

05 Size pic x(02) value "9".

05 Width pic x(04) value "AA".
			

In these code fragments, for example, the familiar Cobol 01 record level corresponds to the XML top-level element tag ‹ShoeOrder›, which is closed with the corresponding end tag .

The Cobol 05 elements appear within the element as , , and and their corresponding end tags. This similarity means that developers can establish Cobol legacy applications as Internet components simply by transforming Cobol data descriptors into XML tags.

XML’s ability to liberate data from code also means that it could easily become the basis for data exchange across the Web—without changing current Web protocols. Middleware based on data rather than component interfaces would permit even greater legacy integration, since middle-tier servers could transform appropriately tagged XML into whatever form an application requires.

One W3C initiative, the XML Query Language (XQL), will allow tag-based document searches, which means that the age of mostly irrelevant search-engine results may soon be over. Another effort, the Web Distributed Data Exchange (WDDX) project, is a proposed standard for storing and exchanging XML data across the Web using HTTP (hypertext transport protocol). WDDX supports the exchange of common data structures including associative arrays, data dictionaries, hash tables, arrays, lists, strings, and Boolean values. Thus, it may be an alternative to object-based infrastructures such as Corba, the Component Object Module (COM), and EJB.

Potential applications

XML can play a dual role in the new Web environment. It can retain its original role as a technology for describing domain-specific data vocabularies, and in combination with HTTP it offers a way to make remote procedure calls with the same basic Web technology used to pass HTML (Hypertext Markup Language) data over the Web. This simple concept has revolutionized the distributed-computing landscape and is forcing software designers and architects to rethink their distributed-computing strategy. Instead of incompatible distributed-object infrastructures, such as Corba or DCOM, XML-driven specifications such as XML-RPC (XML remote procedure call) and SOAP (the Simple Object Access Protocol) offer globally available alternatives that any Web server can understand. XML-RPC lets one server execute code on another via an XML message that describes the subroutine or procedure and any required data parameters. SOAP defines an XML-based envelope for sending messages anywhere across the Web using the universal HTTP, which moves data from Web servers to browsers.

XML-based documents open up new opportunities for data transfer between industry partners and suppliers. In the mortgage banking industry, for example, bankers and purchasers of mortgages such as Fannie Mae are working on a standard for exchanging data about mortgage purchases. The work is producing an XML-based specification, Mismo (Mortgage Industry Standards Maintenance Organization), which in its current form defines data elements that specify the details—like property, borrower, and down payment—of a loan application.

In the past, lenders and purchasers have relied on proprietary protocols to deliver this type of information. By standardizing on an XML data description, they can package data conforming to Mismo in a SOAP header and deliver it over the Web using HTTP. Thus, any size mortgage lender will be able to communicate with mortgage purchasers such as Fannie Mae and Freddie Mac.

Web services

Web services is an effort to use XML to push the Web to the next evolutionary step—from providing services to users to providing services to software that needs to connect with other software. Thus, a Web service can be anything from a real-time weather advisory to an entire hotel and airline package. Web services evolve the object-oriented vision of assembling software from component building blocks to the assembly of services that may or may not be built on object technology.

Web services are unique because they concentrate on how businesses can describe the services or functionality they provide and how to publish such information on the Internet. They also address how other companies can find, connect to, and invoke needed services. XML provides the glue that allows such activity to take place without requiring elaborate infrastructures or proprietary software.

Most of the major software vendors—including Microsoft, IBM, Sun, Hewlett-Packard, and BEA—have Web services initiatives. Most initiatives are built on XML because it fulfills object technology’s promise of reusable components but from a service, rather than a code, perspective. Microsoft’s .NET initiative, for example, is built on XML messaging. IBM and Sun were initially slow to see the importance of XML but have now completely revamped their long-term strategic plans to include it.

How they work

As Figure 1 illustrates, Web services have three major elements: service provider, service requester, and broker. Service providers publish their services with the broker, and requests access those services by creating bindings to the service provider.

Click on Image to enlarge

Figure 1. Three elements of Web services

Web services rely on several standards. Publish-and-discover services use Universal Description, Discover and Integration, an XML-based standard. One of UDDI’s key components is a global registry that holds the business service descriptions and makes them available to requesters. Because UDDI is based on XML, services from the same vendor or across vendors will operate together.

Another Web services standard is the Web Services Description Language, an XML vocabulary that describes how a client program can connect to a Web service. WSDL describes the format of the request and response messages for remote access. The result is the ability to create new products, business processes, and value chains that can be delivered to other servers, desktops, or wireless devices, including cell phones or PDAs. Because Web services make no assumption about an underlying transport infrastructures both legacy systems and object systems can plug into the Web services framework.

Architectures based on Web services are beginning to emerge as tools become available. Dollar Rent-A-Car is one early adopter. The company established a link from Southwest Airlines’ Web site to Dollar’s reservation system using SOAP and Microsoft’s Windows 2000 server. Visitors can set up car rentals through Southwest’s Web site without ever having to leave the Southwest site. The software creates connections automatically behind the scenes using Web services’ protocols.

Microsoft’s Hailstorm is another example of Web services in practice. Hailstorm building blocks include Microsoft Passport, the online user identification service, and Microsoft Network’s Messenger instant messaging. The idea behind Hailstorm is to allow application developers to customize applications using software building blocks. For example, an individual traveling on business often must adhere to company travel policies. Hailstorm allows users to combine personal preferences with company policy to provide a smart travel service that satisfies both traveler and company.

Microsoft’s .NET

.NET is an umbrella term that describes Microsoft’s new strategy for Web services software. As Figure 2 shows, the .NET strategy calls for compiling different languages such as C++, Visual Basic, Cobol, and Java into Microsoft Intermediate Language (MSIL). Microsoft has even developed its own language, C# (pronounced “C-sharp,” like the musical note), an up-to-date object-oriented competitor to Java. Indeed, the .NET approach is similar to the Java technique of generating platform-neutral bytecodes that developers can port across platforms. In .NET, a Common Language Runtime (CLR) engine, which is both an interpreter and compiler, converts MSIL code into native code, using just-in-time compilation strategies to speed up native code performance. Not only can the intermediate code be ported anywhere but it can also be combined with intermediate code generated from other languages. Thus, developers can port an application that is partly C++ and partly Cobol.

Figure 2. Microsoft .NET framework

For the Cobol developer, the net effect is greater potential integration between Cobol programs and modules written in other languages. Organizations with a base of Cobol legacy code can compile existing Cobol modules using a Cobol .NET compiler and integrate it with other .NET language modules. Consider a three-part business application—a GUI front end in Visual Basic, business logic in C++, and legacy data access code in Cobol. Instead of trying to figure out how to integrate the three disparate pieces, developers can separately compile each piece to MSIL and deliver it to any .NET-compliant platform for execution. That one piece was written in C++ and another was written in Cobol makes no difference to the CLR engine because it executes all MSIL program components equally. The result is a new dimension of integration flexibility.

This ability to mix and match different language components forces developers to think differently about writing software. As the software industry moves to a service-oriented consciousness, it becomes more important to develop software components with an eye toward integration. For legacy Cobol, this means new ways to think about Cobol’s value. Programmers can now move Cobol code that was once perceived as mainframe only from that mainframe to any server simply by compiling it to .NET’s MSIL code format. The code is then in a position to become part of a Web service.

The .NET approach also makes it easier to debug large applications. Instead of having to work with different language-specific debuggers, developers can seamlessly debug complex applications that are based on code written in different languages. This is an important capability for those who want to integrate different language components into a single application structure.

ASP.NET

ASP.NET is Microsoft’s successor to Active Server Pages (ASP), the technology designed to deliver dynamic Web content across the Internet. ASP.NET is .NET enabled and overcomes several of the performance and programmability problems that plagued ASP. The ASP.NET technology also enhances the programmability of Web pages, helping to overcome the limitations of static HTML. Developers can build sophisticated Web applications, such as electronic storefronts, inventory management systems, and customer relationship management systems, programming them in Cobol or any of their favorite languages.

Unlike ASP, developers compile rather than interpret ASP.NET, which improves server performance. Compilation is dynamic, occurring only once when an Active Server Web page is requested. Thus, there is only a one-time hit to compile an ASP.NET Web page when the server first deploys it.

The real benefit, however, is that developers can use any of the .NET language family, including Cobol, in ASP.NET pages. This ASP.NET page, for example, uses Cobol to control a display that presents the phrase “Welcome to the XML-Cobol revolution!” in an increasingly larger font:

‹%@ page language="COBOL" %›

‹script runat="server"›

OBJECT.

DATA DIVISION.

WORKING-STORAGE SECTION.

77 FONT-DIMENSION PIC S9(9) COMP-5.

END OBJECT.

‹/script›

‹% PERFORM VARYING FONT-DIMENSION FROM 12 BY 1 UNTIL FONT-DIMENSION› 18 %›

‹font size="‹%= FONT-DIMENSION %›"› Welcome to the XML-COBOL Revolution! ‹/font› ‹br›

‹% END-PERFORM. %›
			

The ‹%@ characters announce the developer’s intent to use Cobol to define the page’s logic. The block that begins with ‹script› contains the Cobol code that defines the size of the display font and the characters ‹% introduce the inline Cobol code that loops and displays the HTML in varying sizes.

When a client requests an ASP.NET page, the server converts the script contained in the ASP.NET page into the language specified at the beginning of script. In the ASP.NET example, the server translates the script into Cobol, which it then compiles into MSIL for execution by the CLR. This is the Cobol code fragment that prints “Welcome to the XML-COBOL Revolution!”:

PERFORM VARYING FONT-DIMENSION FROM 12 BY 1 UNTIL FONT-Dimension › 18 

INVOKE ASP_output "Write" USING BY VALUE " ‹font size="""

INVOKE ASP_output "Write" USING BY VALUE FONT-DIMENSION

INVOKE ASP_output "Write" USING BY VALUE

"""› Welcome to the XML-COBOL Revolution! ‹/font›

‹br› "

END-PERFORM.
			

Cobol-based Web services

ASP.NET lets programmers package dynamic content onto server-side Web pages. The .NET environment also offers the option of exposing programming interfaces to the Web as a Web service. Web services are changing the way developers think about applications. Instead of building a monolithic application that integrates with other applications only through complex interfaces, developers are aiming to build applications with integration in mind from the start. For Cobol shops this rethinking has two benefits: First, developers can write new Cobol code and expect that they can make it available to a range of potential users who are not Cobol based. Second, developers can restructure existing Cobol programs as Web services, giving them new life.

The example that follows illustrates how to repackage a simple Cobol program as a Web service. Although the program does nothing but multiply two numbers and return the answer, it illustrates how easily programmers can turn existing Cobol application code into a globally available service. For organizations with Cobol code that returns important data or data aggregates, this conversion can mean significant new value for the enterprise.

‹%@ webservice language="COBOL" %›

CLASS-ID. MULTIPLICATIONSERVICE.

FACTORY.

PROCEDURE DIVISION.

METHOD-ID. MULTIPLY.

DATA DIVISION.

LINKAGE SECTION.

01 VAL-1 PIC S9(9) COMP-5.

01 VAL-2 PIC S9(9) COMP-5.

01 PRODUCT PIC S9(9) COMP-5.

PROCEDURE DIVISION USING BY VALUE VAL-1 VAL-2

RETURNING PRODUCT.

COMPUTE PRODUCT = VAL-1 * VAL-2.

END METHOD MULTIPLY.

END FACTORY.

END CLASS MULTIPLICATIONSERVICE.
			

From a Cobol perspective, the example is simply a Cobol class definition with a method called MULTIPLY. The webservice directive at the beginning of the code listing tells the .NET framework to expose any methods as Web services while specifying the language in which the service was written—in this case, Cobol.

Wireless technology

Wireless technology represents a leap forward in Internet-driven applications and services. However, viewing it as merely an extension of the desktop Web to handheld devices misses the point of what the wireless Web is all about. The wireless Web represents the convergence of the Web, which has radically changed how we do business and entertain ourselves in cyberspace, and wireless technology. Via the cell phone, wireless technology has introduced the ability to pinpoint a specific user and added a mobile dimension to e-commerce and enterprise computing.

As Figure 3 shows, wireless significantly augments the desktop experience in three areas. Although the media has centered much of the early hype surrounding wireless technology on delivering services to consumers, wireless also helps deliver services to other businesses and employees. It does so in three ways. First, wireless provides personalization. Instead of working with anonymous desktop Web requests, wireless network providers can identify users, letting applications leverage identity information to personalize content according to user preferences or usage patterns. For wireless consumer applications, tapping into legacy data stores becomes critical in tailoring content to individual preferences.

Click on Image to enlarge

Figure 3. Three main reasons for wireless technology.

Localization adds physical dimensions to personalization. Because wireless can locate users through either global positioning or sophisticated cellular triangulation techniques, applications will be able to activate database triggers that are based on personal profile and locale.

Finally, wireless offers immediacy. Companies can immediately deliver or push information to users when they need it rather than waiting until users log in or formally request it. Desktop Web is more about pulling information from servers through user requests. With always-on wireless computing, servers can push information to users in the same way cellular services push the time to your phone every minute. By tying such capabilities into mainframe batch-processing tasks, companies can bring the full power of legacy applications and data to bear on the Web’s challenges and opportunities.

What’s Ahead?

With data returning as the focal point of enterprise-wide application initiatives, XML is equipping Cobol with new power. Over the next year, as XML tools and techniques mature, expect to see Cobol applications playing a more central role in bringing data to the Web, particularly as wireless becomes an important data distribution technology.

Organizations with significant investment in Cobol should begin to think of their code as an asset, not a liability. The best way to leverage legacy assets is to represent critical data in XML. For Cobol, this means rewriting Cobol Data Division records as XML elements. This will enable B2B data exchange across the Web and serve as a first step in the migration to Web services.

In two to four years, as Web services technology standards mature, organizations will look to legacy assets as a source of value-added functionality. Expect to see companies springing up that repackage legacy assets with new software, assembling packages that are greater than the sum of their parts. By adopting a data-driven service consciousness, companies with legacy can reap the rewards of global distribution.

With XML the tide is turning. Instead of having to figure out ways to connect legacy Cobol applications with distributed client-server systems, the Internet is leveling the playing field with both legacy and client-server looking to XML as the new medium for Web connectivity.

Frank P. Coyle is on the faculty at Southern Methodist University, Dallas, Texas, where he is director of the Software Engineering Program and faculty associate at SMU’s Hart eCenter. Parts of this article are based on Coyle’s book The Wireless Web—A Manager’s Guide (Addison Wesley, 2001). His book XML, Web Services, and the Data Revolution is scheduled for publication by Addison Wesley in 2002. Contact him at coyle@engr.smu.edu.