The promise of service-oriented architecture (SOA), increasing benefits of Web services, and continued business use of legacy systems have all coalesced to usher in a new era of flexible IT alignment for business needs. With only a fraction of legacy applications being Web-enabled and increasing enterprise investment in SOA, organizations need to know how they can use Web services to leverage their legacy systems.

Web services can be used to leverage host systems and enable the transformation of legacy applications into Web-enabled composite applications. Such applications can better serve the enterprise by allowing a tight coupling of business needs with available IT resources.

Background
The majority of the Global 2000 run their business on host systems. Various analysts estimate that from 60 to 90 percent of company data is stored on host systems. Many of these systems run key, mission-critical business applications that the organizations heavily rely on; however, making changes to these back-end applications can be difficult and costly.

As companies move forward and extend their technology investments, they can benefit from the reuse of business logic and data from host systems. Additionally, for those applications that require user interaction, browser and mobile access can clearly provide a competitive advantage.

Besides host systems (e.g., CICS and IMS running on mainframe), most organizations may also have ERP and CRM applications such as SAP and Oracle running on UNIX or Windows. There may also be custom applications running on applications servers and middleware. Therefore, a new application may very well require access, aggregation, and composition of data and logic from multiple applications running on a heterogeneous infrastructure.

One solution is to use SOA principles to transform legacy applications to service-based composite applications that also integrate with other applications. Web services are one of the key enabling technologies in achieving this transformation.

Introduction to Web Services
Web services are self-contained, self-describing, modular application components that can be published, located, and invoked across the Web. Web services perform functions, which can be anything from simple requests to complicated business processes. Once a Web service is deployed, other applications (and Web services) can discover and invoke the deployed service.

A Web service message is basically an XML document wrapped in SOAP that is sent across an HTTP/HTTPS connection. There is a Web Service Description Language (WSDL) file associated with each Web service message type that tells the application what to do with the content. The structure of the Web service components is exposed using the WSDL. There may be an entry for this Web service registered in a UDDI, but there doesn't have to be. In summary, XML is used to tag the data, SOAP is used to transfer the data, WSDL is used for describing the services available, and UDDI is used for listing what services are available.

A Web service exposes the business objects to SOAP calls over HTTP/HTTPS and executes remote function calls. The output is rendered as XML and passed back to the consumer. The consumers of a Web service can invoke method calls on remote objects by using SOAP and HTTP/HTTPS over the Web. Figure 1 depicts a Web service accessing a mainframe.

Web services do not typically have a GUI; instead they share business logic, data, and processes through a programmatic interface across a network. The application developers can then add the Web service to a GUI (for example a Web page) to offer specific functionality to users.

Benefits of Using Web Services
The big advantage of deploying Web services is that they allow different applications from different systems to communicate with each other without time-consuming custom coding. Because all communication is in XML, Web services are not tied to any one operating system or programming language, which means that Java can talk to Perl, or UNIX applications can talk to Windows applications.

Applications typically use multiple Web services in combination to solve specific business problems. Examples include processing an order, updating multiple customer records from a single change request, or scheduling just-in-time arrival of parts for a manufacturing run.

For businesses, adopting an unproven new technology contains risk; there must be enough cost justification and business value in using it. Using Web services provides benefits to the business as well as to the IT department that supports it.

The advantages of using Web services are:

• To use a Web service one only needs to know its public interface and nothing about its implementation
• Use of "open standards" means no proprietary technology lock-in
• Transactions from back-end systems can be exposed as Web services
• Web applications and business services can be developed quickly
• IT cost is reduced through reuse of hardware and software

Application of Web Services to Legacy Systems
Organizations have a need to access data from various host applications and present it over the Web in a usable form to their users. They may also need to allow access to the back-end transactions over the Web for the authorized users. In this section we look at examples of using Web services with back-end legacy systems.

Consider a call center where a customer calls for an inquiry or service request. A customer service representative (CSR) answers the call and looks up the customer information in a legacy system where a CICS transaction accesses data from a DB2 database. The CSR then views the customer information in a 3270 screen, for example, and answers the customer inquiry or provides the customer with the requested service.

The CICS-to-DB2 transaction can be captured as a Web service and used in a secure self-service Web application. In addition, it is possible for customers to use their browsers to access the back-end system information in a simple user-friendly Web page. Now the customers can access and view the information whenever they want and as often as they want without having to talk to a CSR. The use of Web services and the Web itself lowers the cost of customer service and increases customer satisfaction.

Let's now consider a scenario where some of the needed data is stored in DB2 while other data is in flat files, perhaps a PDS (partitioned data set) or a sequential dataset. Furthermore, some of the data is accessed by a CICS system, and some by IMS. In this case, two applications are being used on the same host system to produce the required results. By using Web services, the data is retrieved from the two data sources and composed into a single Web page that the customer can view in a browser without knowing where the information is coming from. This is an example of a simple composite application, where data from multiple sources is aggregated and composed and presented in a single view (see Figure 2).

It may very well be that the data resides not only on different applications, but also on different host systems, potentially owned and run by different companies. This is illustrated in Figure 3.

Again, as far as customers are concerned, the application is simple to use. By using a browser the customer can request information, which results in transactions that run on different computers. The responses from those transactions are consolidated and displayed on a Web page. There may be different Web services that retrieve the data from each application and then the data is composed, perhaps using yet another Web service, into a single record that can be rendered within a single Web page. This is an example of a composite application.

In the aforementioned examples we looked at scenarios in which a customer retrieves and views specific data, but has no ability to update the data. Let's suppose that in our first example a customer wants to confirm the delivery address that a company has for him. He can make a simple query through the browser, which causes a CICS transaction to access the appropriate data. The data is then displayed in the browser. If the customer then decides that the address is wrong, he can update the information and submit the correct delivery address. This then causes another transaction to run that will update the company's database. This will obviously require security procedures to be in place to ensure that only authorized people can update the database. Although this is similar to our first example, there are now two transactions taking place - one to read the data and one to update the data - both within the same CICS system.