How Web Services Can Help Solve Legacy Systems Incompatibility Problems

Imagine the following scenarios:

1. Your company (or government) decides that it wants to provide its customers (constituents) with a slew of new services over the Internet. However, the services needed reside on legacy (aged) systems that run nonmainstream operating environments and are written in nonmainstream development languages.

2. Your company acquires a competitor that happens to use a completely different systems infrastructure. (You use mainframe hardware and Cobol or Fortran programming languages; they use Windows platforms for operations and the C++ language for application development.)

In the past, either of these scenarios might have meant great gnashing of teeth for IS managers. The need to mesh disparate systems and network infrastructure, applications environments, and databases usually led to:

• One of the systems environments being chosen as the "standard" while the other was either jettisoned or eventually phased out);

• Complete systems retraining for individuals who were on the losing side of the system standard choice; and

• Lots of additional work integrating disparate databases and applications.

Today, at least the communications highway that each company (or the government) used would be consistent; they would use the TCP/IP communications protocol, which is the basis for Internet communications. On this common basis Web services can provide a solution for system-to-system, program-to-program interoperability.

Web services enable applications written in different languages to present their data in a common form (XML) to each other. And the common information highway, the Internet, makes it possible for these two environments to share data. By setting up a private UDDI directory, Web services enabled applications could find each other and share information. And by using SOAP, sessions can be bound between these disparate computing environments. Thus, through the use of Web services protocols and registry services, disparate applications and databases can be made to work together without the total redesign of systems, application, and database that might have been necessary in days gone by.

In the scenario where the government provides services to external constituents, notice in Figure 5-6 how a user can make a request over the Internet for a service and how the UNIX/Java system calls the legacy system for data. Once it receives that data, the information/service is provided back to the constituent transparently. (The recipient receives a service made possible by using Web services architecture between two disparate system types behind the Internet cloud.)

Figure 5-6. Web Services on the Back End to Help Resolve System/Data/Application Incompatibilities.

Not So Fast…

A lot of work has gone into making Web services easy to use for those who program in the C++, C#, or Java application development languages. Many application development environments have been optimized to enable C or Java code to be automatically compiled (converted into efficient system code), and many vendors offer code that assists in the automation of workflow among applications. Such is not the case, however, for less mainstream languages such as Fortran, Cobol, and several other once popular or somewhat specialized languages. Hence, the real state of the art in terms of cross-environment language support is geared for C-based or Java-based language environments.

Note that in our example scenarios the lack of a common, public UDDI directory was not a factor, because each scenario needed to provide Web services only to internal applications. (In other words, hard-coding the location of the applications that share services is a perfectly acceptable practice in these scenarios.)