On October 17, 2002, WS-I, the Web Services Interoperability Organization, released its first public Working Group Draft of the WS-I Basic Profile version 1.0 specification. This publication represents an important milestone for WS-I and the Basic Profile Working Group, one of the three initial WS-I technical Working Groups chartered with deliverables associated with the WS-I Basic Profile version 1.0. This draft document, while not complete, does represent the consensus of the members of the WS-I Basic Profile Working Group. It is expected that the document will undergo further change to incorporate more examples and more detailed rationalization for the constraints and requirements imposed by the profile.

About the WS-I

The Web Services Interoperability Organization is an open industry effort chartered to promote web services interoperability across platforms, applications, and programming languages. The organization brings together a diverse community of web services leaders to respond to customer needs by providing guidance, recommended practices, and supporting resources for developing interoperable web services.

Back to top

WS-I deliverables

This draft publication is the first of a set of related material being produced by WS-I related to the Basic Profile. When complete, the package of deliverables produced in conjunction with the WS-I Basic Profile will be as follows:

• Use cases and usage scenarios: Use cases and usage scenarios capture (respectively) business and technical requirements for the use of web services. These requirements reflect the classes of real-world requirements supporting web services solutions, and provide a framework to demonstrate the guidelines described in WS-I Profiles.
• Profiles: Profiles are comprised of a set of named and versioned web services specifications together with a set of implementation and interoperability guidelines recommending how the specifications may be used to develop interoperable web services.
• Sample applications: Sample applications demonstrate the implementation of applications that are built from web services usage scenarios and use cases, and that conform to a given set of profiles. Implementations of the same Sample Application on multiple platforms, languages, and development tools demonstrate interoperability in action, and provide readily usable resources for the web services practitioner.
• Testing tools: Testing tools are used to monitor and analyze interactions with a web service to determine whether or not the messages exchanged conform to WS-I Profile guidelines.

The WS-I process begins with the definition of use cases that describe how web services can be applied to meet real-world business needs. These use cases are then decomposed into usage scenarios supporting various aspects of the use cases and design patterns. The usage scenarios describe the ways in which web services are employed in the context of the collected use cases. This work aids in the demonstration of how web services specifications are used individually, in concert with one another, or both.

Use case analysis forms the foundation for profile requirements to be defined. Each profile is based on a specific set of web services specifications, each at a particular version and revision level. Profiles provide a refined usage of these specifications and standards through implementation and interoperability guidelines, which, in many cases, are captured as a set of test assertions that can be used to verify a given web service implementation's conformance with the profile.

WS-I then develops specifications for, and implements, sample applications. The supporting implementations are developed in multiple programming languages, such as C# (C sharp) and Java programming language, and are deployed on multiple platforms, including Java 2 Platform, Enterprise Edition (J2EE) and .NET. This activity illustrates profile interoperability by developing solutions to the use cases and usage scenarios that the profiles are intended to address.

Finally, to close the loop, WS-I is developing testing tools for use by web services practitioners, including those members of the WS-I Working Groups developing sample applications. These tools are used to verify that the interactions observed with the monitored web service conform to the set of guidelines and test assertions that define the interoperability profiles.

Back to top

WS-I Basic Profile 1.0

The WS-I Basic Profile specification defines conformance of a web service instance. The profile consists of the following set of non-proprietary web services specifications:

• SOAP 1.1
• WSDL 1.1
• UDDI 2.0
• XML 1.0 (Second Edition)
• XML Schema Part 1: Structures
• XML Schema Part 2: Datatypes
• RFC2246: The Transport Layer Security Protocol Version 1.0
• RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile
• RFC2616: HyperText Transfer Protocol 1.1
• RFC2818: HTTP over TLS
• RFC2965: HTTP State Management Mechanism
• The Secure Sockets Layer Protocol Version 3.0

The profile provides constraints and clarifications to those base specifications with the intent to promote interoperability. Where the profile is silent, the base specifications are normative. If the profile prescribes a requirement or constraint, it supersedes the underlying base specification. Some of the constraints imposed by the profile are intended to restrict, or require, optional behavior and functionality, so as to reduce the potential for interoperability problems. Some of the constraints or requirements are provided to clarify language in the base specification that may be the source of frequent misinterpretation, that have been a frequent source of interoperability problems.

The following highlights of the key constraints imposed by the profile:

• precludes the use of SOAP encoding
• requires the use of HTTP binding for SOAP
• requires the use of HTTP 500 status response for SOAP Fault messages
• requires the use of HTTP POST method
• requires the use of WSDL1.1 to describe the interface of a web service
• requires the use of rpc/literal or document/literal forms of the WSDL SOAP binding
• precludes the use of solicit-response and notification style operations
• requires the use of WSDL SOAP binding extension with HTTP as the required transport
• requires the use of WSDL1.1 descriptions for UDDI tModel elements representing a web service

Back to top

What's relevant to the developer?

The WS-I Basic Profile 1.0 specification is a rather complex document. You might ask; "I develop web services for a living, what relevance has this specification to my work? Do I need to read, and understand all of this material?".

A majority of the specification is targeted at the audience of platform infrastructure and tools developers working on vendor-specific implementations of SOAP processors, WSDL parsers, code generators, and the like. The specification represents the consensus agreement of the members of the Basic Profile Working Group. Since the WG members include people (such as me) who represent platform and/or tool vendors, you could reasonably look at this document as a concerted effort by those tools and platform vendors to ensure that their respective products will either generate, or host interoperable web services instances. This means that while you'll probably want to be familiar with all of the profile specification's contents there are specific sections you will need to pay close attention to as you implement web services.

We will examine each substantive section of the profile specification and discuss its relevance to a web service practitioner.

Section 4 of the WS-I Basic Profile specification relates to SOAP and use of HTTP binding for SOAP. As such, it is mostly of interest to those developers writing SOAP processor implementations rather than web services developers.

Section 5 pertains to conformant use of WSDL, and as such should be of interest to web services practitioners, especially those who hand-craft their WSDL descriptions. We will explore some of this section's particularly interesting aspects below.

Section 6 pertains to web service discovery using UDDI. This, too, should be of interest to web services practitioners. It describes conformant approaches to registration and categorization of a web service in a UDDI registry.

Section 7 relates to security of web services using HTTP/S and should also be of interest to web services practitioners who require security for the web services they develop.

Back to top

Writing WS-I-conformant WSDL

As previously discussed, section 5 of the WS-I Basic Profile 1.0 specification relates to conformant use of WSDL to describe a web service. Of all the sections in the profile specification, it is probably of most interest and importance to web services developers. It begins by addressing issues related to WSDL document structure and composition.

The first issue addressed is that of correct usage of the wsdl:import feature. The wsdl:import feature is intended to be used in the same manner as the xsd:import feature, to import definitions from a foreign namespace. e.g. a namespace that is not the same as the value of the targetNamespace attribute of the importing WSDL document. Additionally, the WS-I Basic Profile constrains use of the <wsdl:import> feature to the import of WSDL definition components from another WSDL document. This means that you cannot use the <wsdl:import> feature to import schema definitions from an XSD file.

Listings 1 - 3 show some examples that demonstrate both incorrect and correct usage of the <wsdl:import> feature.

	

<definitions name="StockQuote"  
	 targetNamespace="http://example.com/stockquote/wsdl"
   	xmlns:sq="http://example.com/stockquote/sqTypes/" 
   	          	 ...
      xmlns="http://schemas.xmlsoap.org/wsdl/">   
      <import namespace="http://example.com/stockquote/sqTypes/"
               location="http://example.com/stockquote/sqTypes.xsd"/>            
               
      <message name="GetLastTradePriceInput">        
              <part name="body" element="sq:TradePriceRequest"/>    
      </message>
                     ...
</definitions> 

	

<definitions name="StockQuote"    
	 targetNamespace="http://example.com/stockquote/wsdl"   
	 xmlns:sq="http://example.com/stockquote/sqTypes/"           	 
	 	...   
	 xmlns="http://schemas.xmlsoap.org/wsdl/">      

	 <types>     
	 	<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">      
	 		<xsd:import namespace="http://example.com/stockquote/sqTypes/"          
	 			schemaLocation="http://example.com/stockquote/sqTypes.xsd"/>     
	 		</xsd:schema>   
	 </types>   
	 <message name="GetLastTradePriceInput">      
	 	<part name="body" element="sq:TradePriceRequest"/>   
	 </message>               
	 		...
</definitions> 

	
	

<definitions name="StockQuote"     
	targetNamespace="http://example.com/stockquote/service/"   
	xmlns:sq="http://example.com/stockquote/sqDefs/"   
	xmlns:tns="http://example.com/stockquote/service/"   
	xmlns="http://schemas.xmlsoap.org/wsdl/">      
	
	<import namespace="http://example.com/stockquote/sqDefs/"        
		location="http://example.com/stockquote/stockquote.wsdl"/>  
		
	<service name="StockQuoteService">      
		<port name="StockQuotePort" binding="sq:StockQuoteSoap">           
			....      
		</port>  
	</service>
</definitions> 

As we see in the first example, the wsdl:import statement is being used incorrectly to import schema definitions from an XSD file:

http://example.com/stockquote/sqTypes.xsd

Listing 2 and 3 demonstrate the correct usage of the wsdl:import and xsd:import features.

The profile also constrains the order in which the top-level WSDL elements are to be used. Specifically, it requires that the wsdl:import element, if present, precede all other top-level WSDL elements. It is then followed by the <wsdl:types> element, and then <wsdl:message>, <wsdl:portType>, <wsdl:binding> and <wsdl:service> elements which may appear as many times as needed, and in any order.

This constraint, like many others in the specification, is based on decisions made by the W3C Working Group defining the next version of the web services specifications for SOAP and WSDL. The reason that the Basic Profile WG has adopted certain decisions made by the W3C WGs is that they wanted to resolve identified interoperability issues in a manner consistent with the direction of the W3C WG drafting the 1.2 versions of the SOAP and WSDL specifications. This approach is intended to facilitate a smoother transition to the next version of the specifications once they reach W3C Recommendation status and are incorporated into subsequent WS-I Profiles.

Listing 4 is an example of a correctly ordered WSDL document.

	

<definitions name="StockQuote"   
 	targetNamespace="http://example.com/stockquote/service/"   
 	xmlns:tns="http://example.com/stockquote/service/"   
 	xmlns:sqt="http://example.com/stockquote/sqTypes/"   
 	xmlns:sqd="http://example.com/stockquote/sqDefs/"   
 	xmlns="http://schemas.xmlsoap.org/wsdl/">     
 	
 	<import namespace="http://example.com/stockquote/sqDefs/"           
 		location="http://example.com/stockquote/stockquote.wsdl"/>     
 		
 	<types>    
 		<schema targetNamespace="http://example.com/stockquote/sqTypes/"         
 			xmlns="http://www.w3.org/2000/10/XMLSchema">           
 				.......    
 		</schema>   
 	</types>              
 	
 	<message name="GetLastTradePriceInput">      
 		<part name="body" element="sqt:TradePriceRequest"/>   
 	</message>               
 			...   
 			
 	<service name="StockQuoteService">      
 		<port name="StockQuotePort" binding="tns:StockQuoteSoap">           
 			....      
 		</port>   
 	</service>
</definitions>

Back to top

SOAP encoding nixed

As has already been discussed, the WS-I Basic Profile precludes the use of SOAP encoding, largely because it has proven to be a constant source of interoperability problems. The WS-I Basic Profile therefore requires use of either the RPC/literalor Document/literal forms of the WSDL SOAP binding. Considerable detail is provided in the specification describing correct use of the SOAP binding extension elements, to ensure consistent and interoperable description of the RPC/literal and Document/literal forms of the SOAP binding such that WSDL tools that generate code will be sure to be interoperable with regards to the SOAP messages produced and/or consumed.

While in this first public draft, section 5.8 of the specification is not presently accompanied with examples, expect the next revision to have lots of examples, so as to reinforce the constraints imposed in terms that can be readily understood by developers. Additionally, the WSDL produced as part of the sample applications that will be delivered with the Basic Profile will also provide developers with a solid set examples that demonstrate correct usage of the SOAP binding WSDL extension for RPC/literaland Document/literal SOAP binding descriptions.

Of course, WS-I intends that its testing tools, when they become available, be used by developers to test conformance of their WSDL documents with the profile rather than requiring them to manually vet their WSDL against the WS-I Basic Profile specification's constraint prose and/or examples.

Back to top

Scenarios, sample applications, and testing tools

The WS-I Basic Profile Working Group is not alone in making significant progress on its goals. The other two Working Groups have been hard at work developing their own deliverables, based on early drafts of the WS-I Basic Profile 1.0 specification. The Scenarios and Sample Applications working group has designed and is actively developing the sample application that will demonstrate the features of the WS-I Basic Profile.

The Testing Tools Working Group has made significant progress on their reference tools design and development and is translating the constraints and requirements defined in the WS-I Basic Profile draft into the test assertions that will configure the testing tools that web services practitioners can use to test their web service instances and WSDL descriptions for conformance with the profile.

Expect to see the fruits of these Working Group's respective efforts released to the public for review in the near future.

Back to top

Looking beyond the WS-I Basic Profile 1.0

The WS-I Basic Profile 1.0 is, of course, just the tip of the iceberg. WS-I plans to begin work on a number of profiles for web services specifications, moving further up the stack. Possible future profiles include the likes of security, choreography, reliable messaging, etc. Work will begin on these future profiles as the various specifications upon which they are to be founded mature and stabilize. WS-I intends that composed profiles may be created from these base profiles in order to combine features, such basic communications (as found in the Basic Profile), security, and reliable messaging to address business needs.

Resources

• The Web Services Interoperability Organization defines profiles for interoperability between implementations of the web services stack on different platforms.
  
  
• The WS-I Basic Profile version 1.0 specification is available on the WS-I site.
  
  
• The IBM WebSphere SDK for Web Services (WSDK) is available for free download through developerWorks.
  
  
• If you are interested in getting involved in the WS-I's activities, you should contact them directly.
  
  

About the author

Rate this article

Comments

Back to top

Table of contents

• About the WS-I
• WS-I deliverables
• WS-I Basic Profile 1.0
• What's relevant to the developer?
• Writing WS-I-conformant WSDL
• SOAP encoding nixed
• Scenarios, sample applications, and testing tools
• Looking beyond the WS-I Basic Profile 1.0
• Resources
• About the author
• Comments