Defining Web Services

The World Wide Web Consortium (W3C), which is responsible for the development of interoperable technologies (specifications, guidelines, software, and tools) to lead the web to its full potential, defines web services as:

A Web Service is a software system identified by a Uniform Resource Identifier ( URI ), whose public interfaces and bindings are defined and described using XML . Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML based messages conveyed by Internet protocols.

A web service is a programmable entity that provides a particular element of functionality, such as application logic, and is accessible to any number of potentially disparate systems using ubiquitous Internet standards, such as XML and HTTP. Web services depend heavily on the broad acceptance of XML and other Internet standards to create an infrastructure that supports application interoperability at a level that solves many of the problems that previously hindered such attempts.

A web service can be used internally by a single application or exposed externally over the Internet for use by any number of applications. Because it is accessible through a standard interface, a web service allows heterogeneous systems to work together as a single web of computation.

With the introduction of XML, data exchange between systems residing in different environments was made much easier. Web services then added an entirely new dimension. Instead of pursuing the generic capabilities of code portability, web services provide a viable solution for enabling data and system interoperability. Web services use XML-based messaging as a fundamental means of data communication to help bridge differences between systems that use dissimilar component models, operating systems, and programming languages. Developers can create applications that weave together XML web services from a variety of sources in much the same way that developers traditionally use components when creating a distributed application.

One of the core characteristics of a web service is a high degree of abstraction between the implementation and the consumption of a service. By using XML-based messaging as the mechanism by which the service is created and accessed, both the web service client and the XML web service provider are freed from needing any knowledge of each other beyond inputs, outputs, and location.

XML web services are enabling a new era of distributed application development. It is no longer a matter of object model wars or which programming is better than the next. By tightly coupling systems using proprietary infrastructures , you limit application interoperability. Web services deliver interoperability on an entirely new level that negates such counterproductive rivalries. As the next revolutionary advancement of the Internet, web services will become the fundamental structure that links together all computing devices.

The architectural design of web services seems to be a natural evolution from the previous generation of object-oriented design (OOD) and the components developed to match that design. Web services implement fundamental concepts from OOD, including encapsulation, dynamic binding, message passing, and service description and querying. The concept of providing functionality as a service lies at the heart of web services. The API is published for use by other systems and the implementation is encapsulated within the web service's logic.

In addition to interoperability and extensibility, the real power of web services is the ability to combine multiple web services to achieve a more complex solution. A web service that provides a simple service can interact with another web service to deliver a more complex service. Simply put, a web service allows one system to call a function in another system and pass data through as XML without regard for the platforms or implementation details of either system.

Understanding Web Services

To really understand web services, you need a basic understanding of what makes the technology tick. Web services combine the best aspects of component-based development and the web. Just as components represent black-box functionality that can be reused without worrying about how the logic is implemented, web services can be reused and the implementation of the logic is encapsulated within the service.

Unlike almost all current component technologies, web services are not accessed via object model “specific protocols such as DCOM or RMI. DCOM, for example, is a binary protocol that consists of a method request layer that resides on top of a proprietary communication protocol. Such protocols are not conducive to creating highly interoperable applications. One of the major drawbacks of using a protocol such as DCOM is that its dependence on a specific archtecture of underlying systems limits the spectrum of potential clients . Instead, web services are accessed via universal web protocols and data formats, such as HTTP, XML, and SOAP. Furthermore, a web service interface is defined strictly in terms of the messages that the web service accepts and generates. Consumers of the web service can be implemented on any platform in any programming language, as long as they can create and consume the messages defined for the web service interface.

There are a few key specifications and technologies you are likely to encounter when building or consuming web services. The following sections discuss the five main specifications and technologies required for service-based development.

XML for Data Representation: A Standard Way to Represent Data

XML is a meta-markup language that provides a format for describing structured data. The ability to describe structured data from within the data structure itself makes it possible to describe content more precisely. Because XML is a standard that is based on ASCII strings, XML can be used across multiple platforms as well.

XML is the understandable choice for a standard way to represent data. Web service “ related specifications use XML for data representation as well as XML schemas to describe data types. Developers must master XML as a prerequisite to building web services.

Listing 4.1 shows an example of a simple XML document containing information pertaining to a purchase order.

Listing 4.1. Example of a Simple XML Document

 <?xml version="1.0" encoding="utf-8"?>   <ORDER ID="012593">     <CUSTOMER ID="85783">       <DELIVERYADDRESS>         <ADDRESS1>4301 Conn. Ave, NW</ADDRESS1>         <ADDRESS2>Suite #135</ADDRESS2>         <CITY>Washington</CITY>         <STATE>Washington</STATE>         <ZIPCODE>20008</ZIPCODE>       </DELIVERYADDRESS>     </CUSTOMER>     <ITEM ID="123654">       <QUANTITY>7000</QUANTITY>       <DISCOUNT>25</DISCOUNT>       <PRICEPERUNIT>1.99</PRICEPERUNIT>     </ITEM>     <ITEM ID="987123">       <QUANTITY>100</QUANTITY>       <DISCOUNT>2</DISCOUNT>       <PRICEPERUNIT>7.50</PRICEPERUNIT>     </ITEM>   </ORDER> 

This example shows that, by using XML, you could write an entire purchase order in a single document that outlines customer information, delivery information, and order information. It also demonstrates the use of XML elements and attributes. Line 2 of the example displays the order number in the following format: <ORDER ID="012593"> . The order identifier ( ID="012593" ) within the order element is an attribute. Further down, <QUANTITY>7000</QUANTITY> is an example of a value that is defined as an element.

Of course this is just one of many ways to describe a purchase order; but with that in mind, you can see the power of the XML standard. The ability to describe the same data in many different forms allows XML to be used in many different scenarios. One of these scenarios is web services.

SOAP As a Messaging Protocol: A Common, Extensible, Message Format

Web services require a messaging protocol that can invoke a web service and exchange data with it. SOAP is a lightweight, XML-based protocol for exchanging structured information in a decentralized, distributed environment. It is a network protocol, with no underlying explicit programming model. The main design goal of SOAP was to keep it as simple as possible and to provide as little functionality as possible. Because SOAP does not mandate the technology used to implement the client or server applications, it requires no application programming interface (API) or object model. As such, SOAP provides an open methodology ”XML web services ”for application-to-application communication. The protocol defines a messaging framework and does not contain any application or transport semantics. As a result, SOAP is an extremely extensible framework.

Because SOAP uses standard transport protocols, it can leverage the open architecture of the Internet and gain easy acceptance by almost all systems that support the basic Internet standards. SOAP adds very little to the existing infrastructure of the Internet. The fact that SOAP uses the simple infrastructure of the Internet, thus facilitating universal access to web services built on this platform, demonstrates how powerful the protocol really is.

The SOAP specification consists of four main parts :

• An extensible envelope for encapsulating data. The SOAP envelope defines a SOAP message and is the basic unit of exchange between SOAP message processors. This part is the only mandatory part of the specification.

• Data-encoding rules for representation of data types defined in the application, directed graphs, and a uniform model for serializing nonsyntactic data models. This part of the specification is optional.

• An RPC-style (request/response) message exchange pattern. Each SOAP message is a one-way transmission. The fact that SOAP's origin lies in RPC does not limit it to being a request/response mechanism. XML Service often combines SOAP messages to implement such patterns, but SOAP does not mandate a message exchange pattern. This part of the specification is optional.

• A definition of the SOAP and HTTP binding. SOAP can potentially be used in combination with any transportation protocol or mechanism. This part of the specification is optional.

To read more about the SOAP specification, look on the W3C web site at www.w3.org/TR/SOAP/.

WSDL as a Contract Language: A Common, Extensible Service Description Language

The infrastructure of web services is based on communication by means of XML-based messages that abide by a published service description. To support this design, Microsoft and IBM jointly developed a standard for describing web services, called Web Services Description Language (WSDL). WSDL defines the XML grammar used as a standard mechanism for creating and interpreting web service contracts. WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is used to create a file that identifies the services and the set of operations within each service that the server supports. The WSDL file also describes the format that the client must follow in requesting an operation.

The services description serves as a contract between the web service provider and the clients and defines the behavior of a web service. The "contract" includes instructions on how clients interact with the web service, including the messaging patterns (the messages that it accepts and generates) that the service defines and supports. For example, the request/response pattern associated with a remove procedure call style service would define which SOAP message schema to use for invoking specific methods . This pattern would also define the format that the resulting response SOAP message should follow.

Another example of a messaging pattern represents unidirectional interactions. This pattern is implemented when one-way communication is to take place. In this situation, the sender does not receive any messages from the XML web service. If the one-way communication is established using a protocol that is traditionally request/response, however, a fault message might be returned.

SOAP message schemas can be defined internally, within the actual service description, or they can be defined externally and imported into the service description. The service description can contain the address that is associated with each of the entry points within the web service. The format of the address is appropriate to the protocol used to access the service. Examples include URL (Uniform Resource Locator) for HTTP or an email address from SMTP.

To read more about the WSDL specification, look on the W3C web site at www.w3.org/TR/WSDL/.

DISCO: A Way to Discover Services Located on a Particular Web Site

XML web service discovery is the process of locating, or discovering, one or more related documents that describe a particular XML web service using WSDL. Through the discovery process, XML web service clients learn that an XML web service exists and identify where to find the service's description document. A published Discovery Protocol (DISCO) file, which is an XML document that contains links to other resources that describe the XML web service, enables programmatic discovery of an XML web service.

Listing 4.2 shows the structure of a discovery document for a Task Tracker web service:

Listing 4.2. Example DISCOvery Document

 <?xml version="1.0" encoding="utf-8"?>   <discovery   xmlns:xsd="http://www.w3.org/2001/XMLSchema"     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"     xmlns="http://schemas.xmlsoap.org/disco/">     <contractRef ref="http://www.infostrat.com/TaskTracker/ _     svc Task.asmx?wsdl"       docRef="http://www.infostrat.com/TaskTracker/svcTask.asmx"       xmlns="http://schemas.xmlsoap.org/disco/scl/" />      <soap       address="http:// www.infostrat.com /TaskTracker/ _      svcTask.asmx"       xmlns:q1="http://tempuri.org/"       binding="q1:svcTaskSoap"       xmlns="http://schemas.xmlsoap.org/disco/soap/" />     </discovery> 

The document shown in this listing is basically a container for elements that contain links (URLs) to the resources that provide discovery information for a web service. It is good practice to fully qualify the URLs; but if the specified URLs are relative, they are assumed to be relative to the location of the discovery document.

A web site that implements a web service does not need to support discovery. The discovery and description of the web service can be implemented on an alternative web site such as a web service directory. On the other hand, a web service may not have any means of being discovered, such as when the implementation is intended for private use.

A Way to Discover Service Providers

Like companies that consume commercial services, consumers of web services need to know about a service. As with any other resource on the Internet, these consumers would not be able to find a particular web service without some means of searching for it. The DISCO specification defines a discovery document format based on XML and a protocol for retrieving the discovery document, enabling developers to discover services at a known URL.

However, in many cases, developers who need to consume the web service in their code, do not know the URLs at which services can be found. Web services directories provide central locations at which web service providers can publish information about their available services. Such directories can even be web services themselves , accessible programmatically and providing search results in response to queries from potential web service clients. It might be necessary to use a web services directory to locate an organization that provides a web service for a particular purpose, or to determine what web services that particular organizations provide. The Universal Description, Discovery, and Integration (UDDI) specifications define an advertising mechanism for web service providers and a location device for web service consumers. UDDI, in other words, serves as the yellow pages of web services.

UDDI defines how to register business data as well as how to advertise the existence and location of XML web services. Developers and users of web services typically interact with UDDI either by registering their web service or by looking for web services that serve particular needs. When using UDDI, you need to understand how to discover what you need.

The UDDI specifications define a standard way to publish and discover information about web services. The XML schemas associated with UDDI define four types of information that enable a developer to use a published XML web service. These are business information, service information, binding information, and information about specifications for services. A core component of the UDDI project, the UDDI Business Registry, allows businesses to programmatically locate information about XML web services exposed by other organizations. Developers can use the UDDI Business Registry to locate discovery documents and service descriptions.

To read more on UDDI, look on the Organization for the Advancement of Structured Information Standards (OASIS) web site at www.UDDI.org/ or on Microsoft's site at UDDI.microsoft.com/.