The WS-I Deliverables

Microsoft Corporation
August 2003

Summary: Get to know the four deliverables produced by the WS-I for the Basic Profile version 1.0. (11 printed pages)

Contents

Introduction
The Basic Profile
Basic Profile Usage Scenarios
The WS-I Basic Profile Sample Application
The WS-I Basic Profile Test Tools
More Information

Introduction

This chapter describes the four deliverables produced by the WS-I for the Basic Profile version 1.0. Briefly, they are:

• The Basic Profile, which contains requirements and guidelines for writing interoperable Web services.
• The Basic Profile usage scenarios, which describe fundamental ways that providers and consumers interact.
• The sample application, which is an implementation of an interoperable Web service that demonstrates the requirements and guidelines presented in the Basic Profile.
• The testing tools, which help developers verify that their Web service implementations conform to the requirements in the Basic Profile.

We shall discuss each of these deliverables in more detail in the following sections. The WS-I Basic Profile, sample application, and test tools are available at http://www.ws-i.org.

The Basic Profile

The Basic Profile consists of a set of constraints and guidelines that, if followed, will help developers write interoperable Web services. Together, these guidelines and constraints represent the WS-I's approach toward interoperability. This approach is based on some underlying principles, which we will discuss in this section.

Scope of the Profile

The scope of the profile is defined by a group of specifications at particular version levels. Currently, the profile's scope includes the following specifications:

• Simple Object Access Protocol (SOAP) 1.1
• Extensible Markup Language (XML) 1.0 (Second Edition)
• RFC2616: Hypertext Transfer Protocol —HTTP/1.1
• RFC2965: HTTP State Management Mechanism
• Web Services Description Language (WSDL) 1.1
• XML Schema Part 1: Structures
• XML Schema Part 2: Datatypes
• UDDI Version 2.04 API Specification, Dated 19 July 2002
• UDDI Version 2.03 Data Structure Reference, Dated 19 July 2002
• UDDI Version 2 XML Schema
• RFC2818: HTTP Over TLS
• RFC2246: The TLS Protocol Version 1.0
• The SSL Protocol Version 3.0
• RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile

Specifications often provide ways of extending the components they describe to increase their capabilities. For example, the SOAP 1.1 specification states that typical examples of extensions that can be implemented as header entries are authentication, transaction management, and payment methods. These extensions allow vendors to introduce products that are both uniquely their own and that still interoperate with other Web services. To promote this flexibility, the Basic Profile never imposes limitations on the range of these extensions. For a complete list of the profile's extensibility points, see Appendix II of the Basic Profile.

Level of Granularity

The profile addresses interoperability at the application layer and relies on well-understood lower-layer protocols such as TCP/IP, and Ethernet. It assumes that protocols such as SSL/TLS and HTTP are also well understood and only mentions them specifically when there is an issue that affects Web services. It is important to note that WS-I does not address all issues, but only those that are related to interoperability of Web services.

Profile Conformance

Conformance to the profile means adherence to specifications that comprise the profile's scope and to the profile's requirements. Requirements are the rules that any Web service must adhere to in order to meet the profile's standards for interoperability. Each requirement is individually identified by the letter "R" and a number, such as R1000.

There are two types of conformance. The most basic type is conformance at the level of an artifact. Artifacts are the primary elements of any Web service. The profile has rules about three types of artifacts:

• Messages, which are protocol elements that are exchanged (usually over a network) to effect a Web service (for example, SOAP/HTTP messages). The scope of conformance is the entire message.
• Descriptions, which are descriptions of types, messages, interfaces and their concrete protocol and data format bindings, and the network access points associated with Web services (for example, WSDL descriptions). The scope of conformance is wsdl:port, or parts of a port.
• REGDATA, which are statements about Web services that are used to discover their capabilities (for example, UDDI tModels). The scope of conformance is bindingTemplate or tModels.

An artifact is conformant when all of the profile's requirements associated with that artifact type are met.

A second, higher-level of conformance, is called conformance of services and consumers. This occurs when a Web service both produces and consumes only conformant artifacts. If multiple types of a particular artifact are possible, a conformant service must be able to consume them all. For example, while a sender may encode XML in UTF-8 or UTF-16 when sending a message, a receiver must be capable of using either one.

Where possible, the profile places requirements on artifacts (for example, WSDL descriptions and SOAP messages) rather than on the producing or consuming software's behaviors or roles. Artifacts are concrete, making them easier to verify and therefore making conformance easier to understand and less error-prone.

Strength of Requirements

The profile makes strong requirements (for example, MUST, and MUST NOT) wherever possible. If there are times when a strong requirement cannot be met, conditional requirements (for example, SHOULD, and SHOULD NOT) are used. If the requirements are going to be amended, they may become more restrictive but they will not become looser. For example, the profile will not change a MUST to a MAY.

Testability

When possible, the profile makes statements that are testable but testability is not a requirement for a statement. The profile suggests that, preferably, testing should be performed in non-intrusive ways such as examining artifacts "on the wire." An example of this is the monitor, which is a test tool provided by the WS-I. It is described later in this chapter.

Multiple Mechanisms

If one of the profile's specifications allows a variety of mechanisms to be used interchangeably, the profile uses the ones that are best understood and most widely implemented. This is because underspecified or little-known mechanisms and extensions can introduce complexity and, therefore, may reduce interoperability.

Compatibility

Although backward compatibility isn't an explicit goal of the Basic Profile, it tries to avoid introducing changes to the requirements of a specification unless doing so addresses specific interoperability issues. Also, where possible, the profile's requirements are compatible with in-progress revisions to the specifications it references (for example, SOAP 1.2 or WSDL 1.2).

Application Semantics

Application semantics basically lie outside of the profile. By application semantics we mean definitions of what an application does. For example, an airlines reservations Web service will have the format of a message request defined, but whether that message charges a credit card or sends tickets through the mail isn't specified.

Basic Profile Usage Scenarios

The Basic Profile usage scenarios define how Web services are used in specific types of interactions between a consumer and a provider. They identify the basic interoperability requirements for these interactions and map them to the requirements of the Basic Profile.

The scenarios reflect fundamental, real-world Web service requirements. They can be combined and built upon like building blocks. For example, the Synchronous Request/Response scenario describes a basic exchange that can be expanded by adding SOAP headers. The only requirement is that the extensions must also conform to the Basic Profile.

The WS-I has defined three usage scenarios to complement the Basic Profile:

• One-way usage scenario
• Synchronous request/response usage scenario
• Basic callback usage scenario

One-way Usage Scenario

In the one-way usage scenario, a consumer sends a message to a provider. The provider receives the message and processes it but doesn't generate a response in return. The following diagram illustrates this case:

Figure 2.1 One-way usage scenario

At the highest level, the flow can be broken down into 2 steps:

1. The consumer invokes the service by sending a SOAP message bound to an HTTP request to the provider.
2. The provider executes the service.

Synchronous Request/Response Scenario

In the synchronous request/response usage scenario, the consumer first sends a message to the provider. The provider processes it and simultaneously sends back a response. The following diagram illustrates this case:

Figure 2.2 Synchronous request/response scenario

At the highest level, the flow can be broken down into 2 steps:

1. The consumer invokes the service by sending a SOAP message bound to an HTTP request to the provider.
2. The provider executes the service and sends a SOAP message bound to an HTTP response to the consumer.

Basic Callback

The basic callback usage scenario employs a type of asynchronous message exchange for Web services using two synchronous request/response pairs (see the previous section for more information). Since both the consumer and the provider may have other outstanding requests, the consumer adds some type of data, such as a purchase order number, that the provider can use to associate the correct response with the correct request. An alternative approach is to use some form of message ID. In addition, the consumer also supplies the provider with the endpoint information for the callback service. This service is defined by the provider in the published Web service description and is implemented by the consumer. The following diagram illustrates this case:

Figure 2.3 Basic callback

At the highest level, the flow can be broken down into 4 steps:

1. The consumer initiates the service by sending a SOAP message bound to an HTTP request to the provider. This is the initial request.
2. The provider acknowledges receipt by sending a SOAP message bound to an HTTP response to the consumer. This is the initial response.
3. The provider completes the exchange by sending a SOAP message bound to an HTTP request to the consumer with the results of the initial request. This is the final request, or callback.
4. The consumer acknowledges receipt of the callback message with a SOAP message bound to an HTTP response. This is the final response.

Note For more information on these usage scenarios, including detailed flows, see the WS-I Usage Scenarios paper available at http://www.ws-i.org/.

The WS-I Basic Profile Sample Application

In addition to the Basic Profile, the WS-I has also created a Basic Profile sample application. The sample application demonstrates all of the scenarios in the Basic Profile as well as providing an example of how the Basic Profile allows Web services from different vendors to interoperate.

The WS-I Basic Profile sample application is a supply-chain management application that models a retailer selling electronics. The retailer has three warehouses and sells goods from three manufacturers. When using the sample application, a user can select different vendor implementations for each of the warehouses and manufacturers to observe how the Basic Profile allows Web services to interoperate. In addition, there is a logging facility so that the activity generated by the Web services can be logged.

For more information on the WS-I Basic Profile sample application, see the WS-I Supply Chain Management Use Cases and Supply Chain Management Sample Architecture papers available at http://www.ws-i.org as well as the Microsoft sample application available at http://ws-i.gotdotnet.com/wsi/webclient/.

The WS-I Basic Profile Test Tools

The WS-I has developed two test tools, a monitor and an analyzer, that are used in conjunction with each other for evaluating whether or not a Web service follows the Basic Profile guidelines. Both C# and Java versions of the tools are available. Briefly, the tools do the following:

• The monitor captures and logs the messages between a Web service and a consumer.
• The analyzer examines the messages logged by the monitor and analyzes them as to whether or not a Web service follows the Basic Profile guidelines.

The following diagram shows the relationship between the monitor and the analyzer:

Figure 2.4 The WSI test tools

The Monitor

The monitor uses a man in the middle approach, meaning it sits between the consumer and the Web service, intercepting all the SOAP/HTTP messages they exchange. The messages are stored in a log file for later use by the analyzer. The following diagram describes them monitor:

Figure 2.5 The monitor

The monitor configuration file is an XML document that controls the operation of the monitor and defines the parameters that ensure that the SOAP messages are properly routed.

Note For more information on the contents of the monitor configuration file, see the Test Tools User guide available at http://www.ws-i.org/.

The Analyzer

The analyzer uses the monitor's log files as input and analyzes the following items:

• Descriptions, which are WSDL data.
• Messages, which are HTTP message items from the XML message log file.
• Discovery data, which is comprised of the UDDI entries.

The following diagram illustrates how the analyzer works:

Figure 2.6 The analyzer

Similarly to the monitor, the analyzer also has a configuration file that contains the list of options for the tool as well as possibly containing implementation-specific configuration parameters.

The analyzer also uses the test assertion document. This document encodes the Basic Profile's rules. The analyzer compares the Web service under test to the requirements in the test assertion document to see if the Web service complies with the Basic Profile's rules.

Note For more information on the analyzer files, see the Test Tools User guide available at http://www.ws-i.org/.

Once it has completed analyzing the log files, the analyzer issues a conformance report. The overall result of the report will be that the implementation either passed or failed. It is important to remember that, because the test tools only examine the messages between a web service and a requestor, they do not test all requirements of the Basic Profile. This is why the tools are said to evaluate conformance and not certify a Web service. For more information on the WS-I Basic Profile test tools, see the user's guide available at http://www.ws-i.org.

More Information

The WS-I Basic Profile, sample application, and test tools.