This post originated from an RSS feed registered with .NET Buzz by Christian Weyer. Original Post: The Web services empire strikes back - WS-I BP Conformance Feed Title: Christian Weyer: Web Services & .NET Feed URL: http://www.asp.net/err404.htm?aspxerrorpath=/cweyer/Rss.aspx Feed Description: Philosophizing about and criticizing the brave new world ... Latest .NET Buzz Posts Latest .NET Buzz Posts by Christian Weyer Latest Posts From Christian Weyer: Web Services & .NET

Part 1: The Web services empire strikes back - Introductory thoughts
Part 2: The Web services empire strikes back - Inner Workings
Part 3: The Web services empire strikes back - Web Services in Visual Studio 2005

Honestly, aren't Web services a lot about interoperability? Yes, absolutely. And it is essential to the success of Web services and any Web services platform vendor that the interoperability between various implementations can be guaranteed. The first steps in this realm were made with the so called SOAPBuilders Interop Lab that has been established primarily as a virtual lab for builders of SOAP stacks. But with the advent of WSDL and UDDI respectively interoperability testing became noticeably harder. There the Web Services Interoperability Organization (WS-I.org) has been founded. One of the goals of the WS-I is to work out common scenarios, do's and dont's for three areas of interest in Web services landscape: messages, descriptions, and registry data. The respective specifications for SOAP, WSDL, and UDDI literally leave to much space for interpretation - and this is a killer for successful interoperability.

These best practices have been assembles into a document called the Basic Profile 1.0 (BP 1.0). The BP 1.0 addresses issues that can arise with SOAP 1.1 messages, allowing for future compatibility with SOAP 1.2 messages, typically sent over an HTTP 1.1 transport. Further it discusses the Web Services Description Language (WSDL) 1.1 documents exposed by Web services, allowing for future compatibility with WSDL 1.2 definitions. Last but not least it talks about how to use registry data for discovery, such as UDDI tModels. The BP 1.0 is the de-facto standard document to follow when building on tomorrow's Web services interoperability. And Microsoft took a bunch of developers and integrated the BP 1.0 into ASMX v2 (Note: discovery data is outside the scope of the .NET Framework 2.0's Basic Profile 1.0 conformance support).

Every Web service you create in Visual Studio 2005 will be BP1.0 compliant by default. This is good and helps to further ensure and enable true interoperability if all other Web services runtime/engine vendors will do the same in their upcoming revisions of their products.
Here is an example of a classical 'Hello World' Web service in ASMX v2:

using System.Web.Services;
using System.Web.Services.Protocols;

[WebServiceBinding(
  ConformanceClaims=WsiClaims.BP10,
  EmitConformanceClaims=true)]
public class Service_asmx
{
  [WebMethod]
  public string HelloWorld()
  {
    return "Hello World";
  }
}

The most important fact to notice in the above code is the usage of the WebServiceBindingAttribute class. Not that this binding is all new, not at all. If you are leveraging multiple bindings in a Web service this attribute is already very familiar to you. It declares the binding one or more Web service methods implemented within the class. A binding is similar to an interface in that it defines a concrete set of operations. Each Web service method is an operation within a particular binding. And it is exactly this concept of a binding that the BP 1.0 conformance implementation of ASMX works on.
The ConformanceClaims parameter of WebServiceBindingAttribute shows which level of conformance to follow. Currently there are just two values in the WsiClaims enumeration to use: None and BP10. The value BP10 indicates to use the Basic Profile 1.0 conformance rules to follow. An additional step is to instruct the ASMX engine to emit conformance claims into the service description. By setting the EmitConformanceClaims property to true your Web service's WSDL will be enriched with BP 1.0 conformance claim information. A small sample for a WSDL snippet can be seen here:

<wsdl:binding name="foo" type="tns:foo">
  <wsdl:documentation>
    <wsi:Claim conformsTo="http://ws-i.org/profiles/basic/1.0"
      xmlns:wsi="http://ws-i.org/schemas/conformanceClaim/" />
  </wsdl:documentation>
  <soap:binding transport="http://schemas.xmlsoap.org/soap/http"
    style="document" />
  <wsdl:operation name="HelloWorld">
    <soap:operation soapAction="http://tempuri.org/HelloWorld"
      style="document" />
    <wsdl:input>
      <soap:body use="literal" />
    </wsdl:input>
    <wsdl:output>
      <soap:body use="literal" />
    </wsdl:output>
  </wsdl:operation>
</wsdl:binding>

This piece shows how the wsdl:documentation element is used to emit optional metadata about the conformance level of the regarding WSDL element (the binding in this case) into the automatically generated WSDL. It is important to notice that this is just for informational purposes. A WSDL processor does not need to understand this information and a Web services can be conformant without explicitly stating it through such claims in the WSDL.
If you try to use features in your Web service that are officially not supported by the BP 1.0 you will get a hint when you point to the service's help and test page. The help page shown in figure 4 is generated when we decorate our Web service from above with the SoapRpcService attribute. Obviously RPC/encoded Web services are discouraged by the WS-I and the help page actually tells us which statements of the BP 1.0 is violated. In this case it is R2706: A DESCRIPTION MUST use the value of 'literal' for the use attribute in the SOAP Binding description. Which means that you can either use RPC/literal or Document/literal style Web services. For those of you who do not like to see such warnings there is a configuration switch to disable this functionality.

Figure 4: Web services test page warnings

On the other side, Web service clients based on .NET Framework 2.0 are also conformant by default - of course unless the WSDL which it is targeted at is non conformant. The wsdl.exe command line tool as well and the new incarnation of the 'Add Web Reference ...' dialog (not yet implemented in Beta 1) checks for WSDL conformance and gives you warnings if the WSDL is non conformant.

Here's an example message from wsdl.exe when consuming a WSDL document that uses SOAP encoding, which is prohibited by the BP 1.0 document:

Microsoft (R) Web Services Description Language Utility
[Microsoft (R) .NET Framework, Version 2.0.40325.0]
Copyright (C) Microsoft Corporation. All rights reserved.

Warning: This web reference does not conform to WS-I Basic Profile v1.0.
R2706: A DESCRIPTION MUST use the value of 'literal' for the use attribute
in the SOAP Binding description.
  - Operation 'HelloWorld' on binding 'EncodedServiceSoap' from namespace
'http://tempuri.org/'.
Writing file 'C:\Demos\EncodedService.cs'

The support for the Basic Profile 1.0 will further ensure interoperability with other Web services toolkits such as Apache Java Axis as soon as they support the conformance checks based on the BP 1.0. The Axis team over there is currently working on making 1.2 BP-compliant.