This document is identified by a name in this case, Basic Profile and a version number here, 1. Together, they identify a particular profile instance. Version numbers are composed of a major and minor portion, in the form "major. They can be used to determine the precedence of a profile instance; a higher version number considering both the major and minor components indicates that an instance is more recent, and therefore supersedes earlier instances.
Instances of profiles with the same name e. One can also use this information to determine whether two instances of a profile are backwards-compatible; that is, whether one can assume that conformance to an earlier profile instance implies conformance to a later one.
Profile instances with the same name and major version number e. Note that this does not imply anything about compatibility in the other direction; that is, one cannot assume that conformance with a later profile instance implies conformance to an earlier one.
Conformance to the Profile is defined by adherence to the set of requirements defined for a specific target , within the scope of the Profile. This section explains these terms and describes how conformance is defined and used. Requirements state the criteria for conformance to the Profile. They typically refer to an existing specification and embody refinements, amplifications, interpretations and clarifications to it in order to improve interoperability.
All requirements in the Profile are considered normative, and those in the specifications it references that are in-scope see "Conformance Scope" should likewise be considered normative. When requirements in the Profile and its referenced specifications contradict each other, the Profile 's requirements take precedence for purposes of Profile conformance.
Requirement levels, using RFC language e. Each requirement is individually identified e. This requirement is identified by "R", applies to the target WIDGET see below , and places a conditional requirement upon widgets; i. Each requirement statement contains exactly one requirement level keyword e. The conformance target keyword appears in bold text e. Other conformance targets appearing in non-bold text are being used strictly for their definition and NOT as a conformance target.
Additional text may be included to illuminate a requirement or group of requirements e. Definitions of terms in the Profile are considered authoritative for the purposes of determining conformance. None of the requirements in the Profile, regardless of their conformance level, should be interpreted as limiting the ability of an otherwise conforming implementation to apply security countermeasures in response to a real or perceived threat e.
Conformance targets identify what artifacts e. This allows for the definition of conformance in different contexts, to assure unambiguous interpretation of the applicability of requirements, and to allow conformance testing of artifacts e. Requirements' conformance targets are physical artifacts wherever possible, to simplify testing and avoid ambiguity.
The scope of the Profile delineates the technologies that it addresses; in other words, the Profile only attempts to improve interoperability within its own scope. Generally, the Profile's scope is bounded by the specifications referenced by it. The Profile's scope is further refined by extensibility points.
Referenced specifications often provide extension mechanisms and unspecified or open-ended configuration parameters; when identified in the Profile as an extensibility point, such a mechanism or parameter is outside the scope of the Profile, and its use or non-use is not relevant to conformance. Note that the Profile may still place requirements on the use of an extensibility point.
Also, specific uses of extensibility points may be further restricted by other profiles, to improve interoperability when used in conjunction with the Profile. Because the use of extensibility points may impair interoperability, their use should be negotiated or documented in some fashion by the parties to a Web service; for example, this could take the form of an out-of-band agreement.
The Profile's scope is defined by the referenced specifications in Appendix A , as refined by the extensibility points in Appendix B.
Claims of conformance to the Profile can be made using the following mechanisms, as described in Conformance Claim Attachment Mechanisms , when the applicable Profile requirements associated with the listed targets have been met:. This section of the Profile incorporates the following specifications by reference, and defines extensibility points within them:. The following specifications or sections thereof are referred to in this section of the Profile :.
SOAP 1. The Profile mandates the use of that structure, and places the following constraints on its use:. While the combination of R and R below clearly imply that there may be at most one child element of the soap:Body , there is no explicit requirement in the Profile that articulates this constraint, leading to some confusion. The Profile requires that a fault be generated instead, to assure unambiguous operation. The use of unqualified element names may cause naming conflicts, therefore qualified names must be used for the children of soap:Body.
These requirements ensure that conformant artifacts have the broadest interoperability possible. The interpretation of sibling elements following the soap:Body element is unclear. Therefore, such elements are disallowed. This requirement clarifies a mismatch between the SOAP 1. The soap:encodingStyle attribute is used to indicate the use of a particular scheme in the encoding of data into XML.
However, this introduces complexity, as this function can also be served by the use of XML Namespaces. As a result, the Profile prefers the use of literal, non-encoded XML. The soap:mustUnderstand attribute has a restricted type of "xsd:boolean" that takes only "0" or "1".
Therefore, only those two values are allowed. In many cases, senders and receivers will share some form of type information related to the envelopes being exchanged. The following specifications or sections thereof are referred to in this section of the Profile:. In particular, it defines rules for the processing of header blocks and the envelope body.
It also defines rules related to generation of faults. The Profile places the following constraints on the processing model:. Mandatory header blocks are those children of the soap:Header element bearing a soap:mustUnderstand attribute with a value of "1". This requirement guarantees that no undesirable side effects will occur as a result of noticing a mandatory header block after processing other parts of the message. The Profile requires that receivers generate a fault when they encounter header blocks targeted at them, that they do not understand.
When a fault is generated, no further processing should be performed. In request-response exchanges, a fault message will be transmitted to the sender of the request, and some application level error will be flagged to the user. It is important to realize that generation of a Fault is distinct from its transmission, which in some cases is not required. Some consumer implementations erroneously use only the HTTP status code to determine the presence of a Fault.
Because there are situations where the Web infrastructure changes the HTTP status code, and for general reliability, the Profile requires that they examine the envelope. A Fault is an envelope that has a single child element of the soap:Body element, that element being a soap:Fault element. The children of the soap:Fault element are local to that element, therefore namespace qualification is unnecessary.
For extensibility, additional attributes are allowed to appear on the detail element and additional elements are allowed to appear as children of the detail element. Such children can be qualified or unqualified.
Faultstrings are human-readable indications of the nature of a fault. As such, they may not be in a particular language, and therefore the xml:lang attribute can be used to indicate the language of the faultstring. Use of this mechanism to extend the meaning of the SOAP 1. Therefore, its use should be avoided, as doing so may cause interoperability issues when the same names are used in the right-hand side of the ".
Alternatively, it is acceptable to define custom fault codes in a namespace controlled by the specifying authority. A number of specifications have already defined custom fault codes using the ". Despite this, their use in future specifications is discouraged. It is recommended that applications that require custom fault codes either use the SOAP1. The Profile mandates the use of that binding, and places the following constraints on its use:.
Several versions of HTTP are defined. The SOAP1. Because it is not deployed widely and also because its benefits to the use of SOAP are questionable, the Profile does not allow its use. SOAPAction is purely a hint to processors. All vital information regarding the intent of a message is carried in soap:Envelope. HTTP uses the 2xx series of status codes to communicate success. In particular, is the default for successful messages, but can be used to indicate that a message has been submitted for processing.
Additionally, other 2xx status codes may be appropriate, depending on the nature of the HTTP interaction. Despite the fact that the HTTP 1. The Profile accepts both status codes because some SOAP implementations have little control over the HTTP protocol implementation and cannot control which of these response status codes is sent. There are interoperability problems with using many of the HTTP redirect status codes, generally surrounding whether to use the original method, or GET.
The Profile mandates " Temporary Redirect", which has the semantic of redirection with the same HTTP method, as the correct status code for redirection. For more information, see the 3xx status code descriptions in RFC RFC notes that user-agents should not automatically redirect requests; however, this requirement was aimed at browsers, not automated processes which many Web services will be.
Therefore, the Profile allows, but does not require, consumers to automatically follow redirections. HTTP uses the 4xx series of status codes to indicate failure due to a client error. Although there are a number of situations that may result in one of these codes, the Profile highlights those when the HTTP request does not have the proper media type, and when the anticipated method "POST" is not used.
Note that these requirements do not force an instance to respond to requests. In some cases, such as Denial of Service attacks, an instance may choose to ignore requests.
Also note that SOAP 1. This profile doesn't change that requirement. Being designed for hypertext browsing, Cookies do not have well-defined semantics for Web services, and, because they are external to the envelope, are not accommodated by either SOAP 1. However, there are situations where it may be necessary to use Cookies; e. For these reasons, the Profile limits the ways in which Cookies can be used, without completely disallowing them.
The Profile recommends that cookies not be required by instances for proper operation; they should be a hint, to be used for optimization, without materially affecting the execution of the Web service. However, they may be required in legacy integration and other exceptional use cases, so requiring them does not make an instance non-conformant.
While Cookies thus may have meaning to the instance, they should not be used as an out-of-bound data channel between the instance and the consumer.
Therefore, interpretation of Cookies is not allowed at all by the consumer - it is required to treat them as opaque i. An instance of a Web service is required to make the contract that it operates under available in some fashion.
This means that if an authorized consumer requests a service description of a conformant service instance, then the service instance provider must make the WSDL document, the UDDI binding template, or both available to that consumer.
A service instance may provide run-time access to WSDL documents from a server, but is not required to do so in order to be considered conformant. Similarly, a service instance provider may register the instance provider in a UDDI registry, but is not required to do so to be considered conformant.
In all of these scenarios, the WSDL contract must exist, but might be made available through a variety of mechanisms, depending on the circumstances.
WSDL 1. The Profile references new schema documents that have incorporated fixes for known errors. Some examples in WSDL 1. The Profile clarifies use of the import mechanisms to keep them consistent and confined to their respective domains. Imported schema documents are also constrained by XML version and encoding requirements consistent to those of the importing WSDL documents. Although the wsdl:import statement is modeled after the xsd:import statement, the location attribute is required by wsdl:import while the corresponding attribute on xsd:import , schemaLocation is optional.
Consistent with location being required, its content is not intended to be empty. The value of the location attribute of a wsdl:import element is a hint. Example 3 in WSDL 1. Neither WSDL 1. This requirement ensures that conformant artifacts have the broadest interoperability possible. This is the final Functional Specification for version 1. English: htm 4. This updated version is designed to test the Basic Profile 1.
This the final Functional Specification for version 1. English: htm 15K. The list of known issues for the WS-I test tools is available here. English: xml K. Failure Message: A xsd:schema element contained in a wsdl:types element does not have a targetNamespace attribute with a valid and non-null value, while having child element s other than xsd:import or xsd:annotation. Failure Detail Description: Defective xsd:schema element s.
Context: For a candidate wsdl:types. Assertion Description: The type soapenc:Array does not appear in these declarations, and the wsdl:arrayType attribute is not used in the type declaration. Failure Message: An Array declaration uses - restricts or extends - the soapenc:Array type, or the wsdl:arrayType attribute is used in the type declaration. Failure Detail Description: Defective declaration s. Comments: R and R have been interpreted as applying to any declaration, as we cannot assume the intent of declaring arrays, which is untestable.
Context: For a candidate wsdl:types that is used by an rpc-literal binding. Comments: R has been interpreted as applying to any declaration, as we cannot assume the intent of declaring arrays, which is untestable.
However, R should only concern "wrapper elements", i. RPC-lit cases. The narrowing of the context here, is not sufficient to restrict properly the application of this TA. Context: For a candidate wsdl:binding, which contains a document-literal soap:binding.
Assertion Description: If the "parts" attribute is present, then the soapbind:body element s have at most one part listed in the parts attribute. Failure Message: One or more soapbind:body element s in a document-literal soap:binding does not have at most one part listed in the parts attribute. Failure Detail Description: Defective soapbind:body element s. Context: For a candidate wsdl:binding, with a style "rpc" attribute and containing at least a soapbind:body element.
Assertion Description: No wsdl:part referred by such a soapbind:body element is defined using the "element" attribute. Failure Message: The referred wsdl:part element uses the "element" attribute in an rpc-literal soapbind:body. Assertion Description: When they contain references to message parts, the soapbind:header, soapbind:headerfault and soapbind:fault elements only refer to wsdl:part element s that have been defined using the "element" attribute.
Failure Message: The soapbind:header, soapbind:headerfault or soapbind:fault elements refer to wsd:part element s that are not defined using only the "element" attribute. Failure Detail Description: Defective wsdl:binding and wsdl:part elements. Context: For a candidate wsdl:message. Assertion Description: An "element" attribute on any wsdl:part element refers to a global element declaration. Failure Message: A wsdl:message element containing a wsdl:part element that uses the "element" attribute does not refer, via that attribute, to a global element declaration.
Failure Detail Description: Defective wsdl:message element. Context: For a candidate wsdl:message element. Assertion Description: The wsdl:message element does not contain part elements that use both "type" and "element" attributes. Failure Message: A wsdl:message element has at least one wsdl:part element that contains both type and element attributes. Context: For a candidate wsdl:binding element, referred to by an rpc-literal soap:binding.
Assertion Description: The rpc-literal binding does not have a namespace attribute specified on a contained soapbind:header, soapbind:headerfault, and soapbind:fault element. Failure Message: An rpc-literal binding has the namespace attribute specified on contained soapbind:header, soapbind:headerfault and soapbind:fault elements. Assertion Description: The list or set of wsdl:operation elements for the contained wsdl:binding is the same as the list of wsdl:operations for the referred wsdl:portType.
Failure Message: A wsdl:binding does not have the same list of wsdl:operations as the wsdl:portType to which it refers. Assertion Description: Every wsdl:part from each wsdl:message in the associated wsdl:portType is referenced either by the soapbind:body, soapbind:header, soapbind:fault, or soapbind:headerfault.
Failure Message: A wsdl:binding does not 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. Context: For a candidate wsdl:binding, which is of type document-literal. Assertion Description: If it does not specify the parts attribute on a soapbind:body element, the corresponding abstract wsdl:message defines zero or one wsdl:part. Failure Message: A document-literal binding which does not specify the parts attribute, has more than one wsdl:part in the associated wsdl:message element.
Failure Detail Description: Defective wsdl:binding element. Assertion Description: Each operation referenced by the binding results in a unique wire signature. Failure Message: A binding has operations that are not unique. Failure Detail Description: Defective wsdl:operation element s. Context: For a candidate wsdl:types element.
Failure Message: A wsdl:types element contained a data type definition that is not an XML schema definition. Failure Detail Description: Defective data type definition. Comments: Validating the data type definitions includes any imported XML schema definitions. Context: For a candidate wsdl:definitions, if it contains a wsdl:port, wsdl:binding, wsdl:portType, wsdl:operation, or wsdl:message that claims conformance to the Profile.
Failure Message: An extension element within a WSDL element that claims conformance to the Basic Profile has a wsdl:required attribute with a value of "true". Failure Detail Description: Display the extension element that failed the assertion. Comments: Extension elements other than those belonging to one of the following namespaces Context: For a candidate wsdl:import element, where the location attribute or the namespace attribute has a value that is a relative URI, or a for soap:address element where the location attribute is a relative URI.
Assertion Description: The use of a relative URI as the value for a wsdl:import location or namespace attribute, or for a soap:address location attribute may require out of band coordination.
Detail Description: The element s in question. Context: For an XML schema definition defined in the wsdl:types element, or imported directly or indirectly by a schema definition defined in the wsdl:types element, which contains any schema annotation elements.
Assertion Description: An XML schema definition defined in the wsdl:types element, or imported directly or indirectly by a schema definition defined in the wsdl:types element, may use schema annotation elements as an extensibility mechanism.
Detail Description: The annotation elements included in the schema. Comments: Schema annotations are an extensibility point. Assertion Description: Not testable. For example, some of these test assertions represent capabilities which can not be validated. Note, R could be tested.
If a request is inconsistent with the WSDL for the request, we could flag returning a non-error response. We currently do not check the status of a request when we are processing the response.
Context: For a candidate request message in the message log file. Context: For a candidate response message in the message log file, which is bound to a One-Way wsdl:operation. Comments: Need the request to determine if it is a One-Way. We could have targeted the request as well as primary entry , and correlate with the response.
Failure Detail Description: Complete message. Comments: This test assertion is targeted at one-way operations. Failure Detail Description: Both the request and response message. Context: For a candidate message in the message log file containing an HTTP Authentication header field with an authentication mechanism other than "Basic" or "Digest".
Detail Description: HTTP authentication allows for extension schemes, arbitrary digest hash algorithms and parameters. Comments: If all HTTP headers in a message are in the standardized list of draft-nottingham-http-header-reg it will cause the informationalassertion to be notApplicable; otherwise will pass and headers not in the draft-nottingham-http-header-reg will be listed. Context: For a candidate message in the message log file containing a Content-encoding HTTP header field with a value other than "gzip", "compress" or "deflate".
Comments: Any Content-encoding header field with a value other than the specified list is considered to be an extensibility point.
Context: For a candidate response message in the message log file containing a transfer-encoding HTTP header field with a value other than "chunked". Detail Description: Any Transfer-encoding header field with a value other than chunked is considered to be an extensibility point.
Comments: Any Transfer-encoding header field with a value other than chunked is considered to be an extensibility point. Comments: All of these profile requirements are NOT testable. Some of these test assertions represent capabilities which can not be validated. SOAP 1. The profile mandates the use of that structure. Context: For a candidate response envelope containing a soap:Fault element.
Assertion Description: The contained soap:Fault element is defined in the wsdl:binding. Failure Detail Description: Undefined soap:Fault element s. Context: For a candidate envelope containing a soap:Body element. Assertion Description: No child element of soap:Body has a soap:encodingStyle attribute. Failure Message: A child of the soap:Body element has a soap:encodingStyle attribute. Context: For a candidate envelope in a request message. In case of a doc-lit binding, the child element of soap:body is an instance of the global element declaration referenced by the corresponding wsdl:part.
If the message has "parts", the order of the part elements in the soap:body of the wired message, is same as that of the wsdl:partS, in the wsdl:message that describes it for each of the wsdl:part elements bound to the envelope's corresponding soapbind:body element.
0コメント