By linking up existing functions to create new, composite applications, organizations can unlock hidden value from their legacy systems.

	express delivery
	• print  • comment
	Service-oriented architectures and tools free up functionality in legacy systems for reuse in productivity-enhancing applications: Mainframe and other legacy systems hold valuable data and application code Data synchronization ensures transactional integrity Specialist tools ease the task of encapsulating selected functions as services Services give users improved access to existing resources Legacy assets are preserved while contributing to innovative new applications
	Glossary terms: legacy, composite application, EAI, WSDL, API, lookup tool Sponsored links: your text link here

The idea of reusing functionality isn't new, but the advent of service-oriented architectures and a new generation of integration standards and tools are finally making it a practical reality.

In these cost-conscious times, that's welcome news. In most enterprises, legacy systems account for a high percentage of the organization's application functionality, and they are where much of the most valuable data are stored. According to analysts at Forrester Research, there are some 200 billion lines of Cobol, the most popular legacy programming language, still in use. Nor is it going away: maintenance and modifications to installed software increase that number by five billion lines a year. IBM meanwhile claims its CICS mainframe transaction software handles more than 30 billion transactions per day, processes $1 trillion in transaction values, and is used by 30 million people.

The notion of reusing this functionality — as an alternative to building all-new replacement systems — has gone through ups and downs of popularity. "In the mid-90s companies moved off it, because it was not flexible," says Prasantha Jayakody, market manager at WRQ, which specialises in encapsulating legacy code as web services. But the Y2k scare refocussed attention on how much value was tied up in these core systems. "Then the whole downturn of the economy means economic reuse — and how you get the most out of what you have — is again top of the agenda," he says.

The economic incentive is what has driven WRQ customers like AT&T, Countrywide Financial and BT Retail to opt for reuse, fighting against developers' natural propensity to develop from scratch. The information has always been there; the problem has been making it easy for staff and customers to get at it. For example, customer service reps at AT&T's 1-800 toll-free number service had to access three different host systems before they could even begin to speak to customers who phoned in with order enquiries. AT&T turned this laborious process into a less than 30-second query, by setting up a composite application to pull data out of separate legacy billing, account details and order status systems. The project took less than four weeks to complete.

For BT Retail and Countrywide Financial, the problem was linking back-end systems into Siebel front-office software. In the case of Countrywide Financial subsidiary Balboa Insurance Group, it needed to include processes from separate loan-processing, policy-tracking and claims-management applications to create an online virtual claims processing department. It used WRQ software to encapsulate the functionality as services, which the Siebel software could then use to put the information online.

Three vital layers

The defining characteristic of these and other composite applications is their integrated, real-time access to a collection of discrete functions, which enables users to complete important business tasks faster and more accurately. Projects like these typically consist of three layers, each of which makes a vital contribution to the final result:

• Data synchronization — getting at the data stored in the legacy system;
• Functional reuse — encapsulating functionality from within the legacy application and offering it up as a service;
• Runtime presentation — integrating the services into the best runtime environment for users to take advantage of the new composite application.

In some projects, data synchronization is the major part of the work. Take Insurenet, for example, the healthcare insurance portal developed by composite applications specialist Quovadx for leading US hospital operator HCA. The project developed out of earlier work Quovadx had been involved with at HCA, linking data from its claims eligibility provider into its transaction broker. HCA later decided it wanted to bring in data from various other parties and present it in a web portal format that could also display transaction history.

"The beauty is the way we expose data from the integration layer as a web service," says Debbie Dean, EVP of product management at Quovadx. The incoming data is in financial services industry formats such as X12 and Swift, which the Quovadx software then converts into self-describing XML web services. "We can self-describe a transaction because we understand X12 and Swift formats. We set up maps and understand how to parse those structures to XML and then publish them to a portal."

Some legacy systems are harder to work with than others, she says. "If the system is closed you might have to do a screenscrape or take data in an archaic format. So it can take a bit of time, but we do all the heavy lifting." Building on its skills in composite applications, the Colorado-based company is branching out from its original stronghold in healthcare into financial services and elsewhere.

Reusing functionality

For most companies, the big cost savings come from moving beyond data extraction to actually reusing functionality. Dr Ian Howells, VP marketing EMEA at Californian vendor SeeBeyond, explains why: "When you examine how EAI has evolved, it has moved from simple data synchronization to business process management to composite applications and now to all three integrated together. This is critical, as having an integrated approach means infrastructure costs can be halved," he says, citing research from analysts at Giga. "To do this requires reusing many components such as: business processes, transformations and data models."

But if accessing legacy data is difficult, isolating and packaging the functionality within a legacy application is even more of a challenge. This is the area WRQ concentrates on, encapsulating legacy functions and then offering them up as a service to an integrated development environment (IDE), where the developer designs and runs the composite application. The IDE might be anything from Borland Jbuilder, to Visual Studio .NET and Dreamweaver, says WRQ's Jayakody.

"There are two aspects to encapsulation and creating composite applications," he says. "First, there is identifying the functionality in the existing application and having the ability to wrap it up. We focus exclusively on the host, mainframe, legacy and AS/400 — where most existing data logic sits now — and how to draw on that existing functionality. Our tools let developers encapsulate the logic that is on the host and make it usable by a modern IDE, by wrapping it in a modern technology wrapper."

That requires some understanding of the legacy application, he says — not at the programming level, but how the application works, how the host works, and the pieces of functionality that you need access to. Using the example of Cobol, he explains, this would include knowing how to make a session connection, how to manage that session and how to work with that session. This is the know-how that WRQ's product supplies: "Our toolset understands all mainframe, AS/400, OpenVMS, Unix systems. It knows how to communicate with the hosts, how to work through it and identify the functionality that is needed. So all the developer needs to do is drag and drop the functionality into a new application."

Real-time interaction

The final runtime layer presents all the assembled services for real-time interaction with the user. This is the most distinctive element of the composite application approach, and marks a contrast with traditional transaction-centric integration, which tends to focus solely on the data synchronization layer, distributing a change consistently across a number of systems.

In an interaction-centric system, a user might be configuring a car and looking at the cost of sports seats versus leather seats, with or without air conditioning. This new layer of real-time interaction involves calling on a number of back-end systems to offer the customer up-to-the-minute details about the car and the availability of each feature. Then when the user makes a choice and places an order, the system will push the transaction through the various systems in the traditional way.

This combination of user-directed activity and back-end data integrity adds responsiveness and flexibility without sacrificing the trusted reliability of the existing legacy systems. The key to success is the service encapsulation in the middle layer.

Services framework

For Germany-based mobile phone network operator T-Mobile, web services provided the framework for integrating its own back-end systems along with a portfolio of third-party services to offer up content to its mobile phone handsets.

"T-Mobile invested in web services two years ago. It was a very early adopter and it deserves credit for being forward thinking and adopting it on a large scale," says Zdenek Svoboda, director of product development at web services specialist Systinet. T-Mobile is using the vendor's WASP development tools and WASP Server run-time environment to integrate the internal systems and more than 300 external content providers.

"[T-Mobile] needed to communicate somehow with hundreds of partners," says Svoboda. "And they all have different technologies, so it was difficult to connect our different systems. But one of the attractions of web services is that there's virtually no client communication hit. All the differences are handled in the WSDL file and once you have the definitions, the interoperability is very good."

The project involves 65 different web services, including internal services such as billing, which are made available within an API that content providers can use to offer their services over the T-Mobile gateway.

Internally, T-Mobile uses Java to connect together its legacy application and C++ applications at the front-end, and then adds web services to extend this functionality, says Svoboda: "They've extended the use of C++ by putting a thin layer on top of the applications and exposing the business logic as a web service."

The key message, he concludes, is to have the confidence not to touch the existing application, but instead to use whatever connection framework is already in place — be it CICS, C++, Java, .NET or whatever — to offer up its capabilities as a service. The underlying legacy systems already provide the transaction integrity, so the most important work is encapsulating their functionality as services that can be called on by other application resources.

Once those services become available in a loosely coupled environment, they can be freely combined in the runtime layer for presentation to users. How they're combined is entirely down to the imagination of the composite application designer.

More on this topic