Understanding Web Services


The dawn of the service Web

In the beginning, there was the Document Web. The Document Web was powered by Web servers that spoke Hypertext Transfer Protocol (HTTP) and delivered information marked up in Hypertext Markup Language (HTML) for display on Web browsers. The Document Web was created to serve the needs of scientists who needed to share research papers. Businesses saw that the Document Web was a good thing, and many businesses created Web sites to advertise their products and services.

Then businesses wanted to do transactions with their customers, so the Application Web was created. The Application Web was powered by Web application servers, such as IBM® WebSphere® Application Server, which dynamically generated HTML documents from server-side business logic written in programming languages such as Java™. Web application servers acquired distributed programming capabilities, so that they could scale over multiple machines to handle large transaction rates. Web application servers also learned to speak Wireless Application Protocol (WAP) and deliver information marked up in Wireless Markup Language (WML), so that mobile customers could participate in the Application Web. e-business flourished.

Then e-businesses wanted to integrate their processes with other e-businesses, so the Service Web was created. The Service Web is powered by Web application servers that speak Simple Object Access Protocol (SOAP), and deliver information marked up in Extensible Markup Language (XML). Today, the Service Web is in its adolescence. We are currently witnessing the rapid maturation and deployment of a stack of interrelated standards that are defining the infrastructure for the Service Web.

The building block of the Service Web is the Web service, a set of related application functions that can be programmatically invoked over the Internet. The information that an application must have in order to programmatically invoke a Web service is given by a Web Services Description Language (WSDL) document. WSDL documents can be indexed in searchable Universal Description, Discovery, and Integration (UDDI) Business Registries so that developers and applications can locate Web services.

This article describes the Service Web, outlines the key standards of SOAP, WSDL, and UDDI, and discusses new tools for developing Web services. Armed with this information, you should be able to understand how Web services can enhance your business and how you can begin developing them.

The service Web

Web services provide an application integration technology that can be successfully used over the Internet. To illustrate this integration, consider how the Web is currently used for planning travel. Many Web sites sell airplane tickets, and most of them are well-designed for personal travel. However, they may not be useful for planning business travel, because many businesses have internal processes that control travel.

A typical business process for travel might require the use of preferred airlines, car rental agencies, hotels, and travel agents. A travel request might also require management approval to ensure that it is within corporate guidelines and expense constraints. Employees are highly motivated to follow their employer's business processes since failure to do so may result in denial of expense claims. A business may provide a travel planning application to help employees prepare travel requests.

Suppose you are an employee using your company's travel planning application. If the request form asks you to fill in your desired flight times, you naturally want to know what flights are available. Since your travel planning application is not integrated with the airline Web site, you must launch your Web browser, go to the airline Web site, find the schedule query page, and then enter your origin, destination, and dates and times of travel. The airline Web application then returns a list of scheduled flights, from which you choose the flight you want. But since the information on the airline Web page is probably in a different format than that required by the travel application, you must write down or copy the information, switch back to the travel application, enter the information in the travel application, and then submit your request.

A simple task that should have taken seconds, instead takes minutes, because there is no easy way to integrate the airline Web application with the corporate travel planning application.

Figure 1 shows the weak integration that exists on the Application Web:

Figure 1. Weak Integration on the Application Web
Weak integration on the Application Web
Weak integration on the Application Web

Consider how Web services could change this scenario.

Suppose the airline develops a Web service that allows applications to obtain the list of available flights between two cities on a given date. Now, the corporate travel planning application can programmatically invoke the airline flight schedule Web service, so that the employee does not have to navigate through the airline Web site. The ease of use of the corporate travel planning application is greatly improved. There is also a minor benefit to the airline since now its servers are more responsive. The Web service-based transaction is completed with a single request, whereas the traditional Web site returns many HTML pages and images to the user.

Figure 2 shows how Web services can improve application integration:

Figure 2. Improved Integration on the Service Web
Improved Integration on the Service Web
Improved Integration on the Service Web

Continuing this scenario, suppose that airlines, hotels, and car rental agencies provide Web services that allowed applications to programmatically purchase airplane tickets, book hotel rooms, and reserve rental cars. In most cases, a travel planning application could make all of the necessary arrangements without the aid of a human travel agent.

The use of Web services would reduce costs, improve quality, and increase function. For example, suppose the airline also had a Web service that monitored flight departure and arrival times. The travel planning application could query the airline to determine if your flight was delayed, and if so, it could then notify your hotel and your car rental company to hold your reservations.

Here, the economic motivation for businesses to implement Web services is improved customer service and more efficient management of inventory. For example, if the car rental agency knows that you will be two hours late, it might be able to avoid the cost of transporting cars between agencies in order to meet the worst-case peak demand.

More interestingly, the widespread implementation of Web services would also enable a whole new wave of advanced applications. For example, suppose your flight is oversold. Your travel application calls you in the departure lounge on your WAP phone and asks what you want to do. Your travel application can access an e-marketplace Web service that lists seats on this flight. If you have a confirmed seat, your travel application asks you if you would like to put your seat up for auction, shows you the current bids, and lets you specify an asking price.

Conversely, if you don't have a confirmed seat, your travel application asks you if you want to bid on a seat, shows you the current prices, and lets you specify a bid. If you need to check your agenda in order to make a decision, your travel planning application accesses your corporate calendar application Web service and displays your agenda on the WAP phone. If you don't have a confirmed seat but really need to get to that meeting on time, the travel application verifies that corporate expense guidelines are met and approves your bid. If your bid is accepted, the travel application submits the bill to the corporate expense statement Web service.

Figure 3 shows how powerful new applications can be assembled from the Web services of multiple suppliers:

Figure 3. The New Web services Economy
The New Web services Ecomony
The New Web services Ecomony

As the number of Web services increases, their interactions will become more complex and we may even begin to attribute characteristics such as intelligence or self-awareness to the Service Web. The usual vision of artificial intelligence as arising through some very complex thinking program must be re-evaluated. More likely, intelligence may arise as a network effect. After all, the brain itself is simply a very complex network of relatively simple neurons. It is likely that the first time a collection of interacting Web services displays a useful, unanticipated behavior, we will start to think of it as intelligent.

For example, suppose you also rent a cell phone with your car, because you want to avoid long distance charges or because your phone has no local coverage. Suppose also that while driving back from your meeting to the airport, your newly rented cell phone rings and your travel application tells you that the flight has been delayed. The first time this happens to you, you might be surprised and you might think the travel application was intelligent, especially if this capability had not been explicitly programmed into it.

This type of apparently intelligent behavior could arise through the following sequence of simple Web service interactions. When you rented the car and cell phone, the travel application requested the rental agreement from the car rental agency and submitted it to the corporate expense application. When the expense application received the invoice, it scanned the items and noticed a cell phone. The expense application then updated the corporate phone directory with the cell phone number. Later, the travel application requested the departure time from the airline and noticed that it had changed. The travel application then queried the corporate phone directory, retrieved your new cell phone number, and called you.

Most travelers would consider these kinds of notifications very convenient, but other kinds of unanticipated interactions might be undesirable. As we go forth and bravely build the Service Web, we should build appropriate safeguards and controls into it in order to prevent undesired consequences. Considerations of security and privacy will be more important on the Service Web than they are today on the Application Web, and could well become the differentiators between successful e-businesses and their competitors.

Web services standards

The Service Web is being built on Internet standards. One of the key attributes of Internet standards is that they focus on protocols and not on implementations. The Internet is composed of heterogeneous technologies that successfully interoperate through shared protocols, not shared middleware. No single vendor can impose a standard on the Internet, and no single programming technology will dominate. Fortunately, Web services standards are being cooperatively developed by IBM, Microsoft®, Ariba, and many others, and are being submitted to the World Wide Web Consortium (W3C).

Open-source software development plays a crucial role in preserving the interoperability of vendor implementations of standards. To understand this, consider the Apache Web server, which has rapidly gained market share to become the dominant Web server. The Apache Web server acts as the reference implementation of HTTP. Consider what would happen if the next release of Microsoft Internet Explorer or Netscape Navigator included a change to HTTP that made it only work with Microsoft Internet Information Server or Netscape Enterprise Server. The market share of such a vendor-specific Web browser would drop to zero. The existence of the Apache Web server prevents any Web browser or server vendor from fragmenting HTTP. IBM is actively contributing implementations of Web services standards to open-source projects in order to ensure interoperability on the Service Web.

This section discusses three major Web services standards:

A standard for messaging over HTTP and other Internet protocols
A language for precisely describing the programmatic interfaces of Web services
A business registry standard for indexing Web services, so that their descriptions can be located by development tools and applications.

Figure 4 shows how these standards are related to each other:

Figure 4. How SOAP, WSDL, and UDDI Are Related
How SOAP, WSDL, and UDDI Are Related
How SOAP, WSDL, and UDDI Are Related

Application servers host Web services and make them accessible using protocols such as HTTP GET, HTTP POST, and SOAP/HTTP. The Web services are described by WSDL documents, which can be stored on the application server or in special XML repositories. A WSDL document may reference other WSDL documents and XML Schema (XSD) documents that describe datatypes used by Web services. An XML repository is useful for managing WSDL and XSD documents. The WSDL documents contain the URLs of the Web services. The Web services are described and indexed in a UDDI business registry that contains the URLs of the WSDL documents.


SOAP is a standard for sending and receiving messages over the Internet. SOAP was initially proposed by Microsoft as a way to do Remote Procedure Call (RPC) over HTTP. IBM and other vendors contributed to the development of the SOAP 1.1 standard, which was then submitted to the W3C. The current SOAP specification allows transports other than HTTP, and other messaging styles in addition to RPC.

The SOAP specification defines an XML envelope for transmitting messages, a method for encoding programmatic data structures as XML, and a binding for using SOAP over HTTP. These features are best illustrated with an example. Consider a simple Web service that gives stock quotes. Here is a SOAP request sent over HTTP to the stock quote service:

POST /StockQuote HTTP/1.1 
Content-Type: text/xml; charset="utf-8" 
Content-Length: nnnn 
SOAPAction: "" 
                <m:GetLastTradePrice xmlns:m=""> 

In the above example, the request is being sent to the URL The request specifies that the GetLastTradePrice operation is to be performed using the symbol DIS.

Here is the a SOAP HTTP Response for the above stock quote service request:

HTTP/1.1 200 OK 
Content-Type: text/xml; charset="utf-8" 
Content-Length: nnnn 
                <m:GetLastTradePriceResponse xmlns:m=""> 

Here, the GetLastTradePriceResponse element contains the DIS price of 34.5. SOAP is being used in an RPC style in this example. However, SOAP can also be used for one-way message delivery.

The SOAP specification defines the SOAP encoding style, which defines a way to express data structures in XML. The SOAP protocol permits the use of other encoding styles, but this is a potential source of fragmentation, because if a Web service uses a different encoding style, then its reach is limited to only those applications that support that particular encoding style. Alternative encoding styles should be used only after careful consideration of the intended users of the Web service. SOAP messages are not required to use any encoding style in which case the message body is treated as literal XML.

The SOAP specification defines a binding for using SOAP over HTTP, but other transports may be used. For example, Simple Mail Transport Protocol (SMTP) can be used to send SOAP messages to e-mail servers. Using SMTP is useful for asynchronous message delivery.

SOAP is a relatively simple protocol, and is easy to implement, as witnessed by the explosion of implementations. One of the first implementations was done in Java by developmentor. IBM then released another Java implementation, called IBM SOAP4J, on the IBM alphaWorks Web site. The SOAP4J implementation was later contributed to the Apache XML project and was released as Apache SOAP 2.0 which runs on Apache Tomcat, IBM WebSphere Application Server, and other servlet engines. Microsoft released a SOAP Toolkit for use with Visual Basic. Many implementations of SOAP are now available, as shown by the list of Web services at XMethods.

SOAP has rapidly matured. In the Java world, many Java Specification Requests (JSR) were created to standardize APIs. The main JSRs are JSR 101, which defines the Java binding for SOAP, and JSR 109, which defines the deployment model for Web services. These JSRs are included in J2EE 1.4. The Apache Axis project implements JSR 101, while WebSphere Application Server V5.0.2 implements both JSR 101 and JSR 109. In the Microsoft world, Web services are supported by ASP.NET, which is part of the .NET Framework.

After the SOAP 1.1 specification was submitted to the W3C, it formed the Web services Activity to advance Web services standards, and created the XML Protocol Working Group to turn SOAP into a W3C standard. Recently, the SOAP 1.2 specification became a W3C Recommendation.


For an application to use a Web service, the programmatic interface of the Web service must be precisely described. In this sense, WSDL plays a role analogous to the Interface Definition Language (IDL) used in distributed programming. The description must include such details as the protocol, host and port number used, the operations that can be performed, the formats of the input and output messages, and the exceptions that can be thrown.

There were several proposals for languages to solve this problem. Microsoft first proposed Service Description Language (SDL) and provided an implementation of it in their SOAP Toolkit. After reviewing the proposal, IBM countered with the Network Accessible Service Specification Language (NASSL) and released an implementation of it in SOAP4J as the NASSL Toolkit. Ideas from NASSL influenced Microsoft's SOAP Contract Language (SCL), which was also planned to describe Web service composition (also referred to as workflow or orchestration). These proposals converged with input from several other vendors as the WSDL 1.1 specification, which was then contributed to the W3C. IBM and Microsoft continued to work on Web services composition and released the Business Process Execution Language for Web services (BPEL4WS) specification.

Here is a WSDL file that describes the stock quote service:

<?xml version="1.0"?> 
<definitions name="StockQuote" 
       <schema targetNamespace="" 
           <element name="GetLastTradePrice"> 
                      <element name="symbol" type="string"/> 
           <element name="GetLastTradePriceResponse"> 
                      <element name="Price" type="float"/> 
   <message name="GetLastTradePriceInput"> 
        <part name="body" element="xsd1:GetLastTradePrice"/> 
   <message name="GetLastTradePriceOutput"> 
        <part name="body" element="xsd1:GetLastTradePriceResponse"/> 
   <portType name="StockQuotePortType"> 
        <operation name="GetLastTradePrice"> 
           <input message="tns:GetLastTradePriceInput"/> 
           <output message="tns:GetLastTradePriceOutput"/> 
   <binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType"> 
        <soap:binding style="document" transport=""/> 
        <operation name="GetLastTradePrice"> 
           <soap:operation soapAction=""/> 
               <soap:body use="encoded" namespace="" 
               <soap:body use="encoded" namespace="" 
   <service name="StockQuoteService"> 
        <documentation>My first service</documentation> 
        <port name="StockQuotePort" binding="tns:StockQuoteBinding"> 
           <soap:address location=""/> 

The file begins with type definitions for GetLastTradePrice and GetLastTradePriceResponse using XML Schema. The remainder of the file builds up the Web service definition by assembling the types into messages, the messages into operations, and the operations into port types. It then binds the port type to the SOAP/HTTP protocol, and finally assigns it the address As is evident, this file is complex. Its construction is best left to tools that generate it automatically from simple parameters specified by the developer.

A notable feature of WSDL is that interfaces are defined abstractly using XML Schema and then bound to concrete representations appropriate for the protocol. WSDL has predefined bindings for the protocols HTTP GET, HTTP POST, and SOAP/HTTP, but is extensible. For example, in the case of HTTP GET, the binding specifies that the input message is encoded in a URL of an XML request body.

WSDL permits the description document to be composed from parts using an import mechanism. It is useful to put the abstract definitions in a separate file, so that they can be imported by many concrete bindings. For example, the travel industry could define an abstract flight schedule Web service interface, which would then have concrete bindings by many airlines. Each airline would create its own WSDL file that specified the protocols, hosts, and port numbers used by the airline's application servers, and would import the abstract definition of the Web service from the travel industry's XML repository.

WSDL is being standardized by the W3C Web Services Description Working Group, which is part of the Web services activity, and drafts of the WSDL 1.2 specification are available for public review.


UDDI addresses the problem of how to find Web services. UDDI defines a business registry where Web service providers can register services, and where developers and applications can find them. IBM, Microsoft, and Ariba implemented the original UDDI registries, but other vendors now also have implementations. A service provider only has to register a Web service at one of the business registries, because updates to any registry will be replicated in all of the other registries that are part of the UDDI Business Registry Network.

Figure 5 shows how the UDDI Business Registry Network is used by providers and users of Web services:

Figure 5. The UDDI Business Registry Network
The UDDI Business Registry Network
The UDDI Business Registry Network

UDDI is based on four types of entity: Business Entity, Business Service, Binding Template, and Technology Model:

  • A Business Entity describes the business that is providing the services. The Business Entity description includes categorization information so that searches can be performed for specific types of businesses.
  • A Business Service is a class of services within a business. Each Business Service belongs to some Business Entity.
  • The Binding Template and Technology Model (tModel) together define a Web service as described by WSDL. The tModel corresponds to the abstract description and the Binding Template corresponds to its concrete binding to a protocol. Each Binding Template belongs to some Business Service, but many Binding Templates can refer to the same tModel. A UDDI business registry is itself a SOAP Web service. It provides operations to create, modify, delete, and query each of the four entity types.

You can use UDDI at both development time and run time. At development time, you can search the registry for suitable services and use it to locate the appropriate WSDL file. Development tools can then be used to generate client proxies from the WSDL files so that the application can access the service. At run time, the application does not have to use UDDI if the target Web service is fixed and always available. However, if the Web service becomes unavailable, the application can query the registry to determine if the service has been moved to another location. This capability is useful when service providers have to rehost their services. UDDI can also be used at run time, for example, to determine all available services that implement some interface. For example, all car rental agencies could be located and queried at run time to find the lowest rates or the best availability at that moment.

The UDDI specification is being standardized by OASIS, along with new Web services standards for security, reliability, and other enterprise computing qualities of service.

Development tools

Although SOAP, WSDL, and UDDI form the infrastructure for Web services, developers should be shielded from their details, so that they can focus on the business problem being solved. Development tools that facilitate Web services development are now available.

Early versions of several IBM development tools, such as the WSDL Toolkit, the Web Services Toolkit, and the IBM XML and Web Services Development Environment, appeared on the IBM alphaWorks Web site, which continues to host emerging Web services technology. The IBM XML and Web Services Development Environment is now integrated into the IBM WebSphere Studio product, which contains a full suite of Java, J2EE, Web, XML, data, and Web services tools along with tools for building, debugging, testing, deploying, and profiling applications.

Figure 6 shows the WebSphere Studio desktop:

Figure 6. WebSphere Studio desktop
WebSphere Studio                     desktop
WebSphere Studio desktop

The Navigator pane shows the projects, folders, and files in the currently open workspace. The Editor pane contains two open files: and Many files may be open at once, but only one at a time can be selected for editing. You select the files using the tabs at the top of the pane. When a file is selected, its contents are displayed and it is outlined in the Outline pane. Parts of the file can be selected by clicking in the Outline pane. The All Tasks pane lists problems in the solution. Double-clicking on a task opens the file and scrolls it to the line where the problem occurred.

WebSphere Studio has a built-in Java development environment and a set of XML and Web services development tools. The XML tools include editors for XSD and WSDL. The Web services tools include a wizard that can create a Web service from a Java class, an EJB, or a set of SQL statements. The wizard can then generate a WSDL file that describes the Web service, generate a Java client proxy and server skeleton from a WSDL file, generate a Web test client from a WSDL file, and explore the Web services in a UDDI Business Registry. The Web services wizard frees you from dealing with the details of XML, SOAP, WSDL, and UDDI, and lets you focus on the business problem at hand. For more information on the Web services tools in WebSphere Studio, see the IBM Systems Journal article.


The key value business value of Web services is that they enable interoperability of applications that use different hardware, operating systems, programming languages, or middleware. While SOAP, WSDL, and UDDI are a good starting point, they contain too many features to ensure consistent implementation and interoperability. For example, early experience with SOAP exposed problems in achieving interoperability when using SOAP encoding. To ensure that Web services were interoperable, IBM, Microsoft, and other vendors formed the Web Services Interoperability Organization ( The membership of includes all major vendors and many customers, so there is good reason to believe that interoperability will become a reality in the near future. established a Basic Profile 1.0 that clarifies the specifications for SOAP, WSDL, and UDDI, and identifies a subset of features that can be implemented by all vendors in an interoperable way. The Basic Profile 1.0, which covers SOAP, WSDL, and UDDI, is in the final stages of approval and is part of J2EE 1.4. WebSphere Application Server V5.0.2 and WebSphere Studio V5.1 will enable the creation of compliant Web services. The Basic Profile 1.1 will include support for SOAP with Attachments and WS-Security. SOAP with Attachments allows binary documents, such as images, to be efficiently transported with XML SOAP messages. WS-Security defines how portions of SOAP messages can be digitally signed or encrypted. As new key Web services standards emerge, they will be added to future profiles.


The next generation of advanced Web applications will be constructed from Web services building blocks. By developing Web services, businesses enable their applications to be integrated into the processes of their suppliers, partners, and customers, yielding improved function, reduced costs, and competitive advantage.

Web services are based on open, implementation-neutral standards such as XML, SOAP, WSDL, and UDDI. The Web services infrastructure is now ready for serious consideration by businesses.

Development tools that support Web services standards are available and IBM has a full-featured suite of Web services tools in WebSphere Studio. We hope that this article has motivated you to look into this exciting new technology. Try out our tools and send us your feedback.

Questions from users

A great article! A lot of useful info in a short space! Just a few points. How the WSDL is actually used by the developer could be expanded. You mention that if a Web service is down, the UDDI can be dynamically searched for another service. But you don't say how to change the proxy object so that the call can be made to the newly identified service.

Response from author
If the client proxy fails to connect to a Web service, the reason might be that the Web service location has changed. If the Web service description if published in UDDI, then the application can dynamically query UDDI to obtain the current location. A Java application can use the UDDI4J class library to simplify the task of querying the UDDI registry and obtaining the new Web service location. If a new location is found, then the application can set the new value into the proxy. In the Apache SOAP run time, client proxies have a setEndpoint(url) method that you can use for this purpose. In JAX-RPC client proxies, the endpoint url is a property, for example:


To see additional user comments, click the View results button below.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

ArticleTitle=Understanding Web Services