SOAP Version 1.2 Part 2: Adjuncts

2.1.1 Edge labels

An edge label is an XML Schema Qualified Name (see XML Schema Part 2: Datatypes [5]). Two edge labels are equal if and only if both of the following are true:

1. Their local name values are the same.

2. Either of the following is true:

   1. Their namespace name values are missing.

   2. Their namespace name values are present and the same.

See 2.3 Values for uses of edge labels and position to distinguish the members of encoded values, and XML Schema Part 2: Datatypes [5] for more information about comparing XML qualified names.

2.2.1 Single and Multi reference nodes

A graph node may be single reference or multi reference. A single reference graph node has a single inbound edge. A multi reference graph node has multiple inbound edges.

3.1.1 Encoding graph edges and nodes

Each graph edge is encoded as an element information item and each element information item represents a graph edge. 3.1.3 Encoding compound values describes the relationship between edge labels and the local name and namespace name properties of such element information items.

The graph node at which an edge terminates is determined by examination of the serialized XML as follows:

1. If the element information item representing the edge does not have a ref attribute information item (see 3.1.5.2 ref Attribute Information Item) among its attributes then that element information item is said to represent a node in the graph and the edge terminates at that node.

2. If the element information item representing the edge does have a ref attribute information item (see 3.1.5.2 ref Attribute Information Item) among its attributes, then the value of that attribute information item MUST be identical to the value of exactly one id attribute information item ( see 3.1.5.1 id Attribute Information Item) in the same envelope. In this case the edge terminates at the graph node represented by the element information item on which the id attribute information item appears. That element information item MUST be in the scope of an encodingStyle attribute with a value of "http://www.w3.org/2001/12/soap-encoding".

All nodes in the graph are encoded as described in 1 above. Additional inbound edges for multi reference graph nodes are encoded as described in 2 above.

3.1.2 Encoding simple values

The lexical value of a terminal graph node (simple value) is the sequence of Unicode characters identified by the character information item children of the element information item representing that node.

3.1.3 Encoding compound values

An outbound edge of a graph node is encoded as an element information item child of the element information item that represents the node (see 3.1.1 Encoding graph edges and nodes). Particular rules apply depending on what kind of compound value the graph node represents. These rules are as follows:

1. For a graph edge which is distinguished by label ("struct" or "generic"), the namespace name and local name properties of the element information item together determine the value of the edge label.

2. For a graph edge which is distinguished by position ("array" or "generic"):

   • The ordinal position of the graph edge corresponds to the position of the element information item relative to its siblings

   • If outbound edges are distinguished only by position ("array") then the local name and namespace name properties of the element information item are not significant.

3. The following rules apply to the encoding of a graph node that represents an "array":

   • The element information item representing an array node MAY have among its attributes an itemType attribute information item (see 3.1.4.1 itemType Attribute Information Item).

   • The element information item representing an array node MAY have among its attributes an arraySize attribute information item (see 3.1.6 arraySize Attribute Information Item).

4. If a graph edge does not terminate in a graph node then it can either be omitted from the serialization or it can be encoded as an element information item with an xsi:nil attribute information item whose value is "true".

3.1.4 Computing the Type Name property

The type name property of a graph node is a {namespace name, local name} pair computed as follows:

1. If the element information item representing the graph node has an xsi:type attribute information item among its attributes then the type name property of the graph node is the value of the xsi:type attribute information item.

   Note:

   This attribute is of type QName in the namespace named "http://www.w3.org/2001/XMLSchema" (see XML Schema Part 2: Datatypes [5]); its value consists of the pair {namespace name, local name}. Neither the prefix used to construct the QName nor any information relating to any definition of the type is considered to be part of the value. The SOAP graph carries only the qualified name of the type.

2. Otherwise if the parent element information item of the element information item representing the graph node has a soap:itemType attribute information item (see 3.1.4.1 itemType Attribute Information Item) among its attributes then the type name property of the graph node is the value of the soap:itemType attribute information item

3. Otherwise the value of the type name property of the graph node is unspecified.

3.1.5 Unique identifiers

3.1.6 arraySize Attribute Information Item

The arraySize attribute information item has the following Infoset properties:

• A local name of arraySize ;

• A namespace name of "http://www.w3.org/2001/12/soap-encoding".

• A default value of "*"

The type of the arraySize attribute information item is arraySize in the namespace named "http://www.w3.org/2001/12/soap-encoding".

The value of the arraySize attribute information item MUST conform to the following EBNF grammer

[1]	arraySizeValue	::=	("*" | concreteSize) nextConcreteSize*
[2]	nextConcreteSize	::=	" " concreteSize
[3]	concreteSize	::=	[0-9]+

The array's dimensions are represented by each item in the list of sizes (unspecified size in case of the asterisk). The number of items in the list represents the number of dimensions in the array. The asterisk, if present, MUST only appear in the first position in the list.

4.1.1 Identification of RPC Resources

The World Wide Web identifies resources with URIs, but common programming conventions convey identification information in the arguments to procedures, or in the names of those procedures. For example, the call: "updateQuantityInStock(PartNumber="123", NewQuantity="200") suggests that the resource to be updated is the QuantityInStock for PartNumber "123". Accordingly, when mapping to or from a programming language method or procedure call, any arguments that serve to identify resources (such as the part number above) should when practical be represented in the URI to which the SOAP message is addressed. When mapping to or from a programming language method or procedure call, the name of which identifies or qualifies the identification of a resource (such as QuantityInStock above), such naming or qualification should when practical be represented in the URI to which the SOAP message is addressed. No standard means of representation of arguments or method names is provided by this specification.

4.1.2 Distinguishing Resource Retrievals from other RPCs

The World Wide Web depends on mechanisms that optimize commonly performed information retrieval tasks. Specifically, protocols such as HTTP [2] provide a GET method which is used to perform safe retrievals, I.e. to perform retrievals that are idempotent, free of side effects, and for which security considerations do not preclude the use of cached results or URI-based resource identification.

Certain procedure or method calls represent requests for information retrieval. For example, the call: "getQuantityInStock(PartNumber="123") might be used to retrieve the quantity established in the example above. The following conventions can be employed to implement SOAP retrievals and other RPC's on the Web:

• The conventions described in 4.1.1 Identification of RPC Resources are used to identify the resource with a URI.

• In cases where all the arguments have been represented in the URI, no SOAP header blocks are to be transmitted, and the operation is a safe retrieval, the 6.4 Web Method Specification Feature feature and the 6.3 SOAP Response Message Exchange Pattern MEP is used. Accordingly, no SOAP envelope is transmitted for the request, and the "webmeth:Method" property is set to GET. The results of the retrieval are a SOAP RPC response as described in 4.2.2 RPC Response

• In cases where the operation to be performed is not a retrieval, when SOAP headers are to be transmitted (a digital signature, for example), or when a retrieval is not safe, the 6.4 Web Method Specification Feature feature and the 6.2 Request-Response Message Exchange Pattern MEP is used. The request envelope is encoded as described in 4.2.1 RPC Invocation, and the results are as described in 4.2.2 RPC Response. The "webmeth:Method" property is set to POST.

The SOAP RPC Representation does not define any other value for the "webmeth:Method".

4.2.1 RPC Invocation

An RPC invocation is modeled as a struct where parameter access is by name or as an array where parameter access is by position.

• The invocation is represented by a single struct or array containing an outbound edge for each [in] or [in/out] parameter. The struct or array is named identically to the procedure or method name (see A. Mapping Application Defined Names to XML Names).

• Each outbound edge either has a label corresponding to the name of the parameter (see A. Mapping Application Defined Names to XML Names) or a position corresponding to the position of the parameter.

Applications MAY process invocations with missing parameters but also MAY fail to process the invocation and return a fault.

4.2.2 RPC Response

An RPC response is modeled as a struct where parameter access is by name or as an array where parameter access is by position.

• The response is represented by a single struct or array containing an outbound edge for the return value and each [out] or [in/out] parameter.

• If the response is represented by a struct, then each parameter is represented by an outbound edge with a label corresponding to the name of the parameter (see A. Mapping Application Defined Names to XML Names). A non-void return value is represented in the struct by an outbound edge that may be given any unique label. The QName of the label of the edge representing the return value is given by a separate outbound edge with a local name of result and the namespace name "http://www.w3.org/2001/12/soap-rpc". This result outbound edge MUST be present and hold the qname of the edge containing the return value within any struct response if the return value of the procedure is non-void. This result outbound edge MUST NOT be present if the return value of the procedure is void.

• If the response is represented by an array, each outbound edge has a label corresponding to the position of the parameter. A return value MUST be present if the return value of the procedure is non-void. If present, the return value MUST be represented as the first edge of the array with parameters following. If no return value is present, then parameters begin with the first outbound edge of the array.

• Invocation faults are handled according to the rules in 4.4 RPC Faults. If a protocol binding adds additional rules for fault expression, those MUST also be followed.

An RPC response MUST NOT contain both a result and a fault, because a result indicates success and a fault indicates failure.

4.2.3 SOAP Encoding Restriction

When using SOAP encoding (see 3. SOAP Encoding) in conjunction with the RPC convention described here, the SOAP Body MUST contain only a single child element information item, that child being the serialized RPC invocation or response struct or array. I.e. when using the SOAP encoding for serializing RPC invocations and responses, the encoding is constrained to produce a single tree of element information items.

5.1.1 Properties

Under the convention, properties are represented as follows:

• Properties are named with XML qualified names (QNames). For example, myNS:RetryCount where RetryCount is the name of the property, and myNS is a prefix mapped to a namespace.

• Property values are typed, and the type of a property-value is defined by an XML Schema simple datatype in the specification which introduces the property. For example, the type of RetryCount is xsi:int .

5.1.2 Property Scope

Properties within a SOAP node can differ in terms of their scope and the origins of their values. Some properties are scoped per message-exchange, while others have a wider significance. For example, the scope of a SOAP message property is per message-exchange, but the scope of a User Identity property may extend beyond the exchange of a single message. The values of some properties arise directly from the operations of the SOAP node and message exchanges, while others arise in implementation specific ways due to the local environment. As shown in the figure below, we make the distinction between per message-exchange and more widely scoped properties by assigning them to different containers called Message Exchange Context and Environment respectively. All properties, regardless of their scope, are shared by SOAP and a particular Binding.

The values of properties in Environment may depend upon local circumstances (as depicted by the external arrow from Environment in the figure above). More specifically, the properties in the example could be influenced by an Operating System User ID on whose behalf a message exchange is being executed. The mapping of information in a particular implementation to such properties is outside the scope of the binding framework although the abstract representation of such information as properties is not.

5.1.3 Properties and Features

A feature may be expressed through multiple properties and a single property may enable more than one feature. For example, the properties called User ID and Password may be used to enable a feature called Authentication. As a second example, a single property called Message ID could be used to enable one feature called Transaction and a second feature called Message Correlation.

6.2.1 SOAP Feature Name

This message exchange pattern is identified by the URI:

• "http://www.w3.org/2001/12/soap/mep/request-response/"

Protocol binding specifications may use this URI to declare their support for the MEP and its associated semantics.

6.2.2 Description

The Request-Response MEP defines a pattern for the exchange of two messages between two adjacent SOAP nodes along a SOAP message path. One message is exchanged in each direction between a requesting SOAP node and a responding SOAP node.

In the normal operation of a message exchange conforming to the Request-Response MEP, a request message is first transferred from the requesting SOAP node to the responding SOAP node. Following the successful processing of the request message by the responding SOAP node, a response message is transferred from the responding SOAP node to the requesting SOAP node.

Abnormal operation during a Request-Response message exchange may be caused by a failure to transfer the request message, a failure at the responding SOAP node to process the request message, or a failure to transfer the response message. Such failures might be silent at either or both of the requesting and responding SOAP nodes involved. Also, during abnormal operation each SOAP node involved in the message exchange might differ in its determination of the successful completion of the message exchange.

The scope of a Request-Response MEP is limited to the exchange of a request message and a response message between one requesting and one responding SOAP node. This pattern does not mandate any correlation between multiple requests nor specific timing for multiple requests. Implementations MAY choose to support multiple ongoing requests (and associated response processing) at the same time.

6.2.3 State Machine Description

The Request-Response MEP defines a set of properties described in Table 3.

Table 3: Property definitions for Request-Response MEP

Property Name	Property Description
reqres:Role	A URI denoting the pattern specific role of the local SOAP node participating in the message exchange.
reqres:State	A URI denoting the current state of the message exchange. This value is managed by the binding instance and may be inspected by other entities monitoring the progress of the message exchange.
reqres:OutboundMessage	An abstract structure that represents the current outbound message in the message exchange. This abstracts both SOAP Envelope and any other information structures that are transferred along with the envelope.
reqres:InboundMessage	An abstract structure that represents the current inbound message in the message exchange. This abstracts both SOAP Envelope and any other information structures that are transferred along with the envelope.
reqres:ImmediateDestination	A URI denoting the immediate destination of an outbound message.
reqres:ImmediateSender	A URI denoting the immediate sender of an inbound message.

To initiate a message exchange conforming to the Request-Response MEP, the requesting SOAP node instantiates a local message exchange context. Table 4 describes how the context is initialized.

Table 4: Instantiation of a Message Exchange Context for a requesting SOAP node

Property Name	Property Value
context:ExchangePatternName	"http://www.w3.org/2001/12/soap/mep/request-response/"
context:FailureReason	None
reqres:Role	RequestingSOAPNode
reqres:State	Init
reqres:OutboundMessage	An abstraction of the request message
reqres:ImmediateDestination	An identifier (URI) that denotes the responding SOAP node

There may be other properties related to the operation of the message exchange context instance. Such properties are initialized according to their own feature specifications.

Once the message exchange context is initialized, control of the context is passed to a (conforming) local binding instance.

The diagram below shows the logical state transitions at the requesting and responding SOAP nodes during the lifetime of the message exchange. At each SOAP node, the local binding instance updates (logically) the value of the reqres:State property to reflect the current state of the message exchange. The state names are relative URIs, relative to a Base URI value carried in the reqres:Role property of the local message exchange context.

When the local binding instance at the responding SOAP node starts to receive an inbound request message, it (logically) instantiates a message exchange context. Table 5 describes the properties that the binding initializes as part of the context's instantiation.

Table 5: Instantiation of Message Exchange Context for an inbound request message

Property Name	Property Value
context:ExchangePatternName	"http://www.w3.org/2001/12/soap/mep/request-response/" Initialized as early as possible during the life cycle of the message exchange.
context:FailureReason	None
reqres:Role	RespondingSOAPNode Initialized as early as possible during the life cycle the message exchange.
reqres:State	Init

When the requesting and responding SOAP nodes transition between states, the local binding instance (logically) updates a number of properties. Table 6 and Table 7 describe these updates for the requesting and the responding SOAP nodes, respectively.

Table 6: Requesting SOAP Node State Transitions

CurrentState	Transition Condition	NextState	Action
Init	Unconditional	Requesting	Initiate transmission of request message abstracted in reqres:OutboundMessage .
Requesting	Message transmission failure	Fail	Set context:FailureReason to "transmissionFailure"
	Start receiving response message	Sending+Receiving	Set reqres:ImmediateSender to denote the sender of the response message (may differ from the values in reqres:ImmediateDestination ). Start making an abstraction of the response message available in reqres:InboundMessgae .
Sending+Receiving	Message exchange failure	Fail	Set context:FailureReason to "exchangeFailure"
	Completed sending request message. Completed receiving response message.	Success

 

Table 7: Responding SOAP Node State Transitions

CurrentState	Transition Condition	NextState	Action
Init	Start receiving request message	Receiving	Set reqres:ImmediateSender to denote the sender of the request message (if determinable). Start making an abstraction of the request message available in reqres:InboundMessgae . Pass control of message exchange context to SOAP processor.
Receiving	Message reception failure	Fail	Set context:FailureReason to "receptionFailure".
	Start of response message available in reqres:OutboundMessage	Receiving+Sending	Initiate transmission of response message abstracted in reqres:OutboundMessage .
Receiving+Sending	Message exchange failure	Fail	Set context:FailureReason to "exchangeFailure".
	Completed receiving request message. Completed sending response message.	Success

Bindings that implement this MEP MAY provide for streaming of SOAP responses. That is, responding SOAP nodes MAY begin transmission of a SOAP response while a SOAP request is still being received and processed. When SOAP nodes implement bindings that support streaming, the following rules apply:

• All the rules in [1] Binding Framework regarding streaming of individual SOAP messages MUST be obeyed for both request and response SOAP messages.

• When using streaming SOAP bindings, requesting SOAP nodes MUST avoid deadlock by accepting and if necessary processing SOAP response information while the SOAP request is being transmitted.

  Note:

  Depending on the implementation used and the size of the messages involved, this rule MAY require that SOAP applications stream application-level response processing in parallel with request generation.

• A requesting SOAP node MAY enter the Fail state, and thus abort transmission of the outbound SOAP request, based on information contained in an incoming streamed SOAP response.

6.2.4 Fault Handling

During the operation of the Request-Response MEP, the participating SOAP nodes may generate SOAP faults.

If a SOAP fault is generated by the responding SOAP node while it is in the Receiving state, the SOAP fault is made available in reqres:OutboundMessage and the state machine transitions to the Receiving+Sending state.

This MEP makes no claims about the disposition or handling of SOAP faults generated by the requesting SOAP node during any processing of the response message that follows the Success state in the requesting SOAP node's state transition table (see Table 6).

6.3.1 SOAP Feature Name

This message exchange pattern is identified by the URI:

• "http://www.w3.org/2001/12/soap/mep/soap-response/"

Protocol binding specifications may use this URI to declare their support for the MEP and its associated semantics.

6.3.2 Description

The SOAP Response MEP defines a pattern for the exchange of a non-SOAP message acting as a request followed by a SOAP message acting as a response. In the absence of errors or faults, this message exchange pattern consists of two messages, only one of which is a SOAP envelope:

• A request transmitted in a binding-specific manner that does not include a SOAP envelope and hence does not involve any SOAP processing by the receiving SOAP node.

• A response message which contains a SOAP envelope. The MEP is completed by the processing of the SOAP envelope following the rules of the SOAP processing model (see [ref. to chapter 2]).

Abnormal operation during a SOAP Response message exchange may be caused by a failure to transfer the request message or the response message. Such failures MAY be silent at either or both of the requesting and responding SOAP nodes involved. Also, during abnormal operation each SOAP node involved in the message exchange MAY differ in its determination of the successful completion of the message exchange (see also section 6.3.4 Fault Handling).

The scope of a SOAP Response MEP is limited to the request for an exchange of a response message between one requesting and one responding SOAP node. This pattern does not mandate any correlation between multiple requests nor specific timing for multiple requests. Implementations MAY choose to support multiple ongoing requests (and associated response processing) at the same time.

6.3.3 State Machine Description

The SOAP Response MEP defines a set of properties described in Table 8.

Table 8: Property definitions for SOAP Response MEP

Property Name	Property Description
reqres:Role	A URI denoting the pattern specific role of the local SOAP node participating in the message exchange.
reqres:State	A URI denoting the current state of the message exchange. This value is managed by the binding instance and may be inspected by other entities monitoring the progress of the message exchange.
reqres:OutboundMessage	An abstract structure that represents the current outbound message in the message exchange. This abstracts both SOAP Envelope Infoset (which MAY be null) and any other information structures that are transferred along with the envelope.
reqres:InboundMessage	An abstract structure that represents the current inbound message in the message exchange. This abstracts both SOAP Envelope Infoset (which MAY be null) and any other information structures that are transferred along with the envelope. Editorial note   ifwe were to adopt the suggestion that Stuart proposed in response to Noah's suggestion that these properties be named reqres:RequestMessage and reqres:ResponseMessage then only one would be defined as having an empty (null?) Soap Envelope Infoset
reqres:ImmediateDestination	A URI denoting the immediate destination of an outbound message.
reqres:ImmediateSender	A URI denoting the immediate sender of an inbound message.

To initiate a message exchange conforming to the SOAP Response MEP, the requesting SOAP node instantiates a local message exchange context. Table 9 describes how the context is initialized.

Table 9: Instantiation of a Message Exchange Context for a requesting SOAP node

Property Name	Property Value
context:ExchangePatternName	"http://www.w3.org/2001/12/soap/mep/soap-response/"
context:FailureReason	None
reqres:Role	RequestingSOAPNode
reqres:State	Init
reqres:OutboundMessage	An abstraction of the request message that does not include a SOAP envelope infoset.
reqres:ImmediateDestination	An identifier (URI) that denotes the responding SOAP node

There may be other properties related to the operation of the message exchange context instance. Such properties are initialized according to their own feature specifications.

Once the message exchange context is initialized, control of the context is passed to a (conforming) local binding instance.

The diagram below shows the logical state transitions at the requesting and responding SOAP nodes during the lifetime of the message exchange. At each SOAP node, the local binding instance updates (logically) the value of the reqres:State property to reflect the current state of the message exchange. The state names are relative URIs, relative to a Base URI value carried in the reqres:Role property of the local message exchange context.

When the local binding instance at the responding SOAP node starts to receive an inbound request message, it (logically) instantiates a message exchange context. Table 10 describes the properties that the binding initializes as part of the context's instantiation.

Table 10: Instantiation of Message Exchange Context for an inbound request message

Property Name	Property Value
context:ExchangePatternName	"http://www.w3.org/2001/12/soap/mep/soap-response/" Initialized as early as possible during the life cycle of the message exchange.
context:FailureReason	None
reqres:Role	RespondingSOAPNode Initialized as early as possible during the life cycle the message exchange.
reqres:State	Init

When the requesting and responding SOAP nodes transition between states, the local binding instance (logically) updates a number of properties. Table 11 and Table 12 describe these updates for the requesting and the responding SOAP nodes, respectively.

Table 11: Requesting SOAP Node State Transitions

CurrentState	Transition Condition	NextState	Action
Init	Unconditional	Requesting	???
Requesting	Message transmission failure	Fail	Set context:FailureReason to "transmissionFailure"
	Start receiving response message	Sending+Receiving	Set reqres:ImmediateSender to denote the sender of the response message (may differ from the values in reqres:ImmediateDestination ). Start making an abstraction of the response message available in reqres:InboundMessgae .
Sending+Receiving	Message exchange failure	Fail	Set context:FailureReason to "exchangeFailure"
	Completed receiving response message.	Success

 

Table 12: Responding SOAP Node State Transitions

CurrentState	Transition Condition	NextState	Action
Init	Start receiving request message	Receiving	Set reqres:ImmediateSender to denote the sender of the request message (if determinable). making an abstraction of the request message available in reqres:InboundMessgae . Pass control of message exchange context to SOAP processor.
Receiving	Message reception failure	Fail	Set context:FailureReason to "receptionFailure".
	Start of response message available in reqres:OutboundMessage	Receiving+Sending	Initiate transmission of response message abstracted in reqres:OutboundMessage .
Receiving+Sending	Message exchange failure	Fail	Set context:FailureReason to "exchangeFailure".
	Completed sending response message.	Success

Bindings that implement this MEP MAY provide for streaming of SOAP responses. That is, responding SOAP nodes MAY begin transmission of a SOAP response while a SOAP request is still being received and processed. When SOAP nodes implement bindings that support streaming, the following rules apply:

• All the rules in [1] Binding Framework regarding streaming of individual SOAP messages MUST be obeyed for both request and response SOAP messages.

• When using streaming SOAP bindings, requesting SOAP nodes MUST avoid deadlock by accepting and if necessary processing SOAP response information while the SOAP request is being transmitted.

  Note:

  Depending on the implementation used and the size of the messages involved, this rule MAY require that SOAP applications stream application-level response processing in parallel with request generation.

• A requesting SOAP node MAY enter the Fail state, and thus abort transmission of the outbound SOAP request, based on information contained in an incoming streamed SOAP response.

6.3.4 Fault Handling

During the operation of the SOAP Response MEP, the participating SOAP nodes may generate SOAP faults.

This MEP makes no claims about the disposition of SOAP faults generated by the responding SOAP node.

A responding SOAP node MAY express fault information as a result of processing the request in the form of a SOAP fault. This can for example be used to express information that might be useful to a receiving SOAP node. If a SOAP fault is generated by the responding SOAP node while it is in the Receiving state, the SOAP fault is made available in reqres:OutboundMessage and the state machine transitions to the Receiving+Sending state.

This MEP makes no claims about the disposition or handling of SOAP faults generated by the requesting SOAP node during any processing of the response message that follows the Success state in the requesting SOAP node's state transition table (see Table 11).

6.4.1 SOAP Feature Name

This Web Method Specification Feature is identified by the URI:

• "http://www.w3.org/2001/12/soap/features/web-method/"

Protocol binding specifications may use this URI to declare their support for the this feature and its associated semantics.

6.4.2 Description

Underlying protocols designed for use on the World Wide Web provide for manipulation of resources using a small set of Web methods such as GET, PUT, POST, and DELETE. These methods are formally defined in the HTTP specification [2], but other underlying protocols also support them. Bindings to HTTP or such other protocols SHOULD use the Web Method Specification Feature to give applications control over the Web methods to be used when sending a SOAP message.

Bindings supporting this feature SHOULD use the appropriate embodiment of that method as provided by the underlying protocol; for example, the HTTP binding provided with this specification represents the GET Web method as an HTTP GET request, and the POST method as an HTTP POST request (see 7. SOAP HTTP Binding). Bindings supporting this feature SHOULD provide to the receiving node indication of the Web method used for transmission.

The SOAP Web Method Specification Feature MAY be implemented by bindings to underlying transports that have no preferred embodiment of particular Web methods (E.g. do not distinguish GET from POST). Such bindings SHOULD provide to the receiving node indication of the Web method used for transmission, but need take no other action in support of the feature.

6.4.3 Web Method Feature State Machine

The Web Method Feature defines a single property, which is described in Table 13.

Table 13: Property definition for the Web Method Feature

Property Name	Property Description
webmeth:Method	One of GET, POST, PUT, DELETE (or others which may subsequently be added to the repertoire of Web methods.)

This specification provides for the use of the Web Method Feature in conjunction with the 6.2 Request-Response Message Exchange Pattern and 6.3 SOAP Response Message Exchange Pattern message exchange patterns. This feature MAY be used with other MEPs if and only if provided for in the specifications of those MEPs.

A node sending a request message MUST provide a value for the webmeth:Method property. A protocol binding supporting this feature SHOULD set the value of the webmeth:Method property at the receiving node to match that provided by the sender; the means of transmission for the method property is binding-specific. A responding node SHOULD respond in a manner consistent with the Method requested (e.g. a GET should result in retrieval of a representation of the identified resource) or SHOULD fault in an application-specific manner if the Web method cannot be supported.

Editorial note
Should this feature define a standard fault to be used in this case? If so, we can map it to the appropriate HTTP status code, I would think. [NRM 6/4/2002]

Applications SHOULD use GET as the value of webmeth:Method in conjunction with the 6.3 SOAP Response Message Exchange Pattern to support information retrievals which are safe, and for which no parameters other than a URI are required; I.e. when performing retrievals which are idempotent, known to be free of side effects, for which no SOAP request headers are required, and for which security considerations do not conflict with the possibility that cached results would be used. Except in unusual circumstances, other operations SHOULD be performed using POST in conjunction with the 6.2 Request-Response Message Exchange Pattern. Other methods SHOULD not in general be used. For example, use of PUT would suggest storing the SOAP envelope Infoset as the created resource, as opposed to processing in the manner required by the SOAP processing model.

7.5.1 Behavior of Requesting SOAP Node

The overall flow of the behavior of a requesting SOAP node follows a state machine description consistent with both 6.2 Request-Response Message Exchange Pattern and 6.3 SOAP Response Message Exchange Pattern (differences are indicated as necessary.) This binding supports streaming and, as a result, requesting SOAP nodes MUST avoid deadlock by accepting and if necessary processing SOAP response information while the SOAP request is being transmitted (see 6.2.3 State Machine Description). The following subsections describe each state in detail.