OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[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

Title: RE: [wsrm] more on payload(s) inclusion and MEPs than our Request-Response MEP discussion covers

It seems that "restrictions" are indeed inconsistent with Table 26.

My first reaction would be to remove these usage guidelines/restrictions
from (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, "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.


-----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


(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

Unfortunately, I have lifted a rock and  do not like what I see beneath it.
Section completely  contradicts table 26 in section  5.2, even with
the recent updates to the table.  The restrictions described in 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

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'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

B.   Clarify  section  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 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 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

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?


[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]