Last month, in my column on, I provided a nontechnical introduction to some of the reasons for the interest in Web services. The complexity of remote procedure call (RPC) approaches for different application program interfaces (APIs) has meant that code module integration and reuse has been time-consuming and difficult. Web services and associated XML technologies have been developed to address real-time program and code module integration. This month we will further examine the concepts of Web services.

Most enterprises have a common problem: They use different business processes and procedures to do the same thing where a common standard procedure could be used instead. For example, a common problem is experienced in updating a changed customer address in each of the different versions of customer data in an enterprise. The customer address may need to be changed in the customer database (in the sales department), the client database (in the credit control department) and the debtor database (in the accounts receivable section of the finance department).

These databases must be changed using special address-change maintenance programs written for each separate database. The same details must be updated in every database where the customer's address exists redundantly. This is redundant work. It requires redundant staffing to make these redundant changes. These programs may each use change procedures that do not operate the same way. If programs used for address update all have different data-entry operating procedures, this also means redundant training.

This address data should have the option to be updated using a common customer address update process, used as a single standard process throughout the enterprise. This will lead to the design of common, reusable business processes using Web services, and common Web service processes and workflows.

Now let us consider the concepts, components and potential of Web services in the IT industry.

Web services have recently emerged to address the problems of software integration. Early work carried out independently by various companies from 1999 to 2000 culminated in the submission by IBM, Microsoft and Ariba of initial Web Services Specifications for consideration by the World Wide Web Consortium (W3C) in September 2000. More than 130 companies are now collectively working on a set of specifications for interoperable Web services.

Web services are based on XML. IBM alphaWorks Web site ( describes Web services as follows:

Web services are self-describing, self-contained, modular applications that can be mixed and matched with other Web services to create innovative products, processes and value chains. Web services are Internet applications that fulfill a specific task or a set of tasks that work with many other Web services in an interoperable manner to carry out their part of a complex workflow or a business transaction. In essence, they enable just-in-time application integration, and these Web applications can be dynamically changed by the creation of new Web services. Various applications that are available on the Internet can be accessed and invoked at runtime without prior knowledge and programming requirements to enable business processes and decision making at Web speeds. IBM's Web Services Toolkit provides a runtime environment as well as demonstrations and examples to design and execute Web service applications to find one another and collaborate in business transactions without programming requirements or human intervention.

Previously, to combine or integrate different application programs, each API used by code modules in those programs was defined for the specific language and operating system used. This generally meant that all programs had to use the same language and operating system. This made program integration very difficult in the past. Code modules integrated using RPC technologies such as COM or CORBA interfaces have been used as we discussed earlier, but they are tightly coupled. Because of this tight coupling, a change that is made in one component can also affect other components. While they are effective, these technologies have been very complex and time-consuming. Therefore, they have been expensive to use and maintain.

In contrast, APIs can also be defined using XML. An API can be specified using an XML language called SOAP (simple object access protocol), which offers the advantage that it can be used with any programming language and operating system that understands XML. As SOAP is much simpler, integrated code modules can be loosely coupled. This means that changes in one component do not affect other components as we saw with tightly coupled RPC approaches. Because of this, SOAP is less expensive to use and maintain.

The definition of APIs using SOAP is one required component of Web services. The services that can be carried out by the code module or program must also be described. This is specified using another language based on XML, called WSDL (Web services description language). WSDL identifies the SOAP specification and interface that is to be used for the code module API. It identifies the SOAP message formats that are also required for input to and output from the module or program. Each WSDL specification is then used to describe the particular Web services to be accessed via the Internet, or from a corporate intranet, by publishing it to a relevant Internet or intranet Web server.

However, SOAP and WSDL alone are not sufficient. Unless Web services are published in an electronic "yellow pages" directory that is accessible within the enterprise (via an intranet) or available worldwide (via the Internet), no one would know of the existence of the available Web services. Fortunately, a further XML language called UDDI (universal description, discovery and integration) is used for publication in a UDDI directory, which enables the Web services to be found by others.

In an upcoming column, I will discuss two examples that illustrate how Web services can be used within an enterprise and also between enterprises. They will illustrate the power, ease of use and flexibility of Web services.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access