Basic Profile - = Version 1.0 (WGD)

This document defines the WS-I Basic Profile, consisting of a set of=20 non-proprietary Web services specifications, along with clarifications = and=20 amendments to those specifications which promote interoperability.

Status of this Document

This document is a Working Group Draft; it has been accepted by the = Working=20 Group as reflecting the current state of discussions. It is a work in = progress,=20 and should not be considered authoritative or final; other documents may = supercede this document.

The Working Group believes this Working Group Draft to be = substantively=20 complete with regards to the technical refinements, clarifications and=20 constraints specified. The Working Group will be publishing another = Working=20 Group Draft reflecting the remaining issue resolutions, additional = rationale=20 text, and editorial changes within the next month, and intends to pursue = an=20 aggressive schedule for completion of its work. Therefore, the Working = Group=20 invites all parties interested in contributing to the review and = feedback=20 process of the Basic Profile v1.0 to do so based on this version so that = any=20 technical concerns expressed can be considered by the Working Group = before it=20 concludes its formal review period.

Notice

The material contained herein is not a license, either expressly or=20 impliedly, to any intellectual property owned or controlled by any of = the=20 authors or developers of this material or WS-I. The material contained = herein is=20 provided on an "AS IS" basis and to the maximum extent permitted by = applicable=20 law, this material is provided AS IS AND WITH ALL FAULTS, and the = authors and=20 developers of this material and WS-I hereby disclaim all other = warranties and=20 conditions, either express, implied or statutory, including, but not = limited to,=20 any (if any) implied warranties, duties or conditions of = merchantability, of=20 fitness for a particular purpose, of accuracy or completeness of = responses, of=20 results, of workmanlike effort, of lack of viruses, and of lack of = negligence.=20 ALSO, THERE IS NO WARRANTY OR CONDITION OF TITLE, QUIET ENJOYMENT, QUIET = POSSESSION, CORRESPONDENCE TO DESCRIPTION OR NON-INFRINGEMENT WITH = REGARD TO=20 THIS MATERIAL.

IN NO EVENT WILL ANY AUTHOR OR DEVELOPER OF THIS MATERIAL OR WS-I BE = LIABLE=20 TO ANY OTHER PARTY FOR THE COST OF PROCURING SUBSTITUTE GOODS OR = SERVICES, LOST=20 PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY INCIDENTAL, CONSEQUENTIAL, = DIRECT,=20 INDIRECT, OR SPECIAL DAMAGES WHETHER UNDER CONTRACT, TORT, WARRANTY, OR=20 OTHERWISE, ARISING IN ANY WAY OUT OF THIS OR ANY OTHER AGREEMENT = RELATING TO=20 THIS MATERIAL, WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE = POSSIBILITY=20 OF SUCH DAMAGES.

Feedback

The Web Services-Interoperability Organization (WS-I) would like to = receive=20 input, suggestions and other feedback ("Feedback") on this work from a = wide=20 variety of industry participants to improve its quality over time.

By sending email, or otherwise communicating with WS-I, you (on = behalf of=20 yourself if you are an individual, and your company if you are providing = Feedback on behalf of the company) will be deemed to have granted to = WS-I,the=20 members of WS-I, and other parties that have access to your Feedback, a=20 non-exclusive, non-transferable, worldwide, perpetual, irrevocable, = royalty-free=20 license to use, disclose, copy, license, modify, sublicense or otherwise = distribute and exploit in any manner whatsoever the Feedback you provide = regarding the work. You acknowledge that you have no expectation of=20 confidentiality with respect to any Feedback you provide. You represent = and=20 warrant that you have rights to provide this Feedback, and if you are = providing=20 Feedback on behalf of a company, you represent and warrant that you have = the=20 rights to provide Feedback on behalf of your company. You also = acknowledge that=20 WS-I is not required to review, discuss, use, consider or in any way = incorporate=20 your Feedback into future versions of its work. If WS-I does incorporate = some or=20 all of your Feedback in a future version of the work, it may, but is not = obligated to include your name (or, if you are identified as acting on = behalf of=20 your company, the name of your company) on a list of contributors to the = work.=20 If the foregoing is not acceptable to you and any company on whose = behalf you=20 are acting, please do not provide any Feedback.

1. Introduction
1.1. Guiding=20 Principles
1.2. Notational=20 Conventions
2. Profile=20 Conformance
2.1. Conformance=20 of Artifacts
2.2. Conformance=20 of Services and Consumers
2.3. Conformance=20 Annotation
3. Messaging
3.1. XML=20 Representation of SOAP Messages
3.2. = The=20 SOAP Processing Model
3.3. Using=20 SOAP in HTTP
4. Service=20 Description
4.1. Document=20 Structure
4.2. Types
4.3. Messages
4.4. Port=20 Types
4.5. Bindings
4.6. Ports
4.7. Services
4.8. SOAP=20 Binding
4.9. XML=20 Schema
5. Service=20 Publication and Discovery
5.1. bindingTemplates
5.2. tModels
6.=20 Security
6.1. The=20 Use of HTTPS
6.2. Certificate=20 Authority
6.3. Permitted=20 HTTPS Encryption Algorithms

1. Introduction

Section 1 introduces the profile, its scope, and the philosophy that = it takes=20 to interoperability.

Section 2, "Profile Conformance," explains what it means to be = conformant to=20 the Basic Profile. Each subsequent section addresses a component = specification=20 of the Profile, and consists of two parts; an overview of the approach = to the=20 specification taken, followed by subsections which address individual = parts of=20 the component specification.

1.1 Guiding Principles

The Basic Profile was developed according to a set of principles = that,=20 together, form the philosophy of the profile, as it relates to bringing = about=20 interoperability. This section documents these guidelines.

1.2 Notational Conventions

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", = "SHOULD",=20 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are = to be=20 interpreted as described in RFC2119.

Normative statements in the profile (i.e., those impacting = conformance, as=20 outlined in section 3) are presented in the following manner:

where "nnnn" is replaced by the statement number. Each statement will = contain=20 exactly one requirement level keyword (e.g., "MUST") and one conformance = target=20 keyword (e.g., "MESSAGE").

Some statements clarify the referenced specification(s), but do not = place=20 additional constraints upon implementations. For convenience, = clarifications are=20 annotated in the following manner: C =

Some statements are derived from ongoing standardization work on the=20 referenced specification(s). For convenience, forward-derived statements = are=20 annotated in the following manner: xxxx,=20 where "xxxx" is an identifier for the specification (e.g., "SOAP12" for = SOAP=20 Version 1.2, currently under development). Note that because such work = is not=20 complete, the specification which the requirement is derived from may = change;=20 this information is included only as a convenience to implementers.

This specification uses a number of namespace prefixes throughout; = their=20 associated URIs are listed below. Note that the choice of any namespace = prefix=20 is arbitrary and not semantically significant.

2. Profile Conformance

Conformance to the Basic Profile is defined by adherence to the=20 specifications on which the profile is based (as outlined in the = remainder of=20 the document), subject to the refinements, interpretations, and = clarifications=20 set forth.

To allow the description of conformance in different contexts, the = profile=20 defines a number of conformance targets, allowing the = conformance=20 testing and certification of artifacts (such as SOAP messages and WSDL=20 descriptions), Web services themselves, and software that is used in = conjunction=20 with a conformant Web Service.

The criteria for conformance is defined by requirement = statements,=20 which are associated with conformance targets (denoted with capital = letters,=20 e.g., MESSAGE) and use requirement levels (using RFC2119 language, e.g., = MUST)=20 to indicate the nature of the requirement. Requirement statements are=20 individually identified (e.g., r999) for convenience. Additional text = may be=20 included to illuminate the requirements (e.g., rationale and examples); = however,=20 requirement statements alone should be considered in determining=20 conformance.

The sections below describe this profile's conformance targets, from = the=20 basic artifacts (upon which requirements are directly placed) to the = conformance=20 of services and software, which is derived from these artifacts and = additional=20 requirements.

2.1 Conformance of Artifacts

The most basic level of conformance is that of an artifact. This = profile=20 makes requirement statements about three kinds of artifacts;

An instance of an artifact is considered conformant when all of the=20 requirements associated with it are met.

2.2 Conformance of Services and = Consumers

A deployed instance of a Web service (as specified by wsdl:port or=20 uddi:bindingTemplate) is considered conformant if it produces only = conformant=20 artifacts, and is capable of consuming conformant artifacts, as = appropriate.=20 Note that this means that where multiple conformant artifacts are = possible, a=20 conformant service must be able to consume them all (e.g., while a = sender might=20 choose whether to encode XML in UTF-8 or UTF-16 when sending a message, = a=20 receiver must be capable of using either).

Conformant Web service instances must comply with all requirement = statements=20 associated with INSTANCE.

Similarly, a consumer of a service instance is considered conformant = if it=20 produces only conformant artifacts and is capable of consuming = conformant=20 artifacts, as appropriate.

Conformant consumers must comply with all requirements statements = associated=20 with CONSUMER.

Both conformant Web service instances and consumers must comply, as=20 appropriate, with all of the requirement statements associated with:

Note that conformance does not apply to wsdl:service elements; only = wsdl:port=20 elements are considered when determining conformance of instances. = Therefore,=20 the profile places no constraints on wsdl:service definitions. In = particular,=20 they can have more multiple ports, each of which may or may not be=20 conformant.

Types of Web services (as specified by wsdl:binding and = wsdl:portType) are=20 considered conformant if, when deployed with due consideration, they = produce=20 conformant instances.

Additionally, an instance of a Web service is required to make the = contract=20 that it operates under available in some fashion.

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

"described," in this context, means that if an authorized consumer = requests a=20 service description of a conformant service instance, then the service = instance=20 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=20 WSDL documents from a server, but is not required to do so in order to = be=20 considered conformant. Similarly, a service instance provider may = register the=20 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,=20 but might be made available through a variety of mechanisms, depending = on the=20 circumstances.

2.3 Conformance Annotation

To allow services to advertise conformance to the Profile, = conformance=20 claims regarding instances can be placed at the appropriate place = in a=20 service's WSDL description. Claims can be associated with a particular = element=20 (e.g., portType) to scope them to that construct.

R0002=20 DESCRIPTIONs MAY contain conformance claims regarding instances, as = specified in=20 the conformance claim schema.

R0003=20 DESCRIPTIONs' conformance claims MUST be children of the documentation = element=20 of each of the wsdl elements: port, binding, portType, operation and=20 message.

A conformance claim on an element means that the element (and the = instance it=20 represents, in the case of a port) is conformant to the profile it = claims to=20 obey (as relevant to the type of element).

A conformance claim on an element also implies that the same claim is = made=20 for all the elements that it uses, based on the following transitivity = rules,=20 applied recursively:

A claim on a port is inherited by the referenced binding=20
A claim on a binding is inherited by the referenced portType=20
A claim on a portType is inherited by the referenced operations=20
A claim on an operation is inherited by the referenced messages =

The conformance claim schema is:

<?xml version=3D"1.0" encoding=3D"UTF-8"?>=20
<xs:schema xmlns:xs=3D"http://www.w3.org/2001/XMLSchema"=20
           targetNamespace=3D"http://ws-i.org/schemas/conformanceClaim/"
           xmlns:tns=3D"http://ws-i.org/schemas/conformanceClaim/"=20
           elementFormDefault=3D"qualified"=20
           attributeFormDefault=3D"unqualified" >=20
    <xs:element name=3D"Claim" >=20
        <xs:complexType>=20
            <xs:sequence>=20
                <xs:any namespace=3D"##any" =
processContents=3D"lax"/>=20
            </xs:sequence>=20
            <xs:attribute name=3D"conformsTo" type=3D"xs:anyURI"/> =

            <xs:anyAttribute namespace=3D"##any" =
processContents=3D"lax"/>=20
        </xs:complexType>=20
    </xs:element>=20
</xs:schema>

CORRECT: 

<wsdl:definitions xmlns:wsdl=3D"http://schemas.xmlsoap.org/wsdl"=20
                  xmlns:tns=3D"http://example.org/myservice"
                  targetNamespace=3D"http://example.org/myservice">=20
    <wsdl:portType name=3D"MyPortType">=20
        ...=20
    </wsdl:portType>=20
    <wsdl:binding name=3D"MyBinding" portType=3D"MyPortType">=20
        ...=20
    </wsdl:binding>=20
    <wsdl:service name=3D"MyService">=20
        <wsdl:port name=3D"MyPort" binding=3D"tns:MyBinding">=20
            <wsdl:documentation>
              <wsi:Claim =
conformsTo=3D"http://ws-i.org/profiles/basic1.0/"/>=20
            </wsdl:documentation>
            <soap:address =
location=3D"http://example.org/myservice/myport"/>=20
        </wsdl:port>=20
    </wsdl:service>=20
</wsdl:definitions>=20

Editors' note:The editors have an = outstanding=20 action item to obtain a URI for use in conjunction with conformance=20 claims.

3. Messaging

This portion of the profile incorporates the following specifications = by=20 reference;

3.1 XML Representation of SOAP Messages

This portion of the profile modifies and refers to the following=20 specifications (or sections thereof);

SOAP 1.1 defines an XML-based structure for transmitting messages. = This=20 profile mandates the use of that structure, and places the following = constraints=20 on its use:

The XML specification allows UTF-8 encoding to include a BOM; = therefore,=20 receivers of messages must be prepared to accept them. The BOM is = mandatory for=20 XML encoded as UTF-16.

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

For interoperability the content of the soap:Fault = element is=20 restricted to those elements explicitly described in the SOAP 1.1=20 specification.

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

INCORRECT: 
<soap:Fault =
xmlns:soap=3D'http://schemas.xmlsoap.org/soap/envelope/' >
  <faultcode>soap:Client</faultcode>
  <faultstring>Invalid message format</faultstring>
  <faultactor>http://example.org/someactor</faultactor>
  <detail>There were <b>lots</b> of elements in the =
message=20
  that I did not understand
  </detail>
  <m:Exception xmlns:m=3D'http://example.org/faults/exceptions' >
    <m:ExceptionType>Severe</m:ExceptionType>
  </m:Exception>
</soap:Fault>

CORRECT: 
<soap:Fault =
xmlns:soap=3D'http://schemas.xmlsoap.org/soap/envelope/' >
  <faultcode>soap:Client</faultcode>
  <faultstring>Invalid message format</faultstring>
  <faultactor>http://example.org/someactor</faultactor>
  <detail>There were <b>lots</b> of elements in the =
message
   that I did not understand
   </detail>
</soap:Fault>

The children of the soap:Fault element are local to that = element=20 and do not need to be namespace qualified.

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

INCORRECT: 
<soap:Fault =
xmlns:soap=3D'http://schemas.xmlsoap.org/soap/envelope/' >
  <soap:faultcode>soap:Client</soap:faultcode>
  <soap:faultstring>Invalid message =
format</soap:faultstring>
  =
<soap:faultactor>http://example.org/someactor</soap:faultactor&g=
t;
  <soap:detail>There were <b>lots</b> of elements in =
the message=20
  that I did not understand
  </soap:detail>
</soap:Fault>

CORRECT: 
<soap:Fault =
xmlns:soap=3D'http://schemas.xmlsoap.org/soap/envelope/'=20
			xmlns=3D'' >
  <faultcode>soap:Client</faultcode>
  <faultstring>Invalid message format</faultstring>
  <faultactor>http://example.org/someactor</faultactor>
  <detail>There were <b>lots</b> of elements in the =
message=20
  that I did not understand
  </detail>
</soap:Fault>

For extensibility, additional attributes are allowed to appear on the = detail=20 element and additional elements are allowed to appear as children of the = detail=20 element .

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

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

To help internationalization the language of faultstrings may be=20 indicated.

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

Custom fault codes must not appear inside the faultcode = element;=20 for interoperability, a fixed set of fault codes is needed.

R1004 When=20 a MESSAGE contains a faultcode element the content of that = element=20 MUST be one of the fault codes defined in the SOAP 1.1 specification. =

INCORRECT: 
<soap:Fault =
xmlns:soap=3D'http://schemas.xmlsoap.org/soap/envelope/'
            xmlns:c=3D'http://example.org/faultcodes' >
  <faultcode>c:ProcessingError</faultcode>
  <faultstring>An error occurred while processing the message
  </faultstring>
</soap:Fault>

CORRECT: 
<soap:Fault =
xmlns:soap=3D'http://schemas.xmlsoap.org/soap/envelope/' >
  <faultcode>soap:Server</faultcode>
  <faultstring>An error occurred while processing the message
  </faultstring>
</soap:Fault>

For interoperability, literal XML is preferred.

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

R1006 A=20 MESSAGE MUST NOT contain soap:encodingStyle attributes on = any=20 element which is a child of soap:Body.

R1007 A=20 MESSAGE MUST NOT contain soap:encodingStyle attributes on = any=20 elements which are grandchildren of soap:Body.

For interoperability, security and ease of processing these XML = constructs=20 are disallowed.

R1008 A=20 MESSAGE MUST NOT contain a Document Type Declaration. C

R1009 A=20 MESSAGE MUST NOT contain Processing Instructions. C

Presence or absence of such a declaration does not affect = interoperability.=20 Certain implementations might always precede their XML serialization = with the=20 XML declaration.

R1010 A=20 RECEVIER MUST accept messages that contain an XML Declaration. C

This requirement clarifies a mismatch between the SOAP 1.1 = specification and=20 the associated XML Schema document

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

INCORRECT: 
<soap:Envelope =
xmlns:soap=3D'http://schemas.xmlsoap.org/soap/envelope/' >
  <soap:Body>
    <p:Process xmlns:p=3D'http://example.org/Operations' />
  </soap:Body>
  <m:Data xmlns:m=3D'http://example.org/information' >
  Here is some data with the message
  </m:Data>
</soap:Envelope>

CORRECT: 
<soap:Envelope =
xmlns:soap=3D'http://schemas.xmlsoap.org/soap/envelope/' >
  <soap:Body>
    <p:Process xmlns:p=3D'http://example.org/Operations' >
	  <m:Data xmlns:m=3D'http://example.org/information' >
  Here is some data with the message
      </m:Data>
    </p:Process>
  </soap:Body>
</soap:Envelope>

All XML Processors must support UTF-8 and UTF-16, per the XML 1.0=20 specification so requiring these encodings places no burden on = implementations=20 and aids interoperability.

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

The soap:mustUnderstand attribute has a type of = xsd:boolean=20 which allows all four lexical forms but for compatibility only two are = allowed.=20

R1013=20 MESSAGEs containing a soap:mustUnderstand attribute MUST = only use=20 the lexical forms 0 and 1. C

The interpretation of unqualified element names is ambiguous, = therefore=20 qualified names must be used.

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

SOAP 1.1 only stated that the message be discarded in such cases. For = interoperability faults must be generated instead.

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

In many cases senders and receivers will share some form of type = information=20 related to the messages being exchanged. xsi:type is only needed where = no such=20 schema exists, that is where both sides are assuming that all exchanged = items=20 are xs:anyType.

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

3.2 The SOAP Processing Model

This portion of the profile modifies and refers to the following=20 specifications (or sections thereof);

SOAP 1.1 defines a message exchange model for processing of messages. = This=20 profile places the following constraints on that model:

This guarantees that no undesirable side-effects will occur as a = result of=20 noticing a mandatory header AFTER processing other parts of the message. =

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

soap:actor is used to target header blocks at = intermediaries.=20 The SOAP specification has nothing to say about its value.

R1026 The=20 value of the soap:actor attribute in a MESSAGE is a private = agreement between the sender and the receiver of the header carrying the = attribute. C

Editors' note:This statement isn't = really a=20 requirement; it might become a Best Practice.

Requiring that receivers generate faults ensures that mandatory = headers are=20 not silently and erroneously ignored.

R1027 A=20 RECEIVER MUST generate a soap:MustUnderstand fault when a message = contains a=20 mandatory header targeted at the receiver ( via soap:actor ) that the = receiver=20 does not understand. A mandatory header is one which carries a=20 soap:mustUnderstand attribute with the value 1.

These requirements ensure that, when a Fault is generated, no further = processing will be done on the message, a Fault message will be = transmitted to=20 the sender of the request message in request-response cases and some = application=20 level error will be flagged to the user.

R1028 Upon=20 generating a SOAP Fault a RECEIVER MUST NOT effect any further = processing of a=20 SOAP message beyond that which is necessary to handle the generated SOAP = Fault.=20

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

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

3.3 Using SOAP in HTTP

This portion of the profile modifies and refers to the following=20 specifications (or sections thereof);

SOAP 1.1 defines a single protocol binding, for HTTP. This profile = mandates=20 the use of that binding, and places the following constraints on its = use:

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

R1140 A=20 MESSAGE SHOULD be sent using HTTP/1.1.

Some consumer implementations use only the HTTP status code to = determine the=20 presence of a SOAP Fault. Because there are situations where the Web=20 infrastructure changes the HTTP status code, and for general = reliability, the=20 Profile requires that they examine the envelope.

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

The HTTP Extension Framework is an experimental mechanism for = extending HTTP=20 in a modular fashion. Because it is not deployed widely and also because = the=20 benefits to the use of SOAP are questionable, the Profile does not allow = its=20 use.

R1108 A=20 MESSAGE MUST NOT use the HTTP Extension Framework [RFC2774].

Interoperability testing has demonstrated that requiring the value of = the=20 SOAPAction HTTP Header Field to be quoted increases=20 interoperability of implementations. Even though HTTP allows for the = value of=20 HTTP Header Fields to be unquoted, some implementations require that the = value=20 be quoted.

The SOAPAction header is purely a hint to processors. = All vital=20 information regarding the intent of a message is carried in the=20 Envelope.

R1109 The=20 value of the SOAPAction HTTP header field in a MESSAGE MUST = be a=20 quoted string. C

R1117 A=20 MESSAGE MUST contain a SOAPAction HTTP header field with a = quoted=20 value equal to the value of the = soapbind:operation/@soapAction=20 attribute, if present in the DESCRIPTION. C

R1118 A=20 MESSAGE MUST contain a SOAPAction HTTP Header Field with a = quoted=20 empty string if the soapbind:operation/@soapAction = attribute is=20 either not present in the DESCRIPTION, or is present and contains an = empty=20 string as its value. C

R1119 A=20 RECEIVER MAY respond with a Fault if the value of the = SOAPAction=20 HTTP Header Field is not quoted. C

CORRECT: 

A WSDL Description that has:

<soapbind:operation soapAction=3D"foo" />

results in a message with a corresponding SOAPAction HTTP header field
as follows:

SOAPAction: "foo"

CORRECT: 

A WSDL Description that has:

<soapbind:operation />

or=20

<soapbind:operation soapAction=3D"" />


results in a message with a corresponding SOAPAction HTTP header field
as follows:

SOAPAction: ""

SOAP is designed to take advantage of the HTTP infrastructure. = However, there=20 are some situations (e.g., involving proxies, firewalls and other=20 intermediaries) where there may be harmful side effects. As a result, = instances=20 may find it advisable use other ports.

R1110 An=20 INSTANCE MAY use TCP port 80 (HTTP). C

HTTP uses the 2xx series of status codes to communicate success. In=20 particular, 200 is the default for successful messages, but 202 can be = used to=20 indicate that a messages has been submitted for processing. = Additionally, other=20 2xx status codes may be appropriate, depending on the nature of the HTTP = interaction.

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

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

R1112 An=20 INSTANCE SHOULD use either a "200 OK" or "202 Accepted" HTTP status code = for=20 responses that indicate successful HTTP outcome of a request but do not = contain=20 a SOAP message.

There are interoperability problems with using many of the HTTP = redirect=20 status codes, generally surrounding whether to use the original method, = or GET.=20 The profile mandates "307 Temporary Redirect" as the correct status code = for=20 redirection; for more information, see the 3xx status code descriptions = in=20 RFC2616.

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

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

RFC2616 notes that user-agents should not automatically redirect = requests;=20 however, this requirement was aimed at browsers, not automated processes = (which=20 many Web services will be). Therefore, the Profile allows, but does not = require,=20 consumers to come to be configured to automatically follow=20 redirections.

HTTP uses the 4xx series of status codes to indicate failure due to a = client=20 error. Although there are a number of situations which may result in one = of=20 these codes, the profile highlights those when the payload of the HTTP = request=20 is not the proper media type, and when the anticipated method is not=20 used.

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

R1113 An=20 INSTANCE SHOULD use a "400 Bad Request" HTTP status code if the request = message=20 is invalid (HTTP request malformed, XML not well formed, ...).

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

R1115 An=20 INSTANCE SHOULD use a "415 Unsupported Media Type" HTTP status code if = the=20 Content-Type HTTP request header did not have a value of = "text/xml".

HTTP uses the 5xx series of status codes to indicate failure due to a = server=20 error.

R1116 An=20 INSTANCE MUST use a 5xx HTTP status code for responses that indicate an=20 unsuccessful outcome of a well formed request.

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

The HTTP State Management Mechanism, or "Cookies", allows the = creation of=20 stateful sessions between Web browsers and servers. Being designed for = hypertext=20 browsing, Cookies do not have well-defined semantics for Web services, = and,=20 because they are external to the SOAP Envelope, are not accommodated by = either=20 the SOAP or WSDL specifications. However, there are situations where it = may be=20 necessary to use Cookies; e.g., for load balancing between servers, or = for=20 integration with legacy systems that use Cookies. For these reasons, the = profile=20 limits the ways in which Cookies can be used, without completely = disallowing=20 them.

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

R1122 An=20 INSTANCE using Cookies SHOULD conform to RFC2965.

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

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

The Profile recommends that cookies not be required by instances for = proper=20 operation; they should be a hint, to be used for optimization, without=20 materially affecting the execution of the Web service. However, they may = be=20 required in legacy integration and other exceptional use cases, so = requiring=20 them does not make an instance non-conformant. While Cookies thus may = have=20 meaning to the instance, they should not be used as an out-of-bound data = channel=20 between the instance and the consumer. Therefore, interpretation of = Cookies is=20 not allowed at all on the consumer side - it is required to treat them = as opaque=20 (i.e., have no meaning to the consumer).

4. Service Description

The profile uses Web Services Description Language (WSDL) to enable = the=20 description of services as a set of endpoints operating on messages.

This portion of the profile incorporates the following specifications = by=20 reference;

4.1 Document Structure

This portion of the profile modifies and refers to the following=20 specifications (or sections thereof);

WSDL 1.1 defines an XML-based structure for describing Web services. = This=20 profile mandates the use of that structure, and places the following = constraints=20 on its use:

Some of the examples in WSDL 1.1 specification incorrectly show WSDL = import=20 statement being used to import XML Schema definitions. To promote=20 interoperability the profile keeps the import mechanisms consistent and = confined=20 to their respective domains; the wsdl related mechanism in the "wsdl" = domain and=20 the schema related mechanisms in "schema" domain where the normal rules = from the=20 schema specification can be applied consistently.

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

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

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

R2004 A=20 DESCRIPTION MUST NOT use the XML Schema "import" statement to import a = Schema=20 definition embedded in line within another WSDL description.

INCORRECT: 
<definitions name=3D"StockQuote"
   targetNamespace=3D"http://example.com/stockquote/definitions"
   xmlns:xsd1=3D"http://example.com/stockquote.xsd"
           	 ...
   xmlns=3D"http://schemas.xmlsoap.org/wsdl/">

   <import namespace=3D"http://example.com/stockquote/schemas"
         location=3D"http://example.com/stockquote/stockquote.xsd"/>
        =20
   <message name=3D"GetLastTradePriceInput">
        <part name=3D"body" element=3D"xsd1:TradePriceRequest"/>
    </message>
               ...
</definitions>

CORRECT: 
<definitions name=3D"StockQuote" =20
   targetNamespace=3D"http://example.com/stockquote/definitions"
   xmlns:xsd1=3D"http://example.com/stockquote/schemas"
           	 ...
   xmlns=3D"http://schemas.xmlsoap.org/wsdl/">
  =20
   <types>
     <xsd:schema =
targetNamespace=3D"http://example.com/stockquote/definitions"
     	 xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema">
     	=20
       <xsd:import =
namespace=3D"http://example.com/stockquote/schemas"=20
         =
schemaLocation=3D"http://example.com/stockquote/stockquote.xsd"/>
         ...
         ...
     </xsd:schema>
   </types>

   <message name=3D"GetLastTradePriceInput">
      <part name=3D"body" element=3D"xsd1:TradePriceRequest"/>
   </message>
               ...
</definitions>

CORRECT: 
<definitions name=3D"StockQuote" =20
   targetNamespace=3D"http://example.com/stockquote/definitions"
   xmlns:xsd1=3D"http://example.com/stockquote/schemas"
           	 ...
   xmlns=3D"http://schemas.xmlsoap.org/wsdl/">
  =20
   <import namespace=3D"http://example.com/stockquote/definitions"
        location=3D"http://example.com/stockquote/stockquote.wsdl"/>
          =20
   <message name=3D"GetLastTradePriceInput">
      <part name=3D"body" element=3D"xsd1:TradePriceRequest"/>
   </message>
               ...
</definitions>

The XML specification allows UTF-8 encoding to include a BOM; = therefore,=20 description processors must be prepared to accept them.

R4002=20 DESCRIPTIONs MAY include the Unicode Byte Order Mark (BOM)

The profile consistently requires either UTF-8 or UTF-16 encoding for = both=20 SOAP and WSDL. See also R1012.

R4003=20 DESCRIPTIONs MUST use either UTF-8 or UTF-16 encoding.

Namespace coercion on wsdl:import is disallowed by the Basic Profile, = as it=20 has been found to be undesirable from interoperability = perspective.

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

Eliminate confusion about whether the location attribute = of the=20 wsdl:import statement is required and what its content is = required=20 to be.

R2007 A=20 DESCRIPTION MUST specify a valid and non-null value for the=20 location attribute on the wsdl:import element. =

Although the wsdl:import statement is modeled after the=20 xsd:import statement, the location attribute is required by = wsdl:import while the corresponding attribute on=20 xsd:import, schemaLocation is optional. = Consistent=20 with location being required, its content is not intended = to be=20 empty.

A WSDL processor may not need to retrieve a WSDL description from the = URI=20 specified in the location attribute on a wsdl:import element. A WSDL = processor=20 may have other ways of locating a WSDL description for a given = namespace,=20 including but not limited to; already having a cached representation, = having a=20 built-in representation, retrieving a representation from a metadata = repository=20 or UDDI server.

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

Eliminate inconsistency between WSDL 1.1 schema and the WSDL 1.1=20 specification in this area.

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

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

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

Eliminate confusion created by example 3 in section 3.1 of the WSDL = 1.1=20 specification and also align with the W3C WSDL WG resolution on this. =

R2022 In a=20 DESCRIPTION the wsdl:import element(s), when present, MUST = occur=20 either prior to any other child elements under the = wsdl:definitions=20 element, if no wsdl:documentation element is present; or=20 immediately following the wsdl:documentation element if = present.=20 WSDL12

R2023 In a=20 DESCRIPTION the wsdl:types element MUST occur either as the = first=20 child of the wsdl:definitions element if no=20 wsdl:documentation or wsdl:import elements are = present; or immediately following the wsdl:documentation = and/or=20 wsdl:import elements if present. WSDL12

INCORRECT: 
<definitions name=3D"StockQuote" =20
           	 ...
   xmlns=3D"http://schemas.xmlsoap.org/wsdl/">
  =20
   <import namespace=3D"http://example.com/stockquote/definitions"
         location=3D"http://example.com/stockquote/stockquote.wsdl"/>
          =20
   <message name=3D"GetLastTradePriceInput">
       <part name=3D"body" type=3D"tns:TradePriceRequest"/>
   </message>
               ...
   <service name=3D"StockQuoteService">
      <port name=3D"StockQuotePort" =
binding=3D"tns:StockQuoteSoap">
           ....
      </port>
   </service>

   <types>
      <schema targetNamespace=3D"http://example.com/stockquote.xsd"
               xmlns=3D"http://www.w3.org/2001/XMLSchema">
           .......
      </schema>
   </types>
</definitions>

CORRECT: 
<definitions name=3D"StockQuote"
           	 ...
   xmlns=3D"http://schemas.xmlsoap.org/wsdl/">
  =20
  <import namespace=3D"http://example.com/stockquote/definitions"
           =
location=3D"http://example.com/stockquote/stockquote.wsdl"/>
  =20
  <types>
    <schema targetNamespace=3D"http://example.com/stockquote.xsd"
         xmlns=3D"http://www.w3.org/2001/XMLSchema">
           .......
    </schema>
   </types>
          =20
   <message name=3D"GetLastTradePriceInput">
      <part name=3D"body" element=3D"tns:TradePriceRequest"/>
   </message>
               ...
   <service name=3D"StockQuoteService">
      <port name=3D"StockQuotePort" =
binding=3D"tns:StockQuoteSoap">
           ....
      </port>
   </service>
</definitions>

CORRECT: 
<definitions name=3D"StockQuote" =20
           	 ...
   xmlns=3D"http://schemas.xmlsoap.org/wsdl/">

  <types>
     <schema targetNamespace=3D"http://example.com/stockquote.xsd"
          xmlns=3D"http://www.w3.org/2001/XMLSchema">
           .......
     </schema>
   </types>
          =20
   <message name=3D"GetLastTradePriceInput">
        <part name=3D"body" element=3D"tns:TradePriceRequest"/>
   </message>
               ...
   <service name=3D"StockQuoteService">
      <port name=3D"StockQuotePort" =
binding=3D"tns:StockQuoteSoap">
           ....
      </port>
   </service>
</definitions>

4.2 Types

This portion of the profile modifies and refers to the following=20 specifications (or sections thereof);

The wsdl:types element of WSDL 1.1 encloses data type=20 definitions that are relevant to the Web service described. This profile = places=20 the following constraints pertinent to those portions of the content of = the=20 wsdl:types element that are referred to by WSDL elements = that make=20 profile conformance claims:

The WSDL specification is not explicit that WSDL documents may only = refer,=20 using a QName, to a name that is in a namespace that has either been = imported or=20 defined in the referring document.

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

Requiring a targetNamespace on all xsd:schema elements that are = children of=20 wsdl:types is a good practice, places a minimal burden on authors of = WSDL=20 documents, and avoids the cases that are not as clearly defined as they = might=20 be.

R2105 All=20 xsd:schema elements contained in a wsdl:types = element=20 of a DESCRIPTION MUST have a targetNamespace attribute with = a valid=20 and non-null value.

The recommendations in section 2.2 of the WSDL 1.1 specification for=20 declaration of Array types are prohibited by the Basic Profile, as they = are=20 based on SOAP 1.1 encoding scheme.

R2110 In a=20 DESCRIPTION array declarations MUST NOT extend the=20 soapenc:Array type.

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

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

R2113=20 MESSAGEs with serialized form of arrays MUST NOT include the=20 soapenc:arrayType attribute.

INCORRECT: 

<xsd:element name=3D"MyArray2" type=3D"tns:MyArray2Type"/>
<xsd:complexType name=3D"MyArray2Type" =
xmlns:soapenc=3D"http://schemas.xmlsoap.org/soap/encoding/"
  xmlns:wsdl=3D"http://schemas.xmlsoap.org/wsdl/" >
  <xsd:complexContent>
     <xsd:restriction base=3D"soapenc:Array">
       <xsd:sequence>
          <xsd:element name=3D"x" type=3D"xsd:string"  minOccurs=3D0 =
maxOccurs=3D"unbounded"/>
       </xsd:sequence>
       <xsd:attribute ref=3D"soapenc:arrayType" =
wsdl:arrayType=3D"tns:MyArray2Type[]"/>
   </xsd:restriction>
 </xsd:complexContent>
</xsd:complexType>

In a SOAP message this would serialize as below (omitting namespace =
declarations for clarity):

<MyArray2 soapenc:arrayType=3D"tns:MyArray2Type[]" >
  <x>abcd</x>
  <x>efgh</x>
</MyArray2>=09

CORRECT: 

<xsd:element name=3D"MyArray1" type=3D"tns:MyArray1Type"/>
<xsd:complexType name=3D"MyArray1Type">
  <xsd:sequence>
   <xsd:element name=3D"x" type=3D"xsd:string" minOccurs=3D0 =
maxOccurs=3D"unbounded"/>
  </xsd:sequence>
</xsd:complexType>
 =20
In a SOAP message this would serialize as below (omitting namespace =
declarations for clarity):
<MyArray1>
  <x>abcd</x>
  <x>efgh</x>
</MyArray1>

4.3 Messages

This portion of the profile modifies and refers to the following=20 specifications (or sections thereof);

In WSDL 1.1 message elements are used to represent abstract = definitions of=20 the data being transmitted and binding elements to define how the = abstract=20 definitions are bound to a specific wire format.

An "rpc-literal binding" is a wsdl:binding that contains = a=20 soapbind:binding element whose style attribute = has the=20 value "rpc" and all of whose soapbind:body elements specify = the=20 use=3D"literal" attribute.

A "document-literal binding" is a wsdl:binding that = contains a=20 soapbind:binding element whose style attribute = is=20 either omitted or specified with a value of "document" and all of whose=20 soapbind:body elements specify the = use=3D"literal"=20 attribute.

This profile places the following constraints message elements and on = how=20 conformant binding elements may use message element(s).

Use of wsdl:message elements with zero parts is = permitted in=20 Document styles to permit operations that can send or receive MESSAGEs = with=20 empty SOAP Bodies. Use of wsdl:message elements with zero = parts is=20 permitted in RPC styles to permit operations that have no (zero) = parameters=20 and/or return value. This case is explicitly permitted by the Basic = Profile.=20

For Document-literal binding, the Basic Profile requires that at most = one=20 wsdl:part is marshaled in SOAP Body, which needs to be defined via the = element=20 form at the abstract level.

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

R2210 If a=20 document-literal binding in a DESCRIPTION does not specify the=20 parts attribute on a soapbind:body element, = the=20 corresponding abstract wsdl:message MUST define a single=20 wsdl:part.

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

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

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

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

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

soapbind:fault, soapbind:header and soapbind:headerfault assume that=20 style=3D"document", since faults and headers do not contain parameters. = This=20 requirement is consistent with R2204, which requires that all parts in=20 style=3D"document" that are bound to soapbind:body be defined using the = element=20 attribute.

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

A portType defines an abstract contract with a named set of = operations and=20 associated abstract messages. Although not disallowed, it is expected = that every=20 part of the abstract input, output and fault message specified in the = portType=20 is bound to soapbind:body or soapbind:header etc. as appropriate when = using SOAP=20 binding as defined in WSDL 1.1 section 3.

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

The examples 4, 5 in section 3.1 of the WSDL 1.1 specification = incorrectly=20 show the use of Schema types (e.g. xsd:string) as a valid value for the=20 element attribute of a wsdl:part element. =

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

INCORRECT: 
  <message name=3D"GetTradePriceInput">
      <part name=3D"tickerSymbol" element=3D"xsd:string"/>
      <part name=3D"time" element=3D"xsd:timeInstant"/>
  </message>
   =20
  <message name=3D"GetTradePricesInput">
      <part name=3D"tickerSymbol" element=3D"xsd:string"/>
  </message>

CORRECT: 
     <message name=3D"GetTradePriceInput">
      <part name=3D"body" element=3D"tns:SubscribeToQuotes"/>      =
=20
  </message>

4.4 Port Types

This portion of the profile modifies and refers to the following=20 specifications (or sections thereof);

In WSDL 1.1, portType elements are used to group a set = of=20 abstract operations. This profile places the following constraints on = the use of=20 portType element(s):

Permitting the use of parameterOrder helps code generators in mapping = between=20 method signatures and on the wire MESSAGE instances.

R2301 The=20 order of the parts in a message in the DESCRIPTION MUST be the = definitive order=20 of the part elements on the wire for any part in an operation.

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

Solicit-Response and Notification are not well defined by the WSDL = 1.1=20 specification and the WSDL 1.1 specification defines bindings for the = One-way=20 and Request-response primitives only.

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

To promote interoperability operation name overloading in a portType = is=20 disallowed by the Basic Profile. Note however that a portType may name=20 operations same as the ones in another portType.

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

WSDL representation of an RPC function can have 0 or 1 return value = while the=20 return value can be an instance of a complex type. The parameterOrder = definition=20 where provided, must be consistent with this as well.

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

If a part from the output message is omitted from the list of parts = that is=20 the value of the parameterOrder attribute, the single = omitted part=20 is the return value. There are no restrictions on the type of the return = value.=20 If no part is omitted, there is no return value.

WSDL 1.1 specification does not clearly state that both = type and=20 element attributes can not be specified to define a=20 part in a wsdl:message. This loop-hole needs = to be=20 closed.

R2306 A=20 wsdl:portType in a DESCRIPTION MUST NOT refer to=20 wsdl:messages that define wsdl:parts that = specify both=20 type and element attributes on the same=20 wsdl:part.

4.5 Bindings

This portion of the profile modifies and refers to the following=20 specifications (or sections thereof);

In WSDL 1.1 the binding element supplies the concrete = protocol=20 and data format specifications for the operations and messages defined = by a=20 particular portType. This profile places the following constraints on = the=20 binding specifications:

For interoperability the choice of bindings is limited to the well = defined=20 and most commonly used SOAP Binding. MIME, HTTP GET/POST bindings are = not=20 permitted by the Basic Profile.

R2401 A=20 wsdl:binding in a DESCRIPTION MUST use WSDL SOAP Binding as = defined=20 in section "3 SOAP Binding" of the WSDL 1.1 specification.

4.6 Ports

This portion of the profile modifies and refers to the following=20 specifications (or sections thereof);

In WSDL 1.1 the port element specifies an address for binding on a = portType,=20 thus defining a communication end-point for the Web service. This = profile places=20 the following constraints on the use of the port element:

Editors' note:The Working Group has = not closed=20 any issues relating to Ports as of publication.

4.7 Services

This portion of the profile modifies and refers to the following=20 specifications (or sections thereof);

In WSDL 1.1 the service element is used to aggregate a set of related = ports.=20 This profile places the following constraints on the use of the service = element:=20

Editors' note:The Working Group has = not closed=20 any issues relating to Services as of publication.

4.8 SOAP Binding

This portion of the profile modifies and refers to the following=20 specifications (or sections thereof);

WSDL 1.1 defines a binding for SOAP 1.1 endpoints. This profile = mandates the=20 use of SOAP binding as defined in the WSDL 1.1 specification, and places = the=20 following constraints on its use:

SOAP 1.2 specification differs from the SOAP 1.1 specification in = many=20 respects. For interoperability the profile limits the SOAP binding to = the SOAP=20 1.1 protocol.

R2700 A=20 wsdl:binding DESCRIPTION MUST use SOAP 1.1 protocol with = SOAP=20 Binding.

Eliminate inconsistency between the WSDL 1.1 specification text and = the WSDL=20 1.1 schema. The WSDL 1.1 specification shows it to be required but, the = schema=20 shows this attribute to be optional, where as the Basic profile sees = this to be=20 a required attribute.

R2701 A=20 wsdl:binding in a DESCRIPTION MUST be constructed so that = its=20 soapbind:binding child specifies the transport = attribute.

For interoperability the transport protocol is limited to HTTP. To = permit=20 secure transfers at the HTTP level use of HTTP(S) is allowed.

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

Disallow mix and match of operation "style" in the same = binding.

R2705 A=20 wsdl:binding in a DESCRIPTION MUST use the same value, = either "rpc"=20 or "document," for the style attribute for all of its=20 soapbind:operations.

For interoperability the profile prohibits the use of different = encodings=20 including the SOAP encoding.

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

Eliminate the ambiguity between the WDSL specification text and the = Schema=20 given in Appendix A4 about whether the use attribute is = optional on=20 soapbind:body, soapbind:header, and=20 soapbind:headerfault, and if so, what omitting the = attribute means.=20

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

Explicitly permit multiple bindings for the same portType, to = alleviate any=20 ambiguity in this area.

R2709 A=20 wsdlportType in a DESCRIPTION MAY have any number of=20 wsdl:bindings that refer to it defined in the same or other = WSDL=20 documents.

An endpoint that supports multiple operations has to identify = unambiguously=20 the operation being invoked based on the input message that it receives. = This is=20 only possible if all the operations specified in the wsdl:binding = associated=20 with an endpoint have a unique wire signature.

R2710 The=20 Basic Profile defines the "wire signature" of an operation in a=20 wsdl:binding to be the fully qualified name of the child = element of=20 the soap:Body of the SOAP input message it describes. For = the case=20 of an empty soap:Body this name is an empty string. The = operations=20 in a wsdl:binding in a DESCRIPTION MUST result in wire = signatures=20 that are different from one another.

In the case of RPC/literal binding, the operation name is used as = wrapper for=20 the part accessors. However in the doc (literal) SOAP binding case since = a=20 wrapper with the operation name is not present, there might be an = ambiguity as=20 to which operation is invoked, if there are more than one operation in a = port=20 which is bound with doc/literal style. Hence the server needs to ensure = it can=20 distinguish the operation based on, on the wire SOAP message for the = operation.=20

It is perceivable and it has also been demonstarted in the field that = multiple Web services are hosted at the same network end-point by some=20 implementations.

R2711 A=20 DESCRIPTION MAY have more than one port with the same value = for the=20 location attribute of the soapbind:address = element.=20

While it is not a conformance issue to have multiple = wsdl:ports=20 at the same network address, when the input messages destined for two = different=20 wsdl:ports are indistinguishable on the wire, the endpoint = will not=20 be able to determine the wsdl:port being invoked and this may result in=20 implementation problems.

R2712 When=20 a Doc/literal binding is in use, the wire representation of a MESSAGE = MUST be an=20 instance of the global element declaration referenced by the = corresponding=20 wsdl:message part.

Disambiguate the meaning of missing SOAPAction attribute = specification in a=20 WSDL description.

R2713 If=20 the value of the soapAction attribute on the=20 soapbind:operation element is empty (as indicated by two = quotes),=20 the DESCRIPTION MUST be treated equivalent to the one that does not = specify the=20 soapAction attribute.

HTTP being a request/response protocole, the profile needs to clarify = what=20 the expected behavior is in the case of a one-way message being = exchanged.

Any SOAP content sent in reponse to a one-way operation would = constitute a=20 response message. Transmission of one-way operations MUST not result in=20 processing level response or errors. It is therefore fobidden by the = profile to=20 send a SOAP envelop in reply to a one-way document. Hence a HTTP 500 = "Internal=20 Server Error" response that includes a SOAP message in the response = containing a=20 SOAP Fault element MUST NOT be returned.

There is no way at the HTTP level for the initiator of a request to = know that=20 the request was succesfully received until an HTTP response code is sent = back.=20 Based on the scemantics of the different response codes supported by the = HTTP=20 protocol, the profile specify that response codes 200 and 202 are the = only=20 response codes that the sender should interprete to signify that the = message was=20 succesfully delivered.

R2714 For=20 one-way operations, INSTANCEs MUST NOT return a HTTP response that = contains a=20 SOAP envelope. Specifically, the HTTP entity-body of the response MUST = be empty.=20

R2715=20 INSTANCEs MUST NOT consider transmission of one-way operations complete = until a=20 HTTP response code of either "200 OK" or "202 accepted" is received by = the HTTP=20 client.

R2727 For=20 one-way operations, INSTANCEs MUST NOT interpret the HTTP response code = of 200=20 or 202 to mean the message is valid or that the receiver would process = it.

Despite the fact that the HTTP 1.1 specification assigns different = meanings=20 to responce codes 200 and 202, in the context of the basic profile there = should=20 be considered the same by the initiator of the request. This is due to = the fact=20 that some SOAP implementations have little control over the HTTP layer = they=20 depend on and might not be able to control the HTTP response code sent = and when=20 it is sent. As a result, the initiator of a one-way message should only=20 interpret a 200 or 202 response code to mean that the message was = succesfully=20 received at the transport level but not that the SOAP processing layer = and the=20 application logic had a chance to validate the message or are commiting = to=20 processing it.

In a document/literal SOAP binding, the serialized element child of = the=20 SOAP:Body gets its namespace from the targetNamespace of the schema that = defines=20 the element. Use of the soapbind:body/@namespace attribute would = override the=20 element's namespace, which is prevented by the Basic Profile.

Conversely, in a rpc/literal SOAP binding, the serialized element = child of=20 the SOAP:Body is generated by wrapping the xsd Types referenced in the=20 wsdl:part/@type attributes of the wsdl:message, into an element whose = name is=20 constructed from the value of the wsdl:part/@name attribute as the = localname=20 part, and whose assigned namespace is taken from the value of the=20 soapbind:body/@namespace attribute. If the = soapbind:body/@namespaceattribute=20 were not specified, then the child of the SOAP:Body would not be = namespace=20 qualified.

Even for rpc/literal SOAP binding the soapbind:header, = soapbind:headerfault=20 and soapbind:fault assume that style=3D"document", since faults and = headers do not=20 contain parameters. This requirement is consistent with R2716, which = requires=20 that all parts for style=3D"document" not contain the namespace = attribute.=20

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

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

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

The WSDL definition must be consistent at both abstract (portType) = and=20 concrete (binding) levels.

R2718 A=20 wsdl:binding in a DESCRIPTION MUST have the same list of=20 wsdl:operations as the wsdl:portType to which = it=20 refers. C

All known header faults for an operation should be idenfied in a WSDL = description.

R2736 A=20 wsdl:binding in a DESCRIPTION SHOULD contain=20 soapbind:headerfault elements describing each known header = fault=20 that might be generated.

Eliminate inconsistency between WSDL specification text and the WSDL = schema.=20 WSDL 1.1 schema makes the specification of = soapbind:headerfault=20 element manadatory on wsdl:input and = wsdl:output=20 elements of an operation, where as the WSDL 1.1 specification marks them = optional.

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

A Web service definition should include all faults known at the time = the=20 service is defined. There is also need to permit generation of new = faults that=20 had not been indentified when the Web service was defined.

R2740 A=20 wsdl:binding in a DESCRIPTIONs SHOULD contain a=20 soapbind:fault describing each known fault.

R2741 A=20 wsdl:binding in a DESCRIPTIONs SHOULD contain a=20 soapbind:headerfault each known header fault.

R2742 A=20 MESSAGE MAY contain fault detail elements in a soap:Fault = element=20 that are NOT described by a wsdl:fault element in the = corresponding=20 WSDL description.

R2743 A=20 MESSAGE MAY contain fault detail elements in a soap:Header = element=20 that are NOT described by a wsdl:headerfault element in the = corresponding WSDL description.

The WSDL 1.1 schema is inconsistent with the WSDL 1.1 specification = here and=20 incorrectly names the attribute parts and gives a type of=20 "NMTOKENS". The schema is incorrect since each = soapbind:header=20 element references a single part.

R2720 A=20 wsdl:binding in a DESCRIPTIONs MUST use the attribute named = part with a Schema type of "NMTOKEN" on all contained=20 soapbind:header and soapbind:headerfault = elements. It=20 MUST NOT use the attribute named parts on contained=20 soapbind:header and soapbind:headerfault = elements.=20

CORRECT: 
<binding name=3D"StockQuoteSoap" =
type=3D"tns:StockQuotePortType">
  <soap:binding style=3D"document"=20
                transport=3D"http://schemas.xmlsoap.org/soap/http"/>
    <operation name=3D"SubscribeToQuotes">
      <input message=3D"tns:SubscribeToQuotes">
        <soap:body parts=3D"body" use=3D"literal"/>
        <soap:header message=3D"tns:SubscribeToQuotes"
             		part=3D"subscribeheader" use=3D"literal"/>
     </input>
   </operation>
</binding>

Eliminate inconsistency between WSDL1.1 specification text and the = schema.=20 The WSDL 1.1 schema does not list the name attribute. =

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

Eliminate inconsistency between WSDL 1.1 specification text and the=20 schema.

WSDL 1.1 specification section 3.6 soap:Fault grammar, indicates that = the=20 use attribute of fault is required while in the schema the=20 use attribute is defined as optional.

Also ensure the correct value is provided for the use = attribute=20 when present and identify the correct default value for the attribute = when=20 omitted.

R2722 A=20 wsdl:binding in a DESCRIPTION MAY specificy the = use=20 attribute on contained soapbind:fault elements. C

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

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

For interoperability, it is important to define how a conformant port = should=20 behave when a message that does not conform to its WSDL description is = received.=20

R2724 If an=20 INSTANCE receives a message that is inconsistent with its WSDL = description, it=20 MUST return a soap:Fault with a faultcode of = "VersionMismatch", or=20 "MustUnderstand", or "Client".

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

The description in section 3.5 of the WSDL 1.1 specification could be = interpreted to mean the RPC response wrapper element must be named = identical to=20 the name of the wsdl:operation.

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

For rpc-literal SOAP messages, the WSDL 1.1 specification is not = clear what=20 namespace, if any, the accessor elements for parameters and return value = are a=20 part of. Different implementations make different choices, leading to=20 interoperability problems. Settling on one of the alternatives is = crucial to=20 achieving interoperability. The Basic Profile chose to place the part = accessor=20 elements in no namespace as it is simple, covers all cases and does not = lead to=20 logical inconsistency.

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

For rpc-literal SOAP messages, the WSDL 1.1 specification is not = clear on=20 what the correct namespace qualification is, for the child elements of = the part=20 accessor elements, when the corresponding abstract parts are defined to = be of=20 types from a different namespace than the targetNamespace of the WSDL=20 description for the abstract parts. The Basic Profile chose to qualify = the child=20 elements of the part accessor elements with the targetNamespace in which = their=20 types (elements and attributes) were defined.

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

The WSDL1.1 spec in sect 3.5 states:

"The part names, types and value of the namespace attribute are all = inputs to=20 the encoding, although the namespace attribute only applies to content = not=20 explicitly defined by the abstract types."

Yet, it doesn't explicitly state that the element and attribute = content of=20 the abstract (complexType) types is namespace qualified to the = targetNamespace=20 in which those elements and attributes were defined. WSDL was intended = to=20 function in much the same manner as XML Schema. Hence, implementations = must=20 follow the same rules as for XML Schema. If a complexType defined in=20 targetNamespace A were imported and referenced in an element declaration = in a=20 schema with targetNamespace B. The element and attribute content of the = child=20 elements of that complexType would be qualified to namespace A and the = element=20 would be qualified to namespace B.

CORRECT: 
<definitions xmlns=3D"http://schemas.xmlsoap.org/wsdl/"
xmlns:soap=3D"http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:http=3D"http://schemas.xmlsoap.org/wsdl/http/"
xmlns:xs=3D"http://www.w3.org/2001/XMLSchema"
xmlns:bar=3D"http://example.org/bar/"
targetNamespace=3D"http://example.org/bar/"
xmlns:foo=3D"http://example.org/foo/">
<types>
   <xs:schema targetNamespace=3D"http://example.org/foo/"
       xmlns:tns=3D"http://example.org/foo/"
       xmlns:xs=3D"http://www.w3.org/2001/XMLSchema"
       elementFormDefault=3D"qualified"
       attributeFormDefault=3D"unqualified">
       <xs:complexType name=3D"fooType">
          <xs:sequence>
             <xs:element ref=3D"tns:bar"/>
             <xs:element ref=3D"tns:baf"/>
          </xs:sequence>
       </xs:complexType>
       <xs:element name=3D"bar" type=3D"xs:string"/>
       <xs:element name=3D"baf" type=3D"xs:integer"/>
   </xs:schema>
</types>
<message name=3D"BarMsg">
   <part name=3D"BarAccessor" type=3D"foo:fooType"/>
</message>
<portType name=3D"BarPortType">
   <operation name=3D"BarOperation">
     <input message=3D"bar:BarMsg"/>
   </operation>
</portType>
<binding name=3D"BarSOAPBinding" type=3D"bar:BarPortType">
   <soap:binding transport=3D"http://schemas.xmlsoap.org/soap/http/" =
style=3D"rpc"/>
   <operation name=3D"BarOperation">
     <input message=3D"bar:BarMsg">
       <soap:body use=3D"literal"/>
     </input>
   </operation>
</binding>
<service name=3D"serviceName">
  <port name=3D"BarSOAPPort" binding=3D"bar:BarSOAPBinding">
    <soap:address location=3D"http://example.org/myBarSOAPPort"/>
  </port>
</service>
</definitions>

CORRECT: 
<s:Envelope =
xmlns:s=3D"http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema"
xmlns:foo=3D"http://example.org/foo/">
  <s:Header/>
    <s:Body>
      <m:BarOperation xmlns:m=3D"http://example.org/bar/">
         <BarAccessor>
            <foo:bar>String</foo:bar>
            <foo:baf>0</foo:baf>
         </BarAccessor>
      </m:BarOperation>
    </s:Body>
</s:Envelope>

Editors' note:The examples above = demonstrate=20 the purpose of this requirement. The first segment shows a WSDL that = defines=20 some schema in the http://example.org/foo/ namespace in the wsdl:types = section=20 contained within a wsdl:definitions that has as its targetNamespace=20 http://example.org/bar/. Thus, we have a type declared in one namespace = and the=20 containing element defined in another. The resulting SOAP message for=20 BarOperation is shown in the segment that follows.

WSDL 1.1 specification is not clear if all = soapbind:headers=20 specified on wsdl:input or wsd:output of an=20 operation in the SOAP binding section of a WSDL document = must be=20 included in the resultant SOAP messages transmitted. Basic Profile chose = to make=20 all the headers mandatory as there is no way in WSDL 1.1 to mark a = header=20 optional.

R2738 A=20 MESSAGE MUST include all soapbind:headers specified on=20 wsdl:input or wsd:output of an = operation=20 wsdl:binding that describes it.

Headers are SOAP's extensibility mechanism and headers that are not = defined=20 in the WSDL document may need to be included in the SOAP messages for = various=20 valid reasons described in SOAP.

R2739 A=20 MESSAGE MAY contain headers that are not described in the=20 wsdl:binding that describes it. These headers MAY (or may = not) have=20 the mustUnderstand attribute set to '1'.

The SOAPAction header is purely a hint to processors. = All vital=20 information regarding the intent of a message is carried in the = Envelope.=20

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

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

R2746 A=20 RECEIVER MAY respond with a Fault if the value of the = SOAPAction=20 HTTP Header Field is not quoted.

CORRECT: 

A WSDL Description that has:

<soapbind:operation soapAction=3D"foo" />

results in a message with a corresponding SOAPAction HTTP header field
as follows:

SOAPAction: "foo"

CORRECT: 

A WSDL Description that has:

<soapbind:operation />

or=20

<soapbind:operation soapAction=3D"" />


results in a message with a corresponding SOAPAction HTTP header field
as follows:

SOAPAction: ""

The wsdl:required attributed has been widely misunderstood and used = by WSDL=20 writers sometimes to incorrectly to indicate the optionality of=20 soapbind:headers. The wsdl:required attribute, as specified in WSDL1.1, = is an=20 extensibility mechanism aimed at WSDL processors. It allows new WSDL = extension=20 elements to be introduced in a graceful manner. The intent of = wsdl:required is=20 to signal to the WSDL processor whether the extension element needs to = be=20 recognized and understood by the WSDL processor in order that the WSDL=20 description be correctly processed. It is not meant to signal = conditionality or=20 optionality of some construct that is included in the messages. For = example,=20 wsdl:required=3D'false' on a soapbind:header element must not be = interpreted to=20 signal to the WSDL processor that the described SOAP header block is = conditional=20 or optional in the messages generated from the WSDL description. It is = meant to=20 be interpreted as "in order to send a message to the endpoint that = includes in=20 its description the soapbind:header element, the WSDL processor MUST = understand=20 the semantic implied by the soapbind:header element".

The default value for the wsdl:required attribute for WSDL 1.1 SOAP = Binding=20 extension elements is "false". Most WSDL descriptions in practice do not = specify=20 the wsdl:required attribute on the SOAP Binding extension elements, = which could=20 be interpreted by WSDL processors to mean, the extension elements may be = ignored. The Basic Profile requires that all WSDL SOAP 1.1 extensions be = understood and processed by the WSDL processors, irrespective of the = presence or=20 the value of the wsdl:required attribute on an extension element. =

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

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

4.9 XML Schema

This portion of the profile modifies and refers to the following=20 specifications (or sections thereof);

WSDL 1.1 uses XML Schema as one of its type systems. This profile = mandates=20 the use of XML Schema as the type system for WSDL descriptions of Web=20 Services.

R2800=20 DESCRIPTIONs MAY use any construct from XML Schema 1.0.

R2801=20 DESCRIPTIONs MUST use XML Schema 1.0 Recommendation, with the namespace = URI=20 "http://www.w3.org/2001/XMLSchema".

5. Service Publication and Discovery

When publication or discovery of Web services is required, UDDI is = the=20 mechanism the Basic Profile has adopted to describe Web service = providers and=20 the Web services they provide. Business, intended use, and Web service = type=20 descriptions are made in UDDI terms; detailed technical descriptions are = made in=20 WSDL terms. Where the two specifications define overlapping descriptive = data and=20 both forms of description are used, the Basic Profile specifies that the = descriptions must not conflict.

Registration of Web service instances in UDDI registries is optional. = By no=20 means do all usage scenarios require the kind of metadata and discovery = UDDI=20 provides, but where such capability is needed, UDDI is the sanctioned=20 mechanism.

Editors' note:The Web services that = constitute=20 UDDI V2 are not fully conformant with the Basic Profile 1.0 because they = do not=20 accept messages encoded in both UTF-8 and UTF-16 as required by the = profile.=20 (They accept UTF-8 only.) That there should be such a discrepancy is = hardly=20 surprising given that UDDI V2 was designed and, in many cases, = implemented=20 before the Basic Profile was developed. UDDI's designers are aware of = UDDI V2's=20 nonconformance and will take it into consideration in their future = work.

This portion of the profile incorporates the following specifications = by=20 reference;

5.1 bindingTemplates

This portion of the profile modifies and refers to the following=20 specifications (or sections thereof);

UDDI represents Web service INSTANCEs as = uddi:bindingTemplate=20 elements. The uddi:bindingTemplate plays a role that is the = rough=20 analog of the wsdl:port, but provides options that are not=20 expressible in WSDL. To keep the WSDL description of an INSTANCE and its = UDDI=20 description consistent, the profile places the following constraints on = how=20 uddi:bindingTemplate elements may be constructed.

WSDL's soapbind:address element requires the network = address of=20 the INSTANCE to be directly specified. In contrast, UDDI V2 provides two = alternatives for specifying the network address of INSTANCEs it = represents. One,=20 the uddi:accessPoint, mirrors the WSDL mechanism by = directly=20 specifying the address. The other, the = uddi:hostingRedirector,=20 provides a Web service-based indirection mechanism for resolving the = address,=20 and is inconsistent with the WSDL mechanism.

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

INCORRECT: 

<bindingTemplate bindingKey=3D"...">
   <description xml:lang=3D"EN">BarSOAPPort</description>
   <hostingRedirector bindingKey=3D"..."/>=20
   <tModelInstanceDetails>
      ...
   </tModelInstanceDetails>
</bindingTemplate>

CORRECT: 

<bindingTemplate bindingKey=3D"...">
   <description xml:lang=3D"EN">BarSOAPPort</description>
   =
<accessPoint>http://example.org/myBarSOAPPort</accessPoint>
   <tModelInstanceDetails>
      ...
   </tModelInstanceDetails>
</bindingTemplate>

5.2 tModels

This portion of the profile modifies and refers to the following=20 specifications (or sections thereof);

UDDI represents Web service types as uddi:tModel = elements. (See=20 UDDI=20 Data Structures section 8.1.1.) These may, but need not, point = (using a URI)=20 to the document that contains the actual description. Further, UDDI is = agnostic=20 with respect to the mechanisms used to describe Web service types. The = Basic=20 Profile cannot be agnostic about this because interoperation is very = much=20 complicated if Web service types do not have descriptions or if the = descriptions=20 can take arbitrary forms.

The UDDI=20 API Specification, appendix I.1.2.1.1 allows but does not require=20 uddi:tModel elements that use WSDL to describe the Web = service type=20 they represent to state that they use WSDL as the description language. = Not=20 doing so leads to interoperability problems because it is then ambiguous = what=20 description language is being used.

It is not easy and in some cases it may be impossible to determine = whether a=20 given uddi:tModel represents a conformant Web service type = by=20 inspection alone because uddi:tModel elements describing = conformant=20 and non-conformant Web service types can look very similar. It needs to = be easy=20 for inquirers to determine whether a given uddi:tModel = conforms and=20 to discover conforming uddi:tModel elements.

Therefore the Basic Profile places the following constraints on how=20 uddi:tModel elements that describe Web service types may be = constructed:

The profile chooses WSDL as the description language because it is by = far the=20 most widely used such language.

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

For the uddi:overviewURL in a uddi:tModel = to=20 resolve to a wsdl:binding, the profile must adopt a = convention for=20 distinguishing among multiple wsdl:bindings in a WSDL = document. The=20 UDDI Best Practice for Using WSDL in a UDDI Registry specifies the most = widely=20 recognized such convention.

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

To specify that conformant Web service types use WSDL, the profile = adopts the=20 UDDI categorization for making this assertion.

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

It would be ambiquous if the conformance claim a = uddi:tModel=20 made were not consistent with the claim made by the = wsdl:binding it=20 uses.

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

The natural mechanism in UDDI for adding attributes to a=20 uddi:tModel is to define and use a category system. The = profile=20 adopts this mechanism to add the ability for uddi:tModels = to assert=20 conformance with WS-I profiles, and with the Basic Profile in=20 particular.

R3020=20 REGDATA of type uddi:tModel claiming conformance with a = WS-I=20 profile MUST be categorized using the ws-i-org:conformsTo taxonomy.

R3030=20 REGDATA of type uddi:tModel claiming conformance with a the = Basic=20 Profile MUST use the ws-i-org:conformsTo categorization value of=20 "http://www.ws-i.org/profiles/base/1.0".

CORRECT: 

<tModel tModelKey=3D"...">
   <name>BarSOAPService</name>
   <description xml:lang=3D"EN">Bar=E2=80=99s SOAP =
Service</description>
   <overviewDoc>...</overviewDoc>
   <categoryBag>
      <keyedReference
         tModelKey=3D"uddi:..."
         keyName=3D"ws-I_conformance:BasicProfile1.0"
         keyValue=3D"http://www.ws-i.org/profiles/basic/1.0" />
   </categoryBag>

Editors' note:The value of the = categorization=20 in R3030 is intended to match the value used in the resolution of issue = w27=20 concerning how to mark WSDL elements that conform to the profile. If the = value=20 representing the Basic Profile 1.0 changes in the final resolution, the = value=20 used here should be changed to match.

Since wsdl:service elements are not necessarily mapped = to a=20 single uddi:businessService and are also not subject to = conformance=20 claims, it would be unclear what it meant if a = uddi:businessEntity=20 or a uddi:businessService element were to claim conformance = with=20 the Basic Profile. Also, uddi:bindingTemplate elements = can't be=20 categorized because the UDDI V2 XML Schema does not provide a=20 uddi:categoryBag for them. Hence, the conformance claim = made by=20 wsdl:port elements can't be documented in the corresponding = uddi:bindingTemplate.

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

6. Security

As is true of all network-oriented information technologies, the = subject of=20 security is a crucial one for Web services. For Web services, as for = other=20 information technologies, security consists of understanding the = potential=20 threats an attacker may mount and applying operational, physical, and=20 technological countermeasures to reduce the risk of a successful attack = to an=20 acceptable level. Because an "acceptable level of risk" varies hugely = depending=20 on the application, and because costs of implementing countermeasures is = also=20 highly variable, there can be no universal "right answer" for securing = Web=20 services. Choosing the absolutely correct balance of countermeasures and = acceptable risk can only be done on a case by case basis.

That said, there are common patterns of countermeasures that = experience shows reduce the risks to acceptable levels for many Web = services.=20 The Basic Profile adopts, but does not mandate use of, the most widely = used of=20 these: HTTP secured with either TLS 1.0 or SSL 3.0 (HTTPS). That is, = conformant=20 Web services may use HTTPS; they may also use other countermeasure = technologies=20 or none at all.

HTTPS is widely regarded as mature standard for encrypted transport=20 connections to provide a basic level of confidentiality. HTTPS thus = forms the=20 first and simplest means of achieving some basic security features which = are=20 required by many real-world web service applications. HTTPS may also be = used to=20 provide client authentication through the use of client-side = certificates.

This portion of the profile incorporates the following specifications = by=20 reference;

Basic Profile Version 1.0

Working Group Draft

Date: 2003/01/24 09:47:33

Abstract

Status of this Document

Notice

Feedback

Table of Contents

1. Introduction

1.1 Guiding Principles

1.2 Notational Conventions

2. Profile Conformance

2.1 Conformance of Artifacts

2.2 Conformance of Services and = Consumers

2.3 Conformance Annotation

3. Messaging

3.1 XML Representation of SOAP Messages

3.2 The SOAP Processing Model

3.3 Using SOAP in HTTP

4. Service Description

4.1 Document Structure

4.2 Types

4.3 Messages

4.4 Port Types

4.5 Bindings

4.6 Ports

4.7 Services

4.8 SOAP Binding

4.9 XML Schema

5. Service Publication and Discovery

5.1 bindingTemplates

5.2 tModels

6. Security

6.1 The Use of HTTPS

6.2 Certificate Authority

6.3 Permitted HTTPS Encryption = Algorithms