Applying Basic Profile Rules When Consuming Web Services

 

Patterns and Practices home

Microsoft Corporation

August 2003

Applies to:
   Microsoft® Visual Studio® .NET

Summary: Adjust your code to make it comply with the constraints set forth in the Basic Profile. (50 printed pages)

Contents

Messaging
Service Description
Service Publication and Discovery
Security

Developers who write Web service clients may find that they need to adjust their code to make it comply with the constraints set forth in the Basic Profile. To provide some guidance on how to make these adjustments, we first made some general assumptions about how a developer will implement a client that consumes Web services.

These assumptions are made for the purposes of this chapter because otherwise they would apply very broadly. For example, if alternatives to using SoapHttpClientProtocol (such as HttpWebRequest) were considered for each rule, then a large portion of rules would be listed as potentially compliant since using something like HttpWebRequest allows very flexible control in the request allowing for a violation of the rule.

These assumptions are:

  • The Web client is implemented as a class derived from the .NET SoapHttpClientProtocol class, Microsoft® Visual Studio® .NET Add Web Reference wizard generates a template class derived from the SoapHttpClientProtocol class when it creates a client that consumes a Web service.
  • No parameters, return values, or headers contain XmlNode types.
  • The Web service and its WSDL description are compliant with the WS-I Basic Profile.

Next, we assigned each of the Basic Profile rules one of four possible levels of compliance. These levels indicate how closely a client written according to our assumptions complies with the rules' requirements. These levels are:

  • Compliant — this means that if the profile rule is applicable to your client or the Web service you are using, you will not need to make any code changes to meet the requirements of the rule. Note that "weak" rules that contain SHOULD or MAY are classified as compliant when the Web client does not meet their requirements. This is because these rules aren't mandatory. See R2008 for an example.
  • Typically compliant — this means that if the particular profile rule is applicable to your client or the Web service you are using, it probably meets the requirements of the rule but there is a possibility it needs code adjustments.
  • Potentially compliant — this means that if the particular profile rule is applicable to your client or the Web service you are using, you will probably need to make code adjustments to make your Web client meet the rule's requirements.
  • Unique — this means that if the profile rule is applicable to your client or the Web service you are using, you will need to make code adjustments such as using HttpWebRequest for more low-level control.

All directives are included in the same groups (such as messaging) and order as they are listed in the Basic Profile. Note that only the rule numbers and directives are included here. For the complete text, consult the WS-I Basic Profile. The next entry after the rule is the level of compliancy and the final entry includes comments, suggestions and code samples. Here is an example of the format:

R0001 © Profile rule number

An INSTANCE MUST be described by a WSDL 1.1 service description, by a UDDI binding template, or both. © Profile rule

Compliant © Level of compliancy

A .NET Web service supports generating a WSDL 1.1 service description by using reflection on the WebService class. © Comment

Messaging

Messaging is the exchange of protocol elements, usually over a network. Messages encapsulate information transmitted to and from a Web service. These messages do not provide programming instructions; rather they specify to a Web services server which operations to invoke. According to the WS-I Basic Profile, the messaging system uses the following standards at the specified version levels:

XML Representation of SOAP Messages

This section includes directives in section 3.1 of the Basic Profile, which deals with the XML representation of SOAP messages. All these directives are based on the SOAP 1.1, Section 4 standard.

R0001

An INSTANCE MUST be described by a WSDL 1.1 service description, by a UDDI binding template, or both.

Compliant

The Add Web Reference wizard in Visual Studio.NET supports importing a WSDL 1.1 description either directly or through a UDDI registry.

R0002

A DESCRIPTION MAY contain conformance claims regarding instances, as specified in the conformance claim schema.

Unique

The Add Web Reference wizard in Visual Studio.NET fails with a WSDL description that contains conformance claims. You need to manually remove the wsi:Claim elements to have the wizard properly process the WSDL description.

R0003

A DESCRIPTION's conformance claims MUST be children of the wsdl:documentation element of each of the elements: wsdl:port, wsdl:binding, wsdl:portType, wsdl:operation (as a child element of wsdl:portType but not of wsdl:binding) and wsdl:message.

Unique

The Add Web Reference wizard in Visual Studio.NET fails with a WSDL description that contains conformance claims. You need to manually remove the wsi:Claim elements to have the wizard properly process the WSDL description.

R0004

A MESSAGE MAY contain conformance claims, as specified in the conformance claim schema.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, the default is to exclude conformance claims. To include a conformance claim, you must manually modify the proxy class to include a conformance claim header, and make sure to set the header property to a valid instance of the header before invoking the Web service. The following example demonstrates how to modify the proxy class to include the conformance claim (bold lines are the necessary additional code):

// Existing web service class declaration
public class MyWebService : SoapHttpClientProtocol {

  // Add claim header variable declaration
  public ClaimHeaderType ClaimHeaderValue;
  // Other existing header variable declarations

  // Add claim soap header
  [SoapHeaderAttribute("ClaimHeaderValue")]
  // Existing web method declaration

}

// Add ClaimHeaderType class
[XmlRoot ("Claim",
    Namespace="http://ws-i.org/schemas/conformanceClaim/",
    IsNullable=false)]
public class ClaimHeaderType : SoapHeader
{
  [XmlAttribute ()]
  public string conformsTo = "http://ws-i.org/profiles/basic/1.0";
}

R0005

A MESSAGE's conformance claims MUST be carried as SOAP header blocks.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, the default is to exclude conformance claims.

R0006

A MESSAGE MAY contain conformance claims for more than one profile.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, the default is to exclude conformance claims.

R0007

A SENDER MUST NOT use the soap:mustUnderstand attribute when sending a SOAP header block containing a conformance claim.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, the default is to exclude conformance claims. If you manually modify the proxy class to include a conformance claim, do not set the MustUnderstand property of the SoapHeader to true.

R3020

REGDATA of type uddi:tModel claiming conformance with a Profile MUST be categorized using the ws-i-org:conformsTo:2002_12 taxonomy.

Not applicable

Visual Studio.NET does not provide a tool for registering a Web service in a UDDI registry.

R3030

REGDATA of type uddi:tModel claiming conformance with a Profile MUST use the ws-i-org:conformsTo:2002_12 categorization value corresponding to the conformance claim URI for that Profile.

Not applicable

Visual Studio.NET does not provide a tool for registering a Web service in a UDDI registry.

R3021

A REGISTRY MUST support the WS-I Conformance category system by adding the ws-i-org:conformsTo:2002_12 tModel definition in its registry content.

Not applicable

Visual Studio.NET does not provide a tool for registering a Web service in a UDDI registry.

R3005

REGDATA other than uddi:tModel elements representing conformant Web service types MUST NOT be categorized using the ws-i-org:conformsTo:2002_12 taxonomy and a categorization of "http://ws-i.org/profiles/basic/1.0".

Not applicable

Visual Studio.NET does not provide a tool for registering a Web service in a UDDI registry.

R3004

REGDATA of type uddi:tModel MUST be constructed so that the conformance claim it makes is consistent with the conformance claim made by the wsdl:binding to which it refers.

Not applicable

Visual Studio.NET does not provide a tool for registering a Web service in a UDDI registry.

R4001

A RECEIVER MUST accept messages that include the Unicode Byte Order Mark (BOM).

Not applicable

This rule is not applicable to consuming a Web service. When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, the default is to exclude the BOM. The following example demonstrates how to use the RequestEncoding property to include the BOM in the message:

localhost.Service1 myService = new localhost.Service1()
// passing true to the UTF8Encoding constructor tells
// it to include the Unicode BOM
myService.RequestEncoding = new System.Text.UTF8Encoding(true);
String result = myService.HelloWorld();

R1000

When a MESSAGE contains a soap:Fault element, that element MUST NOT have element children other than faultcode, faultstring, faultactor and detail.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it properly treats a returned fault message that adheres to this rule as a SoapException.

R1001

When a MESSAGE contains a soap:Fault element its element children MUST be unqualified.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it properly treats a returned fault message that adheres to this rule as a SoapException.

R1002

A RECEIVER MUST accept fault messages that have any number of elements, including zero, appearing as children of the detail element. Such children can be qualified or unqualified.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it properly treats a returned fault message that adheres to this rule as a SoapException.

R1003

A RECEIVER MUST accept fault messages that have any number of qualified or unqualified attributes, including zero, appearing on the detail element. The namespace of qualified attributes can be anything other than "http://schemas.xmlsoap.org/soap/envelope/".

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it properly treats a returned fault message that adheres to this rule as a SoapException.

R1016

A RECEIVER MUST accept fault messages that carry an xml:lang attribute on the faultstring element.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it properly treats a returned fault message that adheres to this rule as a SoapException.

R1004

When a MESSAGE contains a faultcode element the content of that element SHOULD be one of the fault codes defined in SOAP 1.1 or a namespace qualified fault code.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it properly treats a returned fault message that either does or does not adhere to this rule as a SoapException.

R1031

When a MESSAGE contains a faultcode element the content of that element SHOULD NOT use the SOAP 1.1 "dot" notation to refine the meaning of the Fault.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it properly treats a returned fault message that either does or does not adhere to this rule as a SoapException

R1005

A MESSAGE MUST NOT contain soap:encodingStyle attributes on any of the elements whose namespace name is "http://schemas.xmlsoap.org/soap/
envelope/".

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it generates a message that adheres to this rule. When a Web service uses either the document/encoded or rpc/encoded format, it requires soap:encodingStyle attributes to be included in the SOAP message. Since the Basic Profile prohibits these two formats, a proxy class generated for a conformant Web service does not generate messages that use soap:encodingStyle attributes.

R1006

A MESSAGE MUST NOT contain soap:encodingStyle attributes on any element that is a child of soap:Body.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it generates a message that adheres to this rule.

R1007

A MESSAGE described in an rpc-literal binding MUST NOT contain soap:encodingStyle attribute on any elements are grandchildren of soap:Body.

Unique

The Add Web Reference wizard in Visual Studio.NET cannot process a WSDL description that uses an rpc-literal binding.

R1008

A MESSAGE MUST NOT contain a Document Type Declaration.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it generates a message that adheres to this rule.

R1009

A MESSAGE MUST NOT contain Processing Instructions.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it generates a message that adheres to this rule.

R1010

A RECEIVER MUST accept messages that contain an XML Declaration.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it always generates the XML Declaration on the message and properly handles a response message that adheres to this rule.

R1011

A MESSAGE MUST NOT have any element children of soap:Envelope following the soap:Body element.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it generates a message that adheres to this rule.

R1012

A MESSAGE MUST be serialized as either UTF-8 or UTF-16.

Typically Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it will, by default, use UTF-8 encoding. You can specify what encoding to use by setting the RequestEncoding property. In this case, you must use either UnicodeEncoding or UTF8Encoding. The following example shows how to specify UTF-16 encoding (Unicode):

localhost.Service1 myService = new localhost.Service1();
// Sets the encoding style to use UTF-16
myService.RequestEncoding = System.Text.Encoding.Unicode;
String result = myService.HelloWorld();

R1018

The media type of a MESSAGE's envelope MUST indicate the correct character encoding, using the charset parameter.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it generates a message that adheres to this rule.

R1013

A MESSAGE containing a soap:mustUnderstand attribute MUST only use the lexical forms "0" and "1".

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it generates a message that adheres to this rule. If any of the methods of the Web service have headers defined, a property will exist in the proxy class for each header. The property type will be a class inherited from SoapHeader, which has a MustUnderstand property. Depending on the value of the MustUnderstand property for each header, the proxy class will generate a soap:mustUnderstand attribute with the value of either "0" or "1".

R1014

The children of the soap:Body element in a MESSAGE MUST be namespace qualified.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it generates a message that adheres to this rule.

R1015

A RECEIVER MUST generate a fault if they encounter a message whose document element has a local name of "Envelope" but a namespace name that is not "http://schemas.xmlsoap.org/soap/envelope/".

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it generates a message that adheres to this rule.

R1017

A RECEIVER MUST NOT mandate the use of the xsi:type attribute in messages except as required in order to indicate a derived type (see XML Schema Part 1: Structures, Section 2.6.1).

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it will properly handle a response message that adheres to this rule.

The Soap Processing Model

This portion includes directives in section 3.2 of the Basic Profile, which alludes to information in SOAP 1.1, Section 2. SOAP 1.1, Section 2 defines a model for processing messages.

R1025

A RECEIVER MUST handle messages in such a way that it appears that all checking of mandatory headers is performed before any actual processing.

Not Applicable

This rule is not applicable to consuming a Web service.

R1027

A RECEIVER MUST generate a "soap:MustUnderstand" fault when a message contains a mandatory header block (i.e., one that has a soap:mustUnderstand attribute with the value "1") targeted at the receiver (via soap:actor) that the receiver does not understand.

Not Applicable

This rule is not applicable to consuming a Web service.

R1028

When a Fault is generated by a RECEIVER, further processing SHOULD NOT be performed on the SOAP message aside from that which is necessary to rollback, or compensate for, any effects of processing the message prior to the generation of the Fault.

Not Applicable

This rule is not applicable to consuming a Web service.

R1029

Where the normal outcome of processing a SOAP message would have resulted in the transmission of a SOAP response, but rather a SOAP Fault is generated instead, a RECEIVER MUST transmit a SOAP Fault message in place of the response.

Not Applicable

This rule is not applicable to consuming a Web service.

R1030

A RECEIVER that generates a SOAP Fault SHOULD notify the end user that a SOAP Fault has been generated when practical, by whatever means is deemed appropriate to the circumstance.

Compliant

Although it is not mandatory, when you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, the end user should be notified of a fault if a SoapException is returned.

Using SOAP in HTTP

This portion includes directives in section 3.3 of the Basic Profile, which alludes to information in the following specifications:

SOAP 1.1 defines a single protocol binding, which is for HTTP and the profile mandates the use of that binding.

HTTP/1.1 has several performance advantages and is more clearly specified in comparison to HTTP/1.0. Note that support for HTTP/1.0 is implied in HTTP/1.1, and that intermediaries may change the version of a message; for more information about HTTP versioning, see RFC2145.

R1140

A MESSAGE SHOULD be sent using HTTP/1.1.

Compliant

Although it is not mandatory, when you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it sends the message using HTTP/1.1.

R1141

A MESSAGE MUST be sent using either HTTP/1.1 or HTTP/1.0.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it sends the message using HTTP/1.1.

R1107

A RECEIVER MUST interpret SOAP messages containing only a soap:Fault element as a Fault.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, if the Web service response contains a soap:Fault element, the proxy returns a SoapException regardless of the HTTP status code.

R1132

A HTTP request MESSAGE MUST use the HTTP POST method.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it generates a message that adheres to this rule.

R1108

A MESSAGE MUST NOT use the HTTP Extension Framework (RFC2774).

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it generates a message that adheres to this rule.

R1109

The value of the SOAPAction HTTP header field in a HTTP request MESSAGE MUST be a quoted string.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it generates a message that adheres to this rule.

R1119

A RECEIVER MAY respond with a Fault if the value of the SOAPAction HTTP header field is not quoted.

Not Applicable

This rule is not applicable to consuming a Web service. When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it always makes the SOAPAction HTTP header field a quoted string.

R1110

An INSTANCE MAY accept connections on TCP port 80 (HTTP).

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it uses whichever TCP port was specified in the location attribute of the soap:address element from the WSDL description.

R1124

An INSTANCE MUST use a 2xx HTTP status code for responses that indicate a successful outcome of a request.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it properly processes a response that adheres to this rule.

R1111

An INSTANCE SHOULD use a "200 OK" HTTP status code for responses that contain a SOAP message that is not a SOAP fault.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it properly processes a response that either does or does not adhere to this rule.

R1112

An INSTANCE SHOULD use either a "200 OK" or "202 Accepted" HTTP status code for a response that does do not contain a SOAP message but indicates successful HTTP outcome of a request.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it properly processes a response that adheres to this rule.

R1130

An INSTANCE MUST use HTTP status code "307 Temporary Redirect" when redirecting a request to a different endpoint.

Not Applicable

This rule is not applicable to consuming a Web service. When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it will treat a "307 Temporary Redirect" HTTP status code as an exception, allowing for the code to respond as needed.

R1131

A CONSUMER MAY automatically redirect a request when it encounters a "307 Temporary Redirect" HTTP status code in a response.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it does not automatically redirect a request when it receives a "307 Temporary Redirect" HTTP status code. The following example shows how you can follow the redirect URL:

localhost.Service1 myService = new localhost.Service1();
string result;
bool redirect;
do
{
  redirect = false;
  try
  {
    result = myService.HelloWorld();
  }
  catch (WebException ex)
  {
    HttpWebResponse response = (HttpWebResponse)ex.Response;
    if (response.StatusCode == HttpStatusCode.TemporaryRedirect)
    {
      myService.Url = response.Headers["location"];
      redirect = true;
    }
    else
    {
      throw;
    }
  }
}
while (redirect == true);

R1125

An INSTANCE MUST use a 4xx HTTP status code for responses that indicate a problem with the format of the request.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it properly processes a response that adheres to this rule.

R1113

An INSTANCE SHOULD use a "400 Bad Request" HTTP status code, if the request message is a malformed HTTP request, or not well-formed XML.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it properly processes a response that adheres to this rule. The proxy class always generates a properly formed HTTP request containing well-formed XML.

R1114

An INSTANCE SHOULD use a "405 Method not Allowed" HTTP status code if the request method was not "POST".

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it properly processes a response that adheres to this rule. The proxy class always generates a request using an HTTP POST request method.

R1115

An INSTANCE SHOULD use a "415 Unsupported Media Type" HTTP status code if the Content-Type HTTP request header did not have a value consistent with the value specified for the corresponding binding of the input message.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it properly processes a response that adheres to this rule. The proxy class always generates a request with the Content-Type HTTP request header set to "text/xml".

R1126

An INSTANCE MUST use a "500 Internal Server Error" HTTP status code if the response message is a SOAP Fault.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it properly processes a response that adheres to this rule.

R1120

An INSTANCE MAY use the HTTP state mechanism ("Cookies").

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, you can use the CookieContainer property to either send cookies or access returned cookies.

R1122

An INSTANCE using Cookies SHOULD conform to RFC2965.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it properly handles a response that adheres to this rule.

R1121

An INSTANCE SHOULD NOT require consumer support for Cookies in order to function correctly.

Not applicable

This rule is not applicable to consuming a Web service.

R1123

The value of the cookie MUST be considered to be opaque by the CONSUMER.

Typically Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, you must not use the CookieContainer property to access cookies returned from the Web service for any purpose other then passing them back to the Web service in additional calls.

Service Description

This portion includes directives in section 4 of the Basic Profile, which alludes to information in the following specifications:

The WSDL specification describes and publishes the formats and protocols of a Web service in a standard way. WSDL elements contain a description of the data, usually in XML, that is passed to the Web service so that both the sender and the receiver understand the data being exchanged. The WSDL elements also contain a description of the operations to be performed on that data so that the receiver of the message knows how to process it, and a binding to a protocol or a transport, so that the sender knows how to send it. Typically, WSDL is used with SOAP, and the WSDL specification includes a SOAP binding.

XML provides the description, storage, and transmission format for data exchanged via a Web service. XML elements and attributes define type and structure information for the data they carry. The XML syntax specifies how data is generically represented, defines how and with what qualities of service the data is transmitted, and details how the services are published and discovered.

Document Structure

This portion includes directives in section 4.2 of the Basic Profile, which alludes to information in WSDL 1.1 This defines an XML-based structure for describing Web services.

R2028

A DESCRIPTION using the WSDL namespace (prefixed "wsdl" in this Profile) MUST be valid according to the XML Schema found at "http://schemas.xmlsoap.org/wsdl/
2003-02-11.xsd".

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2029

A DESCRIPTION using the WSDL SOAP binding namespace (prefixed "soapbind" in this Profile) MUST be valid according to the XML Schema found at "http://schemas.xmlsoap.org/wsdl/soap/2003-02-11.xsd".

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2001

A DESCRIPTION MUST only use the WSDL "import" statement to import another WSDL description.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2002

To import XML Schema Definitions, a DESCRIPTION MUST use the XML Schema "import" statement.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2003

A DESCRIPTION MUST use the XML Schema "import" statement only within the xsd:schema element of the types section.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2004

A DESCRIPTION MUST NOT use the XML Schema "import" statement to import a Schema from any document whose root element is not "schema" from the namespace "http://www.w3.org/2001/XMLSchema".

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2009

An XML Schema directly or indirectly imported by a DESCRIPTION MAY include the Unicode Byte Order Mark (BOM).

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that imports an XML Schema which either does or does not include the BOM.

R2010

An XML Schema directly or indirectly imported by a DESCRIPTION MUST use either UTF-8 or UTF-16 encoding.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that imports an XML Schema in either UTF-8 or UTF-16 encoding format.

R2011

An XML Schema directly or indirectly imported by a DESCRIPTION MUST use version 1.0 of the eXtensible Markup Language W3C Recommendation.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2007

A DESCRIPTION MUST specify a non-empty location attribute on the wsdl:import element.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2008

In a DESCRIPTION the value of the location attribute of a wsdl:import element SHOULD be treated as a hint.

Compliant

This is not mandatory.The Add Web Reference wizard in Visual Studio.NET always attempts to download the WSDL description specified with the location attribute.

R2022

When they appear in a DESCRIPTION, wsdl:import elements MUST precede all other elements from the WSDL namespace except wsdl:documentation.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2023

When they appear in a DESCRIPTION, wsdl:types elements MUST precede all other elements from the WSDL namespace except wsdl:documentation and wsdl:import.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R4004

A DESCRIPTION MUST use version 1.0 of the eXtensible Markup Language W3C Recommendation.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R4002

A DESCRIPTION MAY include the Unicode Byte Order Mark (BOM).

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that either includes or does not include a BOM.

R4003

A DESCRIPTION MUST use either UTF-8 or UTF-16 encoding.

Typically Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that uses UTF-8 encoding, but cannot process one using UTF-16 encoding.

R2005

The targetNamespace attribute on the wsdl:definitions element of a description that is being imported MUST have same the value as the namespace attribute on the wsdl:import element in the importing DESCRIPTION.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2020

The wsdl:documentation element MAY occur as a child of the wsdl:import element in a DESCRIPTION.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2021

The wsdl:documentation element MAY occur as a child of the wsdl:part element in a DESCRIPTION.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2024

The wsdl:documentation element MAY occur as a first child of the wsdl:definitions element in a DESCRIPTION.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2025

A DESCRIPTION containing WSDL extensions MUST NOT use them to contradict other requirements of the Profile.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2026

A DESCRIPTION SHOULD NOT include extension elements with a wsdl:required attribute value of "true" on any WSDL construct (wsdl:binding, wsdl:portType, wsdl:message, wsdl:types, or wsdl:import) that claims conformance to the Profile.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2027

If during the processing of an element in the WSDL namespace in a description, a consumer encounters a WSDL extension element amongst its element children, that has a wsdl:required attribute with a boolean value of "true" that the consumer does not understand or cannot process, the CONSUMER MUST fail processing of that element in the WSDL namespace.

Unique

The Add Web Reference wizard in Visual Studio.NET ignores WSDL extension elements it does not understand regardless of the wsdl:required attribute value, when it is present.

Types

This portion of the profile modifies and refers to WSDL 1.1, Section 2.2, which describes WSDL data types.

R2101

A DESCRIPTION MUST NOT use QName references to elements in namespaces that have been neither imported, nor defined in the referring WSDL document.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2102

A QName reference to a Schema component in a DESCRIPTION MUST use the namespace defined in the targetNamespace attribute on the xsd:schema element, or to a namespace defined in the namespace attribute on an xsd:import element within the xsd:schema element.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2105

All xsd:schema elements contained in a wsdl:types element of a DESCRIPTION MUST have a targetNamespace attribute with a valid and non-null value, UNLESS the xsd:schema element has xsd:import and/or xsd:annotation as its only child element(s).

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2110

In a DESCRIPTION, array declarations MUST NOT extend or restrict the soapenc:Array type.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2111

In a DESCRIPTION, array declarations MUST NOT use wsdl:arrayType attribute in the type declaration.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2112

In a DESCRIPTION, array declaration wrapper elements SHOULD NOT be named using the convention ArrayOfXXX.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2113

A MESSAGE containing serialized arrays MUST NOT include the soapenc:arrayType attribute.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it generates a message that adheres to this rule.

R2114

The target namespace for WSDL definitions and the target namespace for schema definitions in a DESCRIPTION MAY be the same.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

Messages

This portion of the profile modifies and refers to WSDL 1.1, Section 2.3, which describes WSDL messages.

R2201

A document-literal binding in a DESCRIPTION MUST, in each of its soapbind:body element(s), have at most one part listed in the parts attribute, if the parts attribute is specified.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2210

If a document-literal binding in a DESCRIPTION does not specify the parts attribute on a soapbind:body element, the corresponding abstract wsdl:message MUST define zero or one wsdl:parts.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2202

A wsdl:binding in a DESCRIPTION MAY contain soapbind:body element(s) that specify that zero parts form the soap:body.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2203

An rpc-literal binding in a DESCRIPTION MUST refer, in its soapbind:body element(s), only to wsdl:part element(s) that have been defined using the type attribute.

Unique

The Add Web Reference wizard in Visual Studio.NET cannot process a WSDL description that uses an rpc-literal binding.

R2211

A MESSAGE described with an rpc-literal binding MUST NOT have the xsi:nil attribute with a value of "1" or "true" on the part accessors.

Unique

The Add Web Reference wizard in Visual Studio.NET cannot process a WSDL description that uses an rpc-literal binding.

R2207

A wsdl:message in a DESCRIPTION MAY contain wsdl:parts that use the elements attribute provided those wsdl:parts are not referred to by a soapbind:body in an rpc-literal binding.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2204

A document-literal binding in a DESCRIPTION MUST refer, in each of its soapbind:body element(s), only to wsdl:part element(s) that have been defined using the element attribute.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2208

A binding in a DESCRIPTION MAY contain soapbind:header element(s) that refer to wsdl:parts in the same wsdl:message that are referred to by its soapbind:body element(s).

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2205

A wsdl:binding in a DESCRIPTION MUST refer, in each of its soapbind:header, soapbind:headerfault and soapbind:fault elements, only to wsdl:part element(s) that have been defined using the element attribute.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2209

A wsdl:binding in a DESCRIPTION SHOULD bind every wsdl:part of a wsdl:message in the wsdl:portType to which it refers to one of soapbind:body, soapbind:header, soapbind:fault or soapbind:headerfault.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2206

A wsdl:message in a DESCRIPTION containing a wsdl:part that uses the element attribute MUST refer, in that attribute, to a global element declaration.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

Port Types

A WSDL port type is an abstract set of operations mapped to one or more end points, defining the collection of operations for a binding; the collection of operations, because it is abstract, can be mapped to multiple transports through various bindings.

R2301

The order of the elements in the soap:body of a MESSAGE MUST be the same as that of the wsdl:parts in the wsdl:message that describes it.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it generates a message that adheres to this rule. For a document-literal binding, the Basic Profile requires the soap:body to contain only one wsdl:part, and the Add Web Reference wizard does not support rpc-literal bindings.

R2302

A DESCRIPTION MAY use the parameterOrder attribute of an wsdl:operation element to indicate the return value and method signatures as a hint to code generators.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2303

A DESCRIPTION MUST NOT use Solicit-Response and Notification type operations in a wsdl:portType definition.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2304

A wsdl:portType in a DESCRIPTION MUST have operations with distinct values for their name attributes.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2305

A wsdl:portType in a DESCRIPTION MUST be constructed so that the parameterOrder attribute, if present, omits at most 1 wsdl:part from the output message.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2306

A wsdl:message in a DESCRIPTION MUST NOT specify both type and element attributes on the same wsdl:part.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

Bindings

A WSDL binding is the concrete protocol and data formats for the operations and messages defined for a particular port type.

R2401

A wsdl:binding element in a DESCRIPTION MUST use WSDL SOAP Binding as defined in WSDL 1.1 Section 3.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

SOAP Binding

SOAP is the most popular transport for WSDL. The SOAP specification contains predefined rules for physically representing such data types as Booleans, integers, and arrays. Binding to SOAP therefore requires the abstract data types, messages, and operations to be bound to concrete physical representations on the wire.

R2701

The wsdl:binding element in a DESCRIPTION MUST be constructed so that its soapbind:binding child element specifies the transport attribute.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2702

A wsdl:binding in a DESCRIPTION MUST specify the HTTP transport protocol with SOAP binding. Specifically, the transport attribute of is soapbind:binding child MUST have the value "http://schemas.xmlsoap.org/soap/http".

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2705

A wsdl:binding in a DESCRIPTION MUST use either be a rpc-literal binding or a document-literal binding.

Typically Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule if the style attribute value is "document." It does not support descriptions with a style attribute value of "rpc" and a use attribute value of "literal".

R2706

A wsdl:binding in a DESCRIPTION MUST use the value of "literal" for the use attribute in all soapbind:body, soapbind:fault, soapbind:header, and soapbind:headerfault elements.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2707

A wsdl:binding in a DESCRIPTION that contains one or more soapbind:body, soapbind:fault, soapbind:header, or soapbind:headerfault elements that do not specify the use attribute MUST be interpreted as though the value "literal" had been specified in each case.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly interprets a WSDL description in a manner that adheres to this rule.

R2709

A wsdl:portType in a DESCRIPTION MAY have zero or more wsdl:bindings that refer to it, defined in the same or other WSDL documents.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2710

The operations in a wsdl:binding in a DESCRIPTION MUST result in wire signatures that are different from one another.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2711

A DESCRIPTION SHOULD NOT have more than one wsdl:port with the same value for the location attribute of the soapbind:address element.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2712

A document-literal binding MUST be represented on the wire as a MESSAGE with a soap:Body whose child element is an instance of the global element declaration referenced by the corresponding wsdl:message part.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it generates a message that adheres to this rule.

R2714

For one-way operations, an INSTANCE MUST NOT return a HTTP response that contains a SOAP envelope. Specifically, the HTTP response entity-body must be empty.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it properly handles a response that adheres to this rule.

R2750

A CONSUMER MUST ignore SOAP response carried in a response from a one-way operation.

Unique

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it will read the response if it receives a 5xx HTTP response code.

R2727

For one-way operations, a CONSUMER MUST NOT interpret a successful HTTP response status code (i.e., 2xx) to mean the message is valid or that the receiver would process it.

Typically Compliant

Your client application shouldn't assume that, even if a one-way operation is successfully delivered, the message is valid or will be processed.

R2716

A document-literal binding in a DESCRIPTION MUST NOT have the namespace attribute specified on contained soapbind:body, soapbind:header, soapbind:headerfault and soapbind:fault elements.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2717

An rpc-literal binding in a DESCRIPTION MUST have the namespace attribute specified, the value of which MUST be an absolute URI, on contained soapbind:body elements.

Unique

The Add Web Reference wizard in Visual Studio.NET cannot process a WSDL description that uses an rpc-literal binding.

R2726

An rpc-literal binding in a DESCRIPTION MUST NOT have the namespace attribute specified on contained soapbind:header, soapbind:headerfault and soapbind:fault elements.

Unique

The Add Web Reference wizard in Visual Studio.NET cannot process a WSDL description that uses an rpc-literal binding.

R2718

A wsdl:binding in a DESCRIPTION MUST have the same set of wsdl:operations as the wsdl:portType to which it refers.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2719

A wsdl:binding in a DESCRIPTION MAY contain no soapbind:headerfault elements if there are no known header faults.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2740

A wsdl:binding in a DESCRIPTION SHOULD contain a soapbind:fault describing each known fault.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2741

A wsdl:binding in a DESCRIPTION SHOULD contain a soapbind:headerfault describing each known header fault.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2742

A MESSAGE MAY contain a fault detail entry in a SOAP fault that is not described by a wsdl:fault element in the corresponding WSDL description.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it properly handles a response that adheres to this rule.

R2743

A MESSAGE MAY contain the details of a header processing related fault in a SOAP header block that is not described by a wsdl:headerfault element in the corresponding WSDL description.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, it properly handles a response that adheres to this rule.

R2720

A wsdl:binding in a DESCRIPTION MUST use the attribute named part with a schema type of "NMTOKEN" on all contained soapbind:header and soapbind:headerfault elements.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2749

A wsdl:binding in a DESCRIPTION MUST NOT use the attribute named parts on contained soapbind:header and soapbind:headerfault elements.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2721

A wsdl:binding in a DESCRIPTION MUST have the name attribute specified on all contained soapbind:fault elements.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2754

In a DESCRIPTION, the value of the name attribute on a soapbind:fault element MUST match the value of the name attribute on its parent wsdl:fault element.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2722

A wsdl:binding in a DESCRIPTION MAY specify the use attribute on contained soapbind:fault elements.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2723

If in a wsdl:binding in a DESCRIPTION the use attribute on a contained soapbind:fault element is present, its value MUST be "literal".

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2728

A wsdl:binding in a DESCRIPTION that omits the use attribute on a contained soapbind:fault element MUST be interpreted as though use="literal" had been specified.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly interprets a WSDL description in a manner that adheres to this rule.

R2724

If an INSTANCE receives a message that is inconsistent with its WSDL description, it SHOULD generate a soap:Fault with a faultcode of "Client", unless a "MustUnderstand" or "VersionMismatch" is generated.

Not Applicable

This rule is not applicable to consuming a Web service.

R2725

If an INSTANCE receives a message that is inconsistent with its WSDL description, it MUST check for "VersionMismatch", "MustUnderstand", and "Client" fault conditions in that order.

Not Applicable

This rule is not applicable to consuming a Web service.

R2729

A MESSAGE described with an rpc-literal binding that is a response message MUST have a wrapper element whose name is the corresponding wsdl:operation name suffixed with the string "Response".

Unique

The Add Web Reference wizard in Visual Studio.NET cannot process a WSDL description that uses an rpc-literal binding to create a proxy for sending messages in an rpc-literal format.

R2735

A MESSAGE described with an rpc-literal binding MUST place the part accessor elements for parameters and return value in no namespace.

Unique

The Add Web Reference wizard in Visual Studio.NET cannot process a WSDL description that uses an rpc-literal binding to create a proxy for sending messages in an rpc-literal format.

R2737

A MESSAGE described with an rpc-literal binding MUST namespace qualify the children of part accessor elements for the parameters and the return value with the targetNamespace in which their types are defined.

Unique

The Add Web Reference wizard in Visual Studio.NET cannot process a WSDL description that uses an rpc-literal binding to create a proxy for sending messages in an rpc-literal format.

R2738

A MESSAGE MUST include all soapbind:headers specified on a wsdl:input or wsdl:output of a wsdl:operation of a wsdl:binding that describes it.

Potentially Compliant

The Add Web Reference wizard in Visual Studio.NET generates a proxy class that has a property for each soapbind:header specified on the wsdl:input of an operation. You must initialize these properties to make the SOAP message generated by the proxy class include the header.

R2739

A MESSAGE MAY contain SOAP header blocks that are not described in the wsdl:binding that describes it.

Unique

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, the proxy class does not support including SOAP header blocks not described in the WSDL description. To include additional SOAP header blocks, you need to modify the proxy class and add additional SoapHeaderAttributes.

R2753

A MESSAGE containing SOAP header blocks that are not described in the appropriate wsdl:binding MAY have the mustUnderstand attribute on such SOAP header blocks set to '1'.

Unique

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, the proxy class does not support including SOAP header blocks not described in the WSDL description. To include additional SOAP header blocks, you need to modify the proxy class to add additional SoapHeaderAttributes.

R2751

The order of soapbind:header elements in soapbind:binding sections of a DESCRIPTION MUST be considered independent of the order of SOAP header blocks in the message.

Not applicable

This rule is not applicable to consuming a Web service. When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, the order of the SOAP header blocks will be in the same order as the soapbind:header elements of the WSDL description.

R2752

A MESSAGE MAY contain more then one instance of each SOAP header block for each soapbind:header element in the appropriate child of soapbind:binding in the corresponding description.

Unique

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, the proxy class does not support including more then one instance of a SOAP header block for a soapbind:header element from the WSDL description.

R2744

A HTTP request MESSAGE MUST contain a SOAPAction HTTP header field with a quoted value equal to the value of the soapAction attribute of soapbind:operation, if present in the corresponding WSDL description.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, the invocation generates a message that adheres to this rule.

R2745

A HTTP request MESSAGE MUST contain a SOAPAction HTTP header field with a quoted empty string value, if in the corresponding WSDL description, the soapAction of soapbind:operation is either not present, or present with an empty string as its value.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, the invocation generates a message that adheres to this rule.

R2747

A CONSUMER MUST understand and process all WSDL 1.1 SOAP Binding extension elements, irrespective of the presence or absence of the wsdl:required attribute on an extension element; and irrespective of the value of the wsdl:required attribute, when present.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly interprets a WSDL description in a manner that adheres to this rule.

R2748

A CONSUMER MUST NOT interpret the presence of the wsdl:required attribute on a soapbind extension element with a value of "false" to mean the extension element is optional in the messages generated from the WSDL description.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly interprets a WSDL description in a manner that adheres to this rule.

XML Schema

An XML schema represents the interrelationship between the attributes and elements of an XML object (for example, a document or a portion of a document). To create a schema for a document, you analyze its structure, defining each structural element as you encounter it. For example, within a schema for a document describing a Web site, you would define a Web site element, a Web page element, and other elements that describe possible content divisions within any page on that site. Just as in HTML, elements are defined within a set of tags.

R2800

A DESCRIPTION MAY use any construct from XML Schema 1.0.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

R2801

A DESCRIPTION MUST use XML Schema 1.0 Recommendation as the basis of user defined datatypes and structures.

Compliant

The Add Web Reference wizard in Visual Studio.NET properly processes a WSDL description that adheres to this rule.

Service Publication and Discovery

The purpose of a UDDI registry is to give people a way to find and use a Web service. The UDDI registry accepts information describing a business, including the Web services it offers, and allows users to perform online searches and to download information. The two main parts of UDDI are registration (or publication) and discovery. Registration means that businesses can post information to UDDI that other businesses can search for and discover. UDDI registration is contained in a variety of data structures, two of which, binding templates and tModels, are addressed in the Basic Profile.

Binding Templates

A binding template is a UDDI data structure that organizes information for specific instances of service types. When businesses want to make their specification-compliant services available to the registry, they include a reference to the tModelKey (see below) for that service type in their binding template data. Binding templates provide information for physically accessing a Web service that is registered with UDDI. Examples of the access points in the bindingTemplate structure include mailto:, http:, and phone:.

R3100

REGDATA of type uddi:bindingTemplate representing a conformant INSTANCE MUST contain the uddi:accessPoint element.

Not applicable

Visual Studio.NET does not provide a tool for registering a Web service in a UDDI registry.

tModels

In UDDI terms, a tModel is the mechanism used to exchange metadata about a Web service, such as the Web service description, or a pointer to a WSDL file. A tModel is a data structure representing a service type (a generic representation of a registered service) in the UDDI registry. Each business registered with UDDI categorizes all of its Web services according to a defined list of service types. Businesses can search the registry's listed service types to find service providers. The tModel is an abstraction for a technical specification of a service type; it organizes the service type's information and makes it accessible in the registry database. Each tModel consists of a name, an explanatory description, and a Universal Unique Identifier (UUID). The tModel name identifies the service, such as, for example, "online order placement." The description supplies more information, which in this case might be place an order online. The unique identifier, called a tModelKey, is a series of alphanumeric characters, such as, for example, uuid:4CD7E4BC-648B-426D-9936-443EAAC8AI. Another example, the tModel uddi-org:http has the description An http or Web browser based Web service, and the tModelKey uuid:68DE9E80-AD09-469D-8A37-088422BFBC36.

R3002

REGDATA of type uddi:tModel representing a conformant Web service type MUST use WSDL as the description language.

Not applicable

Visual Studio.NET does not provide a tool for registering a Web service in a UDDI registry.

R3003

REGDATA of type uddi:tModel representing a conformant Web service type MUST be categorized using the uddi:types taxonomy and a categorization of "wsdlSpec".

Not applicable

Visual Studio.NET does not provide a tool for registering a Web service in a UDDI registry.

R3010

REGDATA of type uddi:tModel representing a conformant Web service type MUST follow V1.08 of the UDDI Best Practice for Using WSDL in a UDDI Registry.

Not applicable

Visual Studio.NET does not provide a tool for registering a Web service in a UDDI registry.

R3011

The wsdl:binding that is referenced by REGDATA of type uddi:tModel MUST itself conform to the profile.

Not applicable

Visual Studio.NET does not provide a tool for registering a Web service in a UDDI registry.

Security

For implementing Web service clients, the Basic Profile offers guidance on using HTTPS and on certificate authorities when invoking a Web service.

The Use of HTTPS

HTTPS tunnels HTTP messages over a secure network connection protected by the using the SSL/TLS protocol (Secure Sockets Layer/Transport Layer Security), which is commonly called SSL.

R5000

An INSTANCE MAY require the use of HTTPS.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, the invocation will use either HTTP or HTTPS, depending on what was specified in the location attribute of the soapbind:address element from the WSDL description.

R5001

If an INSTANCE requires the use of HTTPS, the location attribute of the soapbind:address element in its wsdl:port description MUST be a URI whose scheme is "https"; otherwise it MUST be a URI whose scheme is "http".

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, the invocation will use either HTTP or HTTPS depending on what was specified in the location attribute of the soapbind:address element from the WSDL description.

R5010

An INSTANCE MAY require the use of HTTPS with mutual authentication.

Compliant

When you invoke a Web service using the proxy class generated by the Add Web Reference wizard in Visual Studio.NET, you can use the ClientCertificates property of the proxy class to pass a client certificate to the Web service that requires mutual authentication.

Show: