The WS-I Usage Scenarios draft document has gone through several cycles of review within the organization, and as such is considered to be quite stable by its authors, the members of the Scenarios & Sample Applications Working Group. However, further revision is possible as the document completes the review process as prescribed by the WS-I organization's charter and by-laws.

About the WS-I

The Web Services Interoperability Organization is a consortium of about 150 companies, at the time of this writing, representing a wide range of industries including automotive, consumer packaged goods, finance, government, insurance, media, telecommunications, travel, and of course, the computer industry. WS-I is focused on promoting the interoperability of web services applications across different computing environments and programming languages. It does so by providing advice, best practices, and other resources intended to assist developers of web services applications. More specifically, WS-I intends to develop what it refers to as profiles of interoperable web services. The WS-I Glossary defines a "profile" as follows:

Profile: A collection of requirements to support interoperability. WS-I will deliver a collection of profiles that support technical requirements and specifications to achieve interoperable Web Services.

The first of these profiles, currently still under development, is referred to as WS-Basic Profile 1.0. It is focused on the core foundational technologies upon which web services are based: HTTP, SOAP, WSDL, UDDI, XML, and XML Schema. WS-Basic Profile 1.0 will provide interoperability at the basic connectivity level. Once complete, WS-Basic Profile 1.0 will include the following items:

• Profile specification: The actual specification of the profile includes a list of non-proprietary web services related specifications at certain version levels, plus a list of clarifications and restrictions on those specifications. These clarifications and restrictions are intended to facilitate the development of interoperable web services.
• Usage scenarios: The usage scenarios that will be provided in conjunction with WS-Basic Profile 1.0 can be thought of as the technical requirements for using web services in a profile-conformant manner. This does not imply that using web services in different ways is not conformant with the profile. It simply means that following the guidelines of WS-I usage scenarios is one way to ensure profile conformance.
• Sample application(s): In order to demonstrate to web services developers how to use WS-Basic Profile 1.0 to develop interoperable web services, WS-I chartered a working group to create a sample application. The sample application will portray a supply chain management application for a fictitious consumer electronics retailer.
• Testing tools: In addition to all of the above, WS-I will provide reference implementations of test tools that can be used by developers to test web services for profile conformance. One tool will monitor all interactions between a web service and its client, logging the information it captures to a file. A second tool analyzes the generated log file to determine if the messages exchanged, as well as other artifacts of the web service (its WSDL and UDDI registration), conform to the guidelines specified in the profile.

Back to top

WS-I Usage Scenarios

The WS-I Usage Scenarios document defines the following three usage scenarios which have been developed by the Scenarios & Sample Applications Working Group for use with the Basic Profile:

• One-way.
• Synchronous request/response.
• Basic callback.

But what exactly is a "usage scenario," anyway? The WS-I Glossary defines it as follows:

Usage Scenario: A generic description of interacting entities including actors, roles, and message exchange patterns. Also called Design Patterns.

So, within WS-I, "usage scenario" is used to mean a low-level, generic pattern of using web services. These patterns are described by actors, activities and message exchange patterns. They are low-level in the sense that they can be extended or composed with other usage scenarios to create new, more sophisticated usage scenarios. They are generic, in the sense that they are applicable to any application domain. Before I go into a detailed description of each of these usage scenarios, it is important to establish another pair of terms that are used extensively throughout the WS-I Usage Scenarios document:

Consumer: A Consumer is responsible for making requests of a service implemented by a Provider.
Provider: A Provider is responsible for listening for and processing Consumer service requests.

Together, these terms are referred to as web service actors. Note that the term consumer in this context is analogous to the same term in economics, that is, a consumer uses goods and/or services provided by a producer or service provider. This is not to be confused with the fact that when a web service receives a request, it is said to be "consuming" a message from it's client. I point this out because it has caused confusion for some.

The One-way Usage Scenario

The simplest usage scenario defined by WS-I is called One-way. In this usage scenario, a Consumer sends a request message to a Provider. The Provider receives the message, and processes it. The sequence of events in this usage scenario is illustrated in Figure 1. As the name of the usage scenario suggests, the message exchange is one-way. In particular, what this means is that a SOAP response message is neither generated by the Provider nor expected by the Consumer. However, the transfer/transport layer (for example, HTTP) may send a response back to the Consumer.

Since WS-Basic Profile 1.0 requires use of the SOAP HTTP binding, I will limit discussion to the HTTP transfer protocol. Because the HTTP transfer layer does not guarantee delivery of the message, the Consumer has no way of knowing for certain whether the message was in fact received by the Provider. As such, this usage scenario should only be applied in situations where loss of information can be tolerated. While this obviously limits the usefulness of this usage scenario, there are situations for which it is quite well suited, for example, an application event log. In fact, this is exactly how the Basic Profile sample application will illustrate the applicability of this usage scenario.

The Synchronous request/response Usage Scenario

Arguably the most commonly used of the WS-I usage scenarios is the one referred to as Synchronous request/response. In this usage scenario, a Consumer sends a request message to a Provider. The Provider receives the message, processes it, and sends back a response. This sequence of events is illustrated in Figure 2.

This usage scenario describes distributed computing in general, and is applicable any time the client (Consumer) of some computing service is separated by a network from the server (Provider). You will see that this usage scenario forms the basis of the interaction between the retailer and its warehouses in the Basic Profile sample application.

The Basic callback Usage Scenario

The third and final WS-I usage scenario is called Basic callback. The purpose of this usage scenario is to simulate an asynchronous operation using synchronous operations. This is done by composing a pair of Synchronous request/response usage scenarios, one from the Consumer to the Provider, and one from the Provider back to the Consumer. The request/response from the Consumer to the Provider is referred to as the initial request/response. The request/response from the Provider back to the Consumer is referred to as the final request/response. This interaction is illustrated in Figure 3.

The Consumer may send more than one initial request/response to the Provider before receiving a final request/response. In order to allow the Consumer to know which initial request/response a final request/response refers to, some correlation mechanism must be used. This can be done by the Consumer placing either some sort of message ID or some unique piece of application data (for example, an order number) either in the body or in the SOAP Header of the initial request/response. When the Provider has (asynchronously) processed the initial request/response from the Consumer, it returns (that is, calls back) to the Consumer with a SOAP message, placing the correlating piece of data originally received from the Consumer either in the body or in the SOAP Header. The correlation data tells the Consumer which piece of asynchronous work has been completed by the Provider.

While the Consumer has presumably discovered the Provider's endpoint using UDDI, the same mechanism may not necessarily be appropriate for the Provider to know where the Consumer's callback web service endpoint is located. An alternative mechanism described in the Basic callback usage scenario is for the Consumer to provide the URL of the call back web service to the Provider at runtime in the SOAP message associated with the initial request/response.

The WS-I Basic callback usage scenario is one way in which asynchronous messaging can be accomplished with web services. For a good discussion of alternative approaches, please refer to the article by Holt Adams Asynchronous operations and web services, Part 2 (see Resources).

Back to top

The Relationship to the WS-I Basic Profile

At this point you might be asking yourself: How does all this relate to the Basic Profile? Well, one of the tasks of the WS-I Usage Scenarios document is to provide a mapping from the above usage scenarios, which are clearly described in such a way as to be relevant to web services developers, to the clarifications and restrictions in the profile specification, which is more targeted to those who develop web services run-time and development environments.

In order to describe how this mapping is done, you first need to establish a context for that discussion. No discussion of web services (or any technology, for that matter) would be complete without a "stack" diagram. These are usually drawn as a bunch of boxes all stacked on top of each other, or placed next to one another. Most people have probably seen a diagram of the web services stack that looks something like the following one:

This is a fairly common view of the web services stack from a perspective of the protocols which define the technology. However, the WS-I Scenarios & Sample Applications Working Group has developed a different view, one that is based on the usage of web services, as follows:

The WS-I Usage Scenarios document describes the layers as follows:

• Data Layer: The data layer translates the application specific data into the model chosen for the specific web service. The data layer includes the functions necessary to support flexible data typing. This layer maps to the <wsdl:types> and <wsdl:message> definitions within a WSDL document.
• SOAP Message Layer: The SOAP message layer is the infrastructure that processes SOAP messages, dispatches them, and may optionally fulfill Quality of Service requirements. On the sending side the message layer writes SOAP messages, based on the data model defined in portTypes and bindings. On the receiving side the message layer processes the SOAP messages and dispatches requests to the correct application or method.
• Transport Layer: The transport layer sends and receives messages. For the Basic Profile, this includes only HTTP client and server platforms. This layer maps to the <wsdl:binding> and <wsdl:port> definitions with the WSDL document.

Within each of these layers there is a well-defined set of activities that must be performed. These are shown in Table 1 and are more or less self-explanatory.

The web services (usage) stack and the activities defined for each layer provide the context for mapping WS-I usage scenarios to the profile. The mapping is achieved by applying constraints (as described in the profile specification), to the activities that must be performed within each layer of the web services (usage) stack. These are referred to as flow constraints since they apply to each activity in the flow of processing which occurs when using web services. As an example, the One-way usage scenario defines the following flow constraint in the WS-I Usage Scenario document:

Send HTTP, as defined in Section 5.9. Further constraint specific to this scenario is R2714.

Section 5 is "Appendix 2 - Constraints". Section 5.9 is "Send HTTP", and it states the following:

The following constraints apply to both HTTP and HTTPS:

General: R1108, R1140
Status code: R1106, R1107, R1111, R1112, R1113, R1114, R1115, R1116
SOAPAction Header: R1109
Cookies: R1120, R1121, R1122

The above is a list of requirements specified by WS-Basic Profile 1.0. Cross-referencing the WS-I Usage Scenario document with the WS-I Basic Profile version 1.0 specification using the requirement numbers is an easy way for web services developers to focus on the profile requirements associated with the implementation of a particular usage scenario.

There are also description constraints that apply to the task of describing a web service using WSDL (and possibly UDDI). These constraints specify what the WSDL should look like for a given usage scenario. For example, in the One-way section of the WS-I Usage Scenario document, there is a description constraint which states that the <wsdl:binding> section must use the SOAP binding extension with HTTP transport as follows:

<wsdl:binding ...>
	<soap:binding style="rpc|document" transport=http://schemas.xmlsoap.org/soap/http>
		<wsdl:input ...>
		</wsdl:input>
	</soap:binding>
</wsdl:binding>

Similarly, in the Synchronous request/response section of the WS-I Usage Scenario document the exact same description constraint appears as follows:

<wsdl:binding ...>
	<soap:binding style="rpc|document" transport=http://schemas.xmlsoap.org/soap/http>
		<wsdl:input ...>
		</wsdl:input>
		<wsdl:output ...>
		</wsdl:output>
	</soap:binding>
</wsdl:binding>

The difference, of course, being that in the One-way usage scenario a SOAP response (that is, output) is neither generated by the Provider nor expected by the Consumer.

Finally, in addition to the flow constraints and description constraints mentioned above, each usage scenario includes a description of constraints associated with advertising a web service via UDDI, as well as security threats and countermeasures associated with using web services. You have already seen that in the Basic callback usage scenario, typically only the web service associated with the initial request/response is advertised in UDDI in the normal manner as described in the Using WSDL in a UDDI Registry, Version 1.07 Best Practice document (see Resources). The web service associated with the final request/response is not typically advertised. As for security, currently there are no security threats specific to any of the three usage scenarios. The common web services security threats and countermeasures are described in Appendix 1 of the WS-I Usage Scenarios document.

Back to top

Conclusion

The Web Services Interoperability Organization is focused on providing interoperability between implementations of web services regardless of the language they were written in and the platform they are deployed on. To that end, WS-I defines profiles of interoperable web services, the first of which is the WS-Basic Profile 1.0. The WS-I Usage Scenarios document is an excellent companion to the profile specification, one that is written more from the perspective of the developers and users of web services. Finally, WS-I will also provide sample applications and test tools, which will be the topics of future articles.

So, how can a developer of a web services application best use the resources provided by WS-I to ensure interoperability? This is a question that clearly has no single answer. One recommendation would be to start by mapping the design of an application to the usage scenarios described in the WS-I Usage Scenarios document, that is, identify which of the application's web services would be implemented using the One-way, Synchronous request/response and Basic callback scenarios. Then, use the WS-I Usage Scenarios document to cross-reference the WS-I Basic Profile version 1.0 specification for interoperability implementation requirements. During the implementation of the application, it may be helpful to take a look at the WS-I Basic Profile sample application code and to run the associated demo. And of course, once the application is ready for testing, use the reference implementations of the WS-I test tools to verify that the application's web services conform to the WS-Basic Profile 1.0.

It is entirely possible that there will be web services in an application that cannot be implemented by using just the three current WS-I usage scenarios. If so, then the entire WS-I Basic Profile version 1.0 specification will have to be examined for implementation guidance. In the event that an application's web services cannot be mapped to the three usage scenarios described above, the WS-I organization would be very interested in learning more about the application. Perhaps the current set of usage scenarios needs to be extended with new scenarios. Or, perhaps the WS-Basic Profile 1.0 is not sufficient to address the needs of the application and new profiles need to be developed by WS-I. In any case, the WS-I organization values the input of not just its member organizations, but any developers of web services who are concerned about interoperability.

Resources

• The Web Services Interoperability Organization defines profiles for interoperability between web services.
  
  
• A First look at the WS-I Basic Profile 1.0 by Chris Ferris summarizes the details of the first release of this profile. The full WS-I Basic Profile 1.0 is also available directly from the WS-I site.
  
  
• The WS-I Usage Scenarios document is available from the WS-I site.
  
  
• Asynchronous operations and web services, part 2 by Holt Adams explains alternative approaches to asynchronous communications between services.
  
  
• Using WSDL in a UDDI Registry Version 1.07 is a best practices document published by UDDI.org.
  
  
• If you are interested in getting involved in the WS-I's activities, you should contact the organization directly.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• About the WS-I
• WS-I Usage Scenarios
• The Relationship to the WS-I Basic Profile
• Conclusion
• Resources
• About the author
• Comments

Next steps from IBM

WebSphere Application Server can leverage its built in Web Services support to expose services to remote consumers in an industry-standard way.

---

• Try: The no-charge WebSphere Application Server Community Edition is a pre-integrated, lightweight Java 5 application server built on Apache Tomcat and includes built in Web Services support.
• Article: Learn how to use of the JAX-WS programming model to create dispatch and dynamic proxy clients and how to create an asynchronous Web service client.
• Tutorial: This tutorial takes you through the steps to deploy Data Web Services to the WebSphere Application Server Community Edition.
• Demo: This demo shows how to extract and install the IBM Java Platform, Java EE 5 SDK with WebSphere Application Server.
• Buy: WebSphere Application Server - Express

Dig deeper into SOA and Web services on developerWorks

Discover knowledge paths

Skill-building guides for Linux, open source, cloud, Java, business analytics, and more.

Special offers