Re: more on payload(s) inclusion and MEPs than our Request-ResponseMEP discussion covers

[Doug Bunting <Doug.Bunting@Sun.COM>]

I should be clear: I realize section 4.2.3.1 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 4.2.3.1.

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

thanx,
	doug

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