Applying Basic Profile Rules When Implementing Web Services

Article
06/22/2007

Microsoft Corporation

August 2003

Summary: Learn how to adjust your code to make it comply with the constraints included in the Basic Profile. (54 printed pages)

Messaging
Service Description
Service Publication and Discovery
Security

Developers who write Web services may find that they need to adjust their code to make it comply with the constraints included 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 Web service.

These assumptions are made for the purposes of this chapter because otherwise they would apply very broadly. For example, if the usage of SoapExtensions were considered for each rule, then a large portion of the rules would be listed as potentially compliant since a custom SoapExtension allows very flexible control of Web service behavior allowing for violation of the rule.

These assumptions are:

The Web service is implemented as a class derived from the .NET WebService class. When you use the Visual Studio .NET Add New Project wizard, it generates a template class derived from the WebService class when it creates an ASP.NET Web service project.
Parameters, return values, and headers do not contain XmlNode types or complex data types that when serialized violate a rule.
The Web service doesn't use any custom SoapExtension or IHttpHandler classes, or custom HttpModule assemblies to modify the HTTP or SOAP response.
The Web service doesn't use any custom SoapExtensionReflector classes to modify the way the WSDL is generated.

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

Compliant — this means that if the particular profile rule is applicable to your Web service, you do not need to make any code changes to meet the rule's requirements. Note that "weak" rules that contain SHOULD or MAY are classified as compliant when the Web service does not meet their requirements. This is because these rules aren't mandatory. For an example, see R2740.
Typically compliant — this means that if the particular profile rule is applicable to your Web service, 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 Web service, you will probably need to make code adjustments to make your Web service meet the rule's requirements.
Unique — this means that if the profile rule is applicable to your Web service, you will need to make code adjustments by using SoapExtension, HttpModule, or other unusual means to meet the rule's requirements.

All the rules 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. For the complete text, consult the WS-I Basic Profile at http://www.ws-i.org/Profiles/Basic/2002-10/BasicProfile-1.0-WGD.htm. 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:

Simple Object Access Protocol (SOAP) 1.1
Extensible Markup Language (XML) 1.0 (Second Edition)
RFC2616: Hypertext Transfer Protocol —HTTP/1.1
RFC2965: HTTP State Management Mechanism

XML Representation of SOAP Messages

This section includes the rules included 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

A .NET Web service automatically has built-in support for generating a WSDL 1.1 service description. If you invoke a .NET Web service using a normal HTTP GET request with a query string of ?WSDL, then it will use reflection on the WebService inherited class to generate a WSDL description.

R0002

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

Unique

This is not mandatory. When a .NET Web service generates a WSDL description, it does not support including any conformance claims.

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

When a .NET Web service generates a WSDL description, it does not support including any conformance claims.

R0004

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

Compliant

A .NET Web service properly handles a SOAP message that adheres to this rule.

R0005

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

Compliant

A .NET Web service properly handles a SOAP message that adheres to this rule.

R0006

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

Compliant

A .NET Web service properly handles a SOAP message that adheres to this rule.

R0007

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

Compliant

A .NET Web service properly handles a SOAP message that adheres to this rule.

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

The UDDI registration of a Web service is outside the scope of creating a Web service.

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

The UDDI registration of a Web service is outside the scope of creating a Web service.

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

The UDDI registration of a Web service is outside the scope of creating a Web service.

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

The UDDI registration of a Web service is outside the scope of creating a Web service.

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

The UDDI registration of a Web service is outside the scope of creating a Web service.

R4001

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

Compliant

A .NET Web service properly handles a SOAP message that adheres to this rule. A .NET Web service will handle a SOAP message that either does or does not include the BOM, as well as either UTF-8 (Universal Transformation Format) or UTF-16 encoding.

R1000

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

Typically Compliant

If, when an exception is thrown in a .NET Web service, the type of exception thrown does not inherit from the SoapException class, then the .NET runtime automatically wraps the exception in a SoapException. When serialized into a SOAP message, a SoapException only includes the faultcode, faultstring, detail, and, optionally, the faultactor elements. If you specify a detail parameter, you must make sure the main element is a detail element that contains your child nodes. Here is an example of how to do this:

XmlDocument doc = new XmlDocument();
// detail node is required to be the parent element
XmlNode detail = doc.CreateNode(XmlNodeType.Element, "detail", "");
detail.AppendChild(doc.CreateNode(XmlNodeType.Element, 
"MyElement", ""));
throw new SoapException("MyFault", SoapException.ServerFaultCode, 
"MyActor", detail);

R1001

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

Typically Compliant

If, when an exception is thrown in a Web service, the type of exception thrown does not inherit from the SoapException class, then the .NET runtime automatically wraps the exception in a SoapException. When serialized into a SOAP message, a SoapException does not qualify the element children of the soap:Fault element. If you specify a detail parameter, you must make sure not to specify a prefix for the main detail node. Here is an example illustrating what not to do:

XmlDocument doc = new XmlDocument();
// show incorrect specifying of a prefix for the detail node
XmlNode detail = doc.CreateNode(XmlNodeType.Element, "soap", 
"detail", "https://schemas.xmlsoap.org/soap/envelope/");
detail.AppendChild(doc.CreateNode(XmlNodeType.Element, 
"MyElement", ""));
throw new SoapException("MyFault", SoapException.ServerFaultCode, 
"MyActor", detail);

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

If you specify a detail parameter in the constructor of a SoapException, you can include child elements to the detail element but it is not required.

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 "https://schemas.xmlsoap.org/soap/envelope/".

Typically Compliant

If you specify a detail parameter in the constructor of a SoapException, you can include attributes with the detail element, as long as the namespace specified is not "https://schemas.xmlsoap.org/soap/envelope/". Here is an example of what not to do:

XmlDocument doc = new XmlDocument();
XmlNode detail = doc.CreateNode(XmlNodeType.Element, "detail", "");
detail.Attributes.Append(doc.CreateAttribute("soap", 
"MyAttribute", "https://schemas.xmlsoap.org/soap/envelope/"));
throw new SoapException("MyFault", SoapException.ServerFaultCode, 
"MyActor", detail);

R1016

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

Unique

The SoapException class does not support including an xml:lang attribute on the faultstring element in the SOAP response when an exception is thrown in a .NET Web service.

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

The SoapException class defines four constants that represent the four possible fault codes defined in SOAP 1.1. The constants are ClientFaultCode, MustUnderstandFaultCode, ServerFaultCode, and VersionMismatchFaultCode. Although it is not mandatory, you should pass one of these constants, or a namespace qualified fault code, as the code parameter of the constructor when you throw an exception. Here is an example using a SOAP 1.1 fault code:

throw new SoapException("MyFault", SoapException.ClientFaultCode);

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

Although it is not mandatory, when you throw a SoapException exception, avoid passing an XmlQualifiedName with a name property set to one of the fault codes defined in SOAP 1.1 that has been appended with an additional value as the code parameter of the constructor. Here is an example of what to avoid:

string code = SoapException.ClientFaultCode.Name + ".Type";
throw new SoapException("My Fault", new XmlQualifiedName(code));

R1005

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

Typically Compliant

To ensure that a .NET Web service does not require soap:encodingStyle attributes in the SOAP message, you must not use a SoapRpcMethodAttribute or SoapRpcServiceAttribute. Additionally, if the SoapDocumentMethodAttribute or SoapDocumentServiceAttribute is used, then the Use property must not be set to SoapBindingUse.Encoded.

R1006

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

Typically Compliant

R1007

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

Unique

A .NET Web service does not support an rpc-literal binding.

R1008

A MESSAGE MUST NOT contain a Document Type Declaration.

Compliant

A .NET Web service properly handles a SOAP message that adheres to this rule.

R1009

A MESSAGE MUST NOT contain Processing Instructions.

Compliant

A .NET Web service properly handles a SOAP message that adheres to this rule.

R1010

A RECEIVER MUST accept messages that contain an XML Declaration.

Compliant

A .NET Web service properly handles a SOAP message that adheres to this rule.

R1011

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

Compliant

A .NET Web service properly handles a SOAP message that adheres to this rule.

R1012

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

Compliant

A .NET Web service properly handles a SOAP message serialized using either UTF-8 or UTF-16 encoding.

R1018

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

Compliant

A .NET Web service properly handles 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

A .NET Web service properly handles a SOAP message that adheres to this rule.

R1014

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

Compliant

A .NET Web service properly handles a SOAP 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 "https://schemas.xmlsoap.org/soap/envelope/".

Compliant

If a .NET Web service receives a message whose Envelope element has a namespace other then "https://schemas.xmlsoap.org/soap/envelope/" it returns a SOAP fault with a faultstring stating there is a possible SOAP version mismatch.

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

A .NET Web service does not require that any elements in the request message assert their types using the xsi:type attribute. The element values sent in a request message are parsed and validated against the expected parameter type and a SOAP fault is returned if the value cannot be parsed.

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.

Potentially Compliant

A .NET Web service normally executes completely before checking if the mandatory headers were properly processed. If they were not, it returns a SOAP fault. The Web service determines whether a mandatory header is understood if either there is a SoapHeaderAttribute declared for the header or if the DidUnderstand property of the header is set to true. The following code demonstrates how to verify mandatory headers at the beginning of execution:

public MyHeaderType myHeader;
public SoapUnknownHeader[] unknownHeaders;

[WebMethod]
[SoapHeader("myHeader", Required=false)]
[SoapHeader("unknownHeaders", Required=false)]
public string HelloWorld()
{
    bool headersValid = true;

        // Check if known (declared) header
// is marked as mandatory
        if (myHeader.MustUnderstand == true)
        {
            // Validate the information in the
// known (declared) header
            if ((validation test of myHeader data) == false)
            {
                myHeader.DidUnderstand = false;
                headersValid = false;
            }
        }
        // Check for unknown headers marked as mandatory
        foreach (SoapUnknownHeader header in unknownHeaders)
        {
            if (header.MustUnderstand)
            {
                header.DidUnderstand = false;
                headersValid = false;
            }
        }
        if (headersValid == false)
        {
            // return before processing
            return null;
        }
        // Execute normal Web service processing here
}

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.

Compliant

A .NET Web service automatically generates a soap:MustUnderstand fault if the DidUnderstand property is false on any header that has a MustUnderstand property value of true.

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.

Compliant

Although it is not mandatory, when an exception is thrown in a .NET Web service it will automatically stop processing and execute any exception management code.

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.

Compliant

A .NET Web service returns a SOAP fault message when an exception is thrown.

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 a .NET Web service fails, the end user that initiated the activity that triggered calling the Web service should be notified of the failure.

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

A .NET Web service properly handles a message sent using HTTP/1.1.

R1141

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

Compliant

A .NET Web service properly handles a message sent using either HTTP/1.1 or HTTP/1.0.

R1107

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

Not Applicable

This rule is not applicable to creating a Web service.

R1132

A HTTP request MESSAGE MUST use the HTTP POST method.

Compliant

A .NET Web service properly handles a request that adheres to this rule.

R1108

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

Compliant

A .NET Web service properly handles a request 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

A .NET Web service properly handles a request 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.

Compliant

A .NET Web service does not respond with a Fault if the value of the SOAPAction HTTP header field is not quoted. Instead, it interprets the value exactly as if it were quoted.

R1110

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

Compliant

The TCP port that a .NET Web service responds to depends on the IIS (Internet Information Server) configuration settings. By default, IIS uses port 80 but you can change it to any valid TCP port.

R1124

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

Compliant

This is the default behavior of a .NET Web service.

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

This is the default behavior of a .NET Web service.

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

A .NET Web service returns a "202 Accepted" HTTP status code for a response that does not include a SOAP message. In the case of a one-way method, a SOAP message is not returned, as shown in the following example:

[WebMethod]
[SoapDocumentMethod(OneWay=true)]
public void Submit(string parameter)
{
  // Some action that does not require giving
  // any kind of response to caller
}

R1130

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

Potentially Compliant

To redirect a request in a .NET Web service, you must explicitly set the HTTP status code and add a Location HTTP header. Using the Response.Redirect method won't return the correct status code. Here's an example of how to do this:

[WebMethod]
public string HelloWorld()
{
  Context.Response.StatusCode = 307;
  Context.Response.AddHeader("Location","<redirect URL>");
  return null;
}

R1131

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

Not Applicable

This rule is not applicable to creating a Web service.

R1125

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

Unique

The default behavior of a .NET Web service is to return a 500 HTTP status code on any error result.

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

This is not mandatory. The default behavior of a .NET Web service is to return a 500 HTTP status code on any error result.

R1114

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

Compliant

This is not mandatory. The default behavior of a .NET Web service is to return a 500 HTTP status code on any error result. Also, the default behavior of a .NET Web service for an HTTP GET request returns information about the Web service.

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

This is not mandatory. The default behavior of a .NET Web service is to return a 500 HTTP status code on any error result.

R1126

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

Compliant

When an exception is thrown in a .NET Web service, it generates a SOAP fault as the response and sets the HTTP status code to "500 Internal Server Error."

R1120

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

Compliant

You can access the cookies collection in a Web service request with the Context property inherited from the WebService base class. The following example shows how to read a cookie using the Request property and how to return a cookie using the Response property:

[WebMethod]
public string HelloWorld()
{
 // Access a cookie passed in on the request
 HttpCookie myCookie = Context.Request.Cookies.Get("MyCookie");

 // Add a new cookie to be sent back in the response
 Context.Response.Cookies.Add(new HttpCookie("NewCookie","value"));

 return "Hello World";
}

R1122

An INSTANCE using Cookies SHOULD conform to RFC2965.

Compliant

The cookies support in a .NET Web service conforms to RFC2965.

R1121

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

Compliant

Although it is not mandatory, cookies should only be used to provide hints for such things as optimization and not to ensure that the Web service functions correctly.

R1123

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

Not Applicable

This rule is not applicable to creating a Web service.

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 "https://schemas.xmlsoap.org/wsdl/2003-02-11.xsd".

Compliant

A WSDL description generated by a .NET Web service 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 "https://schemas.xmlsoap.org/wsdl/soap/2003-02-11.xsd".

Compliant

A WSDL description generated by a .NET Web service adheres to this rule.

R2001

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

Compliant

A WSDL description generated by a .NET Web service adheres to this rule. A WSDL import statement is created if you declare and use an additional binding with a WebServiceBindingAttribute. When a WSDL description is generated for the following example, it will include a WSDL import statement that imports the WSDL description "https://www.contoso.com/MySevice.asmx?wsdl":

[WebService]
[WebServiceBinding(Name="RemoteBinding",
  Namespace="https://www.contoso.com/MyBinding",
  Location="https://www.contoso.com/MyService.asmx?WSDL")]
public class MyService
{
  [WebMethod]
  [SoapDocumentMethod(Binding="RemoteBinding")]
  public string HelloWorld()
  {
    return "Hello World";
  }
}

R2002

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

Typically Compliant

If you use a WebServiceBindingAttribute and do not specify the Location property or set the Location property to empty, it causes a WSDL import statement to be created for importing an XML Schema Definition. Here's an example of what not to do:

[WebService]
[WebServiceBinding(Name="RemoteBinding",
  Namespace="https://www.contoso.com/MyBinding",
  Location="")]
public class MyService
{
  [WebMethod]
  [SoapDocumentMethod(Binding="RemoteBinding")]
  public string HelloWorld()
  {
    return "Hello World";
  }
}

R2003

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

Compliant

A WSDL description generated by a .NET Web service adheres to this rule. A .NET Web service will not create an XML Schema "import" statement to import an externally defined XML Schema, but will create them for importing into the primary XML Schema definition the namespace of additional schemas defined within the types section.

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

R2009

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

Compliant

A WSDL description generated by a .NET Web service adheres to this rule. A .NET Web service will not include an XML Schema "import" statement for importing an externally defined schema.

R2010

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

Compliant

A WSDL description generated by a .NET Web service adheres to this rule. A .NET Web service will not include an XML Schema "import" statement for importing an externally defined schema.

R2011

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

Compliant

A WSDL description generated by a .NET Web service adheres to this rule. A .NET Web service will not include an XML Schema "import" statement for importing an externally defined schema.

R2007

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

Compliant

A WSDL description generated by a .NET Web service 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.

Not Applicable

This rule is not applicable to creating a Web service.

R2022

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

Compliant

A WSDL description generated by a .NET Web service 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

A WSDL description generated by a .NET Web service adheres to this rule.

R4004

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

Compliant

A WSDL description generated by a .NET Web service adheres to this rule.

R4002

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

Compliant

A WSDL description generated by a .NET Web service does not include a BOM.

R4003

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

Compliant

A WSDL description generated by a .NET Web service uses UTF-8 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.

Typically Compliant

A WSDL description generated by a .NET Web service includes a wsdl:import element when you use the WebServiceBindingAttribute. In this case, you must make sure to specify a value for the Namespace property and also ensure that the value matches the targetNamespace attribute on the wsdl:definitions element of the WSDL description specified by the Location property.

R2020

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

Compliant

A WSDL description generated by a .NET Web service does not include a wsdl:documentation element as a child of a wsdl:import element.

R2021

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

Compliant

A WSDL description generated by a .NET Web service does not include a wsdl:documentation element as a child of a wsdl:part element.

R2024

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

Compliant

A WSDL description generated by a .NET Web service does not include a wsdl:documentation element as a child of a wsdl:definitions element.

R2025

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

Compliant

A WSDL description generated by a .NET Web service 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

Although it is not mandatory, a WSDL Description generated by a .NET Web service does not include any extension elements with a wsdl:required attribute value of true.

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.

Not Applicable

This rule is not applicable to creating a Web service.

Types

This portion of the profile modifies and refers to WSDL 1.1, Section 2.2 (http://www.w3.org/TR/wsdl#_types), 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

A WSDL description generated by a .NET Web service 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

A WSDL description generated by a .NET Web service 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

A WSDL description generated by a .NET Web service adheres to this rule. A .NET Web service generates one xsd:schema element for each namespace specified for parameters, return values, or headers. The following example generates three xsd:schema elements with the specified namespaces in the WSDL:

[WebService(Namespace="MyNamespace1")]
public class MyService : System.Web.Services.WebService
{
  [WebMethod]
  [return: XmlElement(Namespace="MyNamespace2")]
  public string HelloWorld([XmlElement(Namespace="MyNamespace3")] 
string param1)
  {
   return "Hello World";
  }
}

R2110

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

Compliant

A WSDL description generated by a .NET Web service adheres to this rule.

R2111

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

Compliant

A WSDL description generated by a .NET Web service adheres to this rule.

R2112

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

Compliant

This is not mandatory. A WSDL description generated by a .NET Web service names the xsd:complexType element as ArrayOfXXX in an array declaration.

R2113

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

Compliant

A .NET Web service properly handles a SOAP 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

A WSDL description generated by a .NET Web service typically uses the namespace specified in the Namespace property of the WebServiceAttribute for both the WSDL definition and any schema definitions. The exception is if you specifically declare the namespace for a parameter or return value of a Web method by using XmlElementAttribute, XmlTypeAttribute, or a similar method.

Messages

This portion of the profile modifies and refers to WSDL 1.1, Section 2.3, which describes WSDL messages. A WSDL message is an abstract definition of the data, in the form of a message presented either as an entire document or as arguments to be mapped to a method invocation.

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

A WSDL description generated by a .NET Web service does not specify a parts attribute on the soapbind:body element(s).

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.

Typically Compliant

A WSDL description generated by a .NET Web service typically defines a single wsdl:part for a wsdl:message when using document-literal binding. The exception is if you use a SoapDocumentServiceAttribute or SoapDocumentMethodAttribute specifying the ParameterStyle property with a value of SoapParameterStyle.Bare, in which case it includes one wsdl:part for each parameter defined. When using SoapParameterStyle.Bare you must only have zero or one parameters. Here is an example of what not to do:

[WebMethod]
[SoapDocumentMethod(ParameterStyle=SoapParameterStyle.Bare)]
public string HelloWorld(string param1, string param2)
{
  return "Hello World";
}

R2202

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

Compliant

A WSDL description generated by a .NET Web service does not specify a parts attribute on the soapbind:body element(s).

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

A .NET Web service does not support generating a WSDL description with 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

A .NET Web service does not support generating a WSDL description with 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

A WSDL description generated by a .NET Web service adheres to this rule. A .NET Web service uses the elements attribute for all wsdl:parts defined in a wsdl:message, and only uses document-literal bindings.

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

A WSDL description generated by a .NET Web service 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

A WSDL description generated by a .NET Web service adheres to this rule. If a Webmethod has a SoapHeaderAttribute specified, then it generates a soapbind:header element and a separate wsdl:message from the wsdl:message created to define the wsdl:parts for the soapbind:body.

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

When a .NET Web service generates a WSDL description, it does not create soapbind:headerfault or soapbind:fault elements. If a Webmethod has a SoapHeaderAttribute specified, then it generates a soapbind:header element and a wsdl:message element specifically for the header that contains wsdl:parts defined using the element attribute.

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

Although it is not mandatory, a WSDL description generated by a .NET Web service defines only the wsdl:input and wsdl:output elements for a wsdl:operation in a wsdl:portType element. It also implicitly binds every part of a wsdl:message in that wsdl:portType by omitting a parts attribute on the soapbind:body element.

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

A WSDL description generated by a .NET Web service 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

A .NET Web service properly handles a SOAP message that adheres to this rule.

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

A WSDL description generated by a .NET Web service does not use the parameterOrder attribute on any wsdl:operation elements.

R2303

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

Compliant

A WSDL description generated by a .NET Web service adheres to this rule.

R2304

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

Compliant

If there are multiple WebMethods defined with the same name (that is, they are overloaded), the .NET Web service fails with an exception when it tries to generate the WSDL description. In the case of overloaded WebMethods, you must use the MessageName property of the WebMethod attribute to specify a distinct value that will be used as the operation name in the WSDL. Here is an example:

[WebMethod]
public string HelloWorld()
{
  return "Hello World";
}

[WebMethod(MessageName="HelloWorldMsg")]
public string HelloWorld(string msg)
{
  return "Hello World - " + msg;
}

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

A WSDL description generated by a .NET Web service does not use the parameterOrder attribute.

R2306

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

Compliant

A WSDL description generated by a .NET Web service adheres to this rule. When it generates a WSDL description, a .NET Web service uses the element attribute on a wsdl:part element.

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

A WSDL description generated by a .NET Web service 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

A WSDL description generated by a .NET Web service 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 "https://schemas.xmlsoap.org/soap/http".

Compliant

A WSDL description generated by a .NET Web service 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

By default, a WSDL description generated by a .NET Web service uses the "document" value for the style attribute. You must not use a SoapRpcMethodAttribute or SoapRpcServiceAttribute. If you do use a SoapRpcServiceAttribute but not any SoapDocumentMethodAttributes, or instead, use a SoapRpcMethodAttribute for all of your Webmethods, then you will be compliant with this rule but non-compliant with other rules.

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.

Typically Compliant

By default, a WSDL description generated by a .NET Web service uses the "literal" value for the use attribute on all soapbind:body and soapbind:header elements, and does not generate soapbind:headerfault elements. You must not use a SoapRpcMethodAttribute or SoapRpcServiceAttribute. If instead, you use either a SoapDocumentMethodAttribute or SoapDocumentServiceAttribute then you must not set the Use property to SoapBindingUse.Encoded.

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.

Not Applicable

This rule is not applicable to creating a Web service. A WSDL description generated by a .NET Web service always includes the use attribute for soapbind:body and soapbind:header elements, and does create soapbind:headerfault elements.

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

A WSDL description generated by a .NET Web service 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.

Typically Compliant

By default a WSDL description generated by a .NET Web service will have a wrapper element of the same name as the Webmethod to ensure the wire signature is unique. However, if you use a SoapDocumentMethodAttribute and set the ParameterStyle property to SoapParameterStyle.Bare, then you must ensure the parameters of your Webmethod are not identical to the parameters of any other Webmethod in your Web service.

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

Although it is not mandatory, a WSDL description generated by a .NET Web service 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

A .NET Web service properly handles a SOAP 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

A .NET Web service returns an empty HTTP response body for a Webmethod that is marked as one-way by using a SoapDocumentMethodAttribute with the OneWay property set to true. Here is an example:

[WebMethod]
[SoapDocumentMethod(OneWay=true)]
public void HelloWorld()
{
  // Some processing
}

R2750

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

Not Applicable

This rule is not applicable to creating a Web service. A .NET Web service does not return a SOAP response for a one-way operation.

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.

Not Applicable

This rule is not applicable to creating a Web service. A .NET Web service always returns a "202 Accepted" HTTP response for a one-way operation, even if an exception is thrown in that operation.

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

A WSDL description generated by a .NET Web service 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

A .NET Web service does not support generating a WSDL description with 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

A .NET Web service does not support generating a WSDL description with 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

A WSDL description generated by a .NET Web service 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

A WSDL description generated by a .NET Web service does not contain any soapbind:headerfault elements.

R2740

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

Compliant

This is not mandatory. A WSDL description generated by a .NET Web service does not include soapbind:fault elements.

R2741

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

Compliant

This is not mandatory. A WSDL description generated by a .NET Web service does not include soapbind:headerfault elements.

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

Because a WSDL description generated by a .NET Web service does not include wsdl:fault elements, any SOAP message returned containing a soap:Fault element is not described by the WSDL description.

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

A WSDL description generated by a .NET Web service does not contain wsdl:headerfault elements, but you can return fault detail elements in the SOAP header block by including a SoapHeaderAttribute with the Direction property set to SoapHeaderDirection.Fault.

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

A WSDL description generated by a .NET Web service 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

A WSDL description generated by a .NET Web service adheres to this rule.

R2721

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

Compliant

A WSDL description generated by a .NET Web service does not contain any soapbind:fault elements.

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

A WSDL description generated by a .NET Web service does not contain any wsdl:fault or soapbind:fault elements.

R2722

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

Compliant

A WSDL description generated by a .NET Web service does not contain any soapbind:fault elements.

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

A WSDL description generated by a .NET Web service does not contain any soapbind:fault elements.

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

A WSDL description generated by a .NET Web service does not contain any soapbind:fault elements.

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.

Compliant

This is not mandatory. A .NET Web service does not return a soap:Fault if the message is inconsistent with its WSDL description unless there are inconsistencies such as a method it does not recognize.

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.

Unique

A .NET Web service will automatically check first for a VersionMismatch error when validating the incoming message. It then automatically parses the message for header and parameter values and will return a Client error if the values cannot be parsed against the expected data types. Once those two automatic steps are completed, control is given to your Webmethod, where you must check first for MustUnderstand faults (reference rule 1025 for example).

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

A .NET Web service does not support an rpc-literal binding.

R2735

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

Unique

A .NET Web service does not support an rpc-literal binding.

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

A .NET Web service does not support an rpc-literal binding.

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.

Typically Compliant

A .NET Web service properly handles a SOAP message that adheres to this rule. However, you must not use a SoapHeaderAttribute with the Direction property set to SoapHeaderDirection.Fault. This is because the WSDL description includes a soapbind:header element on the wsdl:output, but the response message does not include a soap:header for it.

R2739

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

Compliant

A .NET Web service properly handles a SOAP message that adheres to this rule. SOAP headers that are passed in that have not been declared can be accessed by using a SoapHeaderAttribute with a variable declared as an array of type SoapUnknownHeader. Here is an example:

public SoapUnknownHeader[] unknownHeaders;

[WebMethod]
[SoapHeader("unknownHeaders", Required=false)]
public string HelloWorld()
{
// check the unknownHeaders array to see if any undeclared
// header blocks were passed in the SOAP message
}

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'.

Compliant

public SoapUnknownHeader[] unknownHeaders;

[WebMethod]
[SoapHeader("unknownHeaders", Required=false)]
public string HelloWorld()
{
    // Check for unknown headers marked as mandatory
    foreach (SoapUnknownHeader header in unknownHeaders)

    {
        if (header.MustUnderstand)
        {
        // Process SOAP header marked as mustUnderstand
        }
    }
}

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.

Compliant

A .NET Web service properly handles the SOAP header blocks regardless of the order.

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.

Compliant

A .NET Web service properly handles a SOAP message that adheres to this rule. When you use a SoapHeaderAttribute, any additional instances of that header beyond the first one in the SOAP message are treated as an unknown header and can be accessed by using a SoapHeaderAttribute with a variable declared as an array of type SoapUnknownHeader.

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

A .NET Web service properly handles an HTTP request message that adheres to this rule. A WSDL description generated by a .NET Web service includes a soapAction attribute on soapbind:operation elements.

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

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.

Not applicable

This rule is not applicable to creating a Web service. A WSDL description generated by a .NET Web service does not include wsdl:required attributes on WSDL 1.1 SOAP Binding extension elements.

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.

Not applicable

This rule is not applicable to creating a Web service. A WSDL description generated by a .NET Web service does not include wsdl:required attributes on soapbind extension elements.

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

A WSDL description generated by a .NET Web service adheres to this rule.

R2801

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

Compliant

A WSDL description generated by a .NET Web service 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

The UDDI registration of a Web service is outside the scope of creating a Web service.

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

The UDDI registration of a Web service is outside the scope of building a Web service.

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

The UDDI registration of a Web service is outside the scope of creating a Web service.

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

The UDDI registration of a Web service is outside the scope of creating a Web service.

R3011

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

Not Applicable

The UDDI registration of a Web service is outside the scope of creating a Web service.

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

To require the use of HTTPS for a .NET Web service, configure IIS by setting directory security to force SSL.

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

A WSDL description generated by a .NET Web service sets the URI of the location attribute on the soapbind:address element to "https" if, when querying for the WSDL description, https is used. Otherwise, the URI of the location attribute is "http". By setting directory security in IIS to force SSL, you force queries for the WSDL description to use https.

R5010

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

Compliant

To require use of HTTPS with mutual authentication for a .NET Web service, configure IIS by setting directory security to force SSL and to require client certificates.

Applying Basic Profile Rules When Implementing Web Services

Contents

R0001 © Profile rule number

Messaging

XML Representation of SOAP Messages

R0001

R0002

R0003

R0004

R0005

R0006

R0007

R3020

R3030

R3021

R3005

R3004

R4001

R1000

R1001

R1002

R1003

R1016

R1004

R1031

R1005

R1006

R1007

R1008

R1009

R1010

R1011

R1012

R1018

R1013

R1014

R1015

R1017

The Soap Processing Model

R1025

R1027

R1028

R1029

R1030

Using SOAP in HTTP

R1140

R1141

R1107

R1132

R1108

R1109

R1119

R1110

R1124

R1111

R1112

R1130

R1131

R1125

R1113

R1114

R1115

R1126

R1120

R1122

R1121

R1123

Service Description

Document Structure

R2028

R2029

R2001

R2002

R2003

R2004

R2009

R2010

R2011

R2007

R2008