[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsrm] more on payload(s) inclusion and MEPs than our Request-Response MEP discussion covers
It seems that 4.2.3.1 "restrictions" are indeed inconsistent with Table 26.
My first reaction would be to remove these usage guidelines/restrictions
from 4.2.3.1 (as I would argue that Section 4 is more about describing the detail of header elements and their wire semantics, and should leave out
the context of their use, which Section 5.2 would address in this case.)
At best, 4.2.3.1 "usage guidelines" should stay within the "wire scope",
and ignore MEPs "at application level" (i.e. WSDL) above that.
I think that means this section should restrict to say how these reply patterns fit in the assumed request-response protocol (RMP to RMP. We have made
the assumption of a "request-response protocol" in 2.1.)
Consequently I feel that any reference to the new "Respond" operation,
(like any linkage to other abstract operations), as well as to WSDL op types,
should be left out of this section.
Trying to flesh out [a variant of] option B in Doug's mail, I would annotate
each pattern value as:
- "Response" value: when this value appears in the request (reliable) message of
a req-resp protocol exchange, it indicates An RM-Reply MUST be sent back in the response message of the same exchange. A Request/ReplyPattern/Value element with
"Response" value MUST NOT appear in a response message of a req-resp protocol exchange.
- "Callback" value : when this value appears in the request (reliable) message of
a req-resp protocol exchange, it indicates An RM-Reply MUST be sent back
in the request message of a separate requ-resp exchange.
A Request/ReplyPattern/Value element with "Callback" value MUST NOT appear in a response message of a req-resp protocol exchange.
- "Poll" value:
Synchronous case: when this value appears in the request (reliable) message of
a req-resp protocol exchange, and when no Request/ReplyPattern/ReplyTo element is present, it indicates An RM-Reply related to the polled message IDs MUST be sent back in the response message of the same requ-resp exchange.
Asynchronous case: when this value appears in a message (either request or response of a req-resp protocol exchange), and when a Request/ReplyPattern/ReplyTo element is present, it indicates an RM-Reply MUST be sent back
in the request message of a separate requ-resp exchange.
As for Table 26, I think its title also need be updated with latest updates.
It should be something like:
" Recommended use of reply patterns with WSDL operations."
Not sure if we need other changes on Table 26.
I hope this is at least a good part of the solution, if not all of it ...
I will separately send the model extension updates ("Respond") discussed
yesterday in another mail.
Jacques
-----Original Message-----
From: Doug Bunting [mailto:Doug.Bunting@sun.com]
Sent: Wednesday, June 09, 2004 4:04 PM
To: wsrm@lists.oasis-open.org
Subject: [wsrm] more on payload(s) inclusion and MEPs than our
Request-Response MEP discussion covers
All,
(Sorry again to be a squeaky wheel and the length of this email.)
In thinking more about the various reply patterns, all could have a generic
"getting any payload back" issue, specific "responding to duplicate
messages" issue or both. I will be sending a separate email about the
"responding to duplicate messages" problem. Here, I concentrate on the
implications of implementing Jacques' suggestions for the rest of the
document.
Unfortunately, I have lifted a rock and do not like what I see beneath it.
Section 4.2.3.1 completely contradicts table 26 in section 5.2, even with
the recent updates to the table. The restrictions described in 4.2.3.1 are
somewhat implied (reasoning by example, not a great idea) in the HTTP
binding descriptions (near the top of sections 6.2 and 6.3) of fault
situations. The problem we have here with the Callback and Poll RM-Reply
patterns is a lack of clarity about the underlying protocol response to the
original message, an outgoing callback or a Poll request. While fault
situations are somewhat described, normal processing is not (except,
occasionally, by example). We are also left with little or no description
about a receiving RMP "bundling" payload(s) with the outgoing Callback
request or Poll publication (underlying protocol response or request for
the sync and async cases). Note that, while it would be a useful addition
to our specification, I am not clamouring for text on the details of
payload bundling. More, just when are payload(s) delivered for those reply
patterns?
Assuming relatively complete knowledge of the sections mentioned in the
previous paragraphs (sorry), alternatives here include:
A. Completely and consistently resolve the contradiction, likely in favour
of section 4.2.3.1's restrictions. This basically means applying the same
rules to all wire level exchanges as to the producer / consumer interaction
(application level WSDL, whatever that means). The synchronous Poll case
is probably an exception we would have to underscore because it requires a
wire-level request-response exchange. The new Respond operation would be
allowed only when the Response RM-Reply pattern is used.
Section 5.2 would change substantially in this case and might become
redundant.
B. Clarify section 4.2.3.1 to link the existing "pattern is not
applicable" sentences only to the initial sending RMP / receiving RMP
wire-level interaction (the delivery of the reliable message). That is,
the original message is sent using an RMP-to-RMP (remember this is not
about the consumer's description of the service they provide, that comes in
section 5.2 under this alternative) one-way operation unless the Response
RM-Reply pattern is in use and a request-response operation for that
pattern. The new Respond operation would provide consumer payload(s) to be
carried with the RMP publication.
How the published (receiving RMP provided) information must be delivered to
the original sending RMP should probably be described in this section as
well. The callback "request" is sent using a one-way operation and the
Poll and Response "response" is returned using either a one-way operation
(async poll case) or underlying protocol response (sync poll and Response
pattern cases). For the asynchronous Poll reply pattern, the wire protocol
requirements actually involve two one way operations.
Again, all of these WSDL operation types and related MEPs[2] are separate
from the application WSDL or "application level MEP" and are not written
down anywhere as WSDL but are made explicit in this section.
Section 5.2 would cover the overall producer / consumer interaction (again,
sometimes called the "application level WSDL" in our specification) and
what information a consumer may add to the Response pattern response,
Callback request or Poll publication. Effectively, section 5.2 describes
bundling payload(s) together with the RMP publication. The details of such
bundling would not necessarily be explicitly described in our document but
would be allowed.
C. Clarify section 4.2.3.1 to link the "pattern is not applicable" text to
the inclusion of consumer information with the published data. That is,
these restrictions cover the addition of payload(s) to the underlying
protocol response in the Response RM-Reply pattern and later publication in
a Callback request or Poll response. Patterns other than the Response
RM-Reply pattern would disallow any consumer information carried together
with the RMP publication.
Section 5.2 should be clarified to apply to the original message as well as
the overall producer / consumer interaction, allowing payload(s) to be
returned "immediately" though (in cases other than the Response RM-Reply
pattern) the RMP information will travel separately and such payload(s) are
not necessarily correlated with the original message(s) (and are certainly
not sent reliably). The use cases for this option seem a bit far fetched
since the RMP information would be expected to be available faster than any
consumer Respond invocation; we would expect the RMP to be able to respond
faster than the consuming system / user / application / ... The new
Respond operation would provide consumer payload(s) returned as part of the
initial message exchange.
The return of published information must be described (using identical
terminology to that recommended for section 4.2.3.1 in alternative B) in
this section.
This alternative is somewhat the opposite of B though the overall producer
/ consumer interactions are identical. In the B case, payloads are
optionally carried along with the RMP publication. For C, payloads are
optionally returned immediately as part of an initial request-response
(wire level) MEP. Yes, B and C result in identical handling for the
Response RM-Reply pattern.
----
I lean somewhat toward B since that would not require extensive changes to
the HTTP binding and seems somewhat more useful. However, any of these
alternatives would somewhat change the proposed definition of the Respond
operation. If we choose A, the Respond operation has strict restrictions
on when it may be invoked. In the B case, invoking this operation results
in magic occurring for the Callback and Poll RM-Reply patterns but may be
used for every pattern. If we chose C, the magic occurs in the initial
underlying protocol response.
Going a bit further down the rabbit hole, we also need to think more about
the "spontaneous" use of the Poll request message when the original message
was sent using the Response RM-Reply pattern (if we choose A above) and,
generally, when the consumer provides payload(s) associated with an
incoming message. The problem here arises primarily when the Poll request
mentions (asks for information about) multiple earlier messages. The
Response provides no mechanism to correlate individual payload(s) with
individual NonSequenceReply or single messages within the
SequenceReplies/ReplyRange.
Alternatives here include:
I. Additional words stating that any consumer-provided information (the
results of an earlier Respond operation) are quietly lost in this
situation. That is, the response to a Poll request never includes any
payload(s) -- no matter what RM-Reply pattern was used originally. This
would contradict the text in section 5.2 according to alternative B above.
II. Add a new warning in the Message Processing Fault set named
PayloadAvailable. This would inform the sending RMP of lost payload(s)
associated with messages within the referenced range.
III. Possibly along with (II), describe a special case in which the
response to a Poll request asks for information about a single earlier
message. Syntactically, such a Poll request would contain a single
RefToMessageIds element. In turn, that RefToMessageIds element must
contain 0 or 1 SequenceNumRange and, when SequenceNumRange is included, the
@from and @to values must match.
For this very special case, any information included in the SOAP Body would
be automatically correlated with the earlier message. Information provided
in a Respond operation would be published along with the acknowledgement
indication in support of this case.
Please note that saved information useful in responding to a Poll request
would also support "caching" Response RM-Reply pattern responses in case a
duplicate message comes later.
IV. Ensure the existing text does not disallow option III as an
implementation choice but otherwise remain silent on payload(s) included in
the response to a Poll request. I suspect (but am not sure) we have
nothing normative that would prevent use of III. However, the
non-normative text (a new note in section 5.2 for example) should at least
describe the correlation issue.
----
What do others prefer?
thanx,
doug
[1] Specifically, the negative (why negative?) links between RM-Reply
patterns and WSDL MEPs. The bullets in this section can be paraphrased as
stating the Response RM-Reply pattern may only be associated with
request-response MEPs and other RM-Reply patterns (Callback and Poll) may
only be associated with one-way MEPs (and WSDL operations of those types).
[2] Note that I am not particularly picky on terminology here and go back
and forth between WSDL operation types and MEPs. I am not making a
distinction. I also use the word "operation" to describe the abstract
interface between consumer or producer and associated RMP, mostly with
regard to the Respond operation.
To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]