Proposed resolution for issue 103

The TBTF has discussed issue 103 [1] and proposes the following word
change in order to solve it. Note that this proposal is based on the
latest SOAP 1.2 part 2 [2] editor's revision to which it proposes small
changes. I hope I in this captured the viewpoints put forward by the
TBTF, if not then please let me know! Issue 103 states:

"Regardless of the protocol to which SOAP is bound, messages are routed
along a so-called "message path", which allows for processing at one or
more intermediate nodes in addition to the ultimate destination." As
discussed in the referenced e-mail, "SOAP does refer to a message path,
which appears to be post facto the ordered locations and processing
(there is vagueness here) that actually were visited in processing the
message. There is at least an attempt to associate special behavior with
the "end" of the path, where header entries with no actor are processed.
The details of all this need to be stated more precisely." This is
related to the suggestion that the notion of message pattern (e.g.
request/response) also be clarified. This issue needs to be revisited
after TBTF concludes its work."

DISCUSSION

The proposed rewrite of the introduction of section 2 says:

* * * * *

SOAP messages are fundamentally one-way transmissions from a SOAP sender
to a SOAP receiver; however, SOAP messages are often combined to
implement patterns such as request/response.

SOAP implementations can be optimized to exploit the unique
characteristics of particular network systems. For example, the HTTP
binding described in [1](SOAP in HTTP) provides a request/response
message exchange pattern that may be leveraged by SOAP applications.

SOAP provides a distributed processing model that assumes that a SOAP
message originates at an initial SOAP sender and is sent to an ultimate
SOAP receiver via zero or more SOAP intermediaries. This section defines
the SOAP distributed processing model. Section 5 defines a framework for
describing how additional features such as routing, reliability and
security fit into the distributed processing model.

* * * * *

This is quite close to where we want to be than the current section 2.
The proposal below only suggests small changes to this text. In
addition, there are some pieces of the terminology section that needs to
be updated in order to fit the model.

PROPOSAL

The proposed rewrite of the introduction is as follows:

* * * * *

SOAP provides a distributed processing model that assumes that a SOAP
message originates at an initial SOAP sender and is sent to an ultimate
SOAP receiver via zero or more SOAP intermediaries.

The SOAP distributed processing model can support many message exchange
patterns including but not limited to one-way messages, request/response
interactions, and peer-to-peer conversations.

This section defines the SOAP distributed processing model. Section 5
defines a framework for describing how message exchange patterns as well
as additional features such as routing, reliability and security
interact with the distributed processing model.

* * * * *

In addition, there are some minor changes in the terminology section:

1) In the definition of "SOAP message path" replace "the ultimate SOAP
receiver" with "an ultimate SOAP receiver" resulting in:

"The set of SOAP senders and SOAP receivers through which a single SOAP
message passes. This includes the initial SOAP sender, zero or more SOAP
intermediaries, and an ultimate SOAP receiver."

2) In the definition of "SOAP intermediary" replace "towards the
ultimate" with "towards an ultimate" resulting in:

A SOAP intermediary is both a SOAP receiver and a SOAP sender and is
target-able from within a SOAP message. It processes a defined set of
SOAP header blocks in a SOAP message along a SOAP message path. It acts
in order to forward the SOAP message towards an ultimate SOAP receiver.

3) In the definition of "Ultimate SOAP receiver", remove the first
sentence and modify resulting in the following text:

The ultimate SOAP receiver is responsible for processing the contents of
the SOAP body. Normally the ultimate receiver is the last SOAP node
along the SOAP message path. As described in section 2, a SOAP ultimate
receiver cannot also be a SOAP intermediary. In certain circumstances, a
SOAP message may not reach the ultimate recipient because of a SOAP
fault generated by a SOAP node along the SOAP message path.

Comments?

Henrik Frystyk Nielsen
mailto:henrikn@microsoft.com

[1] http://www.w3.org/2000/xp/Group/xmlp-issues#x103
[2] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html

Received on Friday, 15 February 2002 19:40:58 UTC