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: more on payload(s) inclusion and MEPs than our Request-ResponseMEP discussion covers

I should be clear: I realize section is presently about the 
Request/ReplyPattern/Value element content and that value is intended to 
describe how the RM-Reply is publicized.  This section is the only one in 
the document using the term "MEP" and the use of "application-level MEP" 
remains ambiguous (at best).  My suggested changes might appear elsewhere 
in the document (somewhere in sections 2 or 5) but would start from the 
bullets in

Turning the various options into editorial work will have to wait until we 
get some clarity on the TC leanings...


On 09-Jun-04 16:04, Doug Bunting wrote:

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]