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

Sent: Wednesday, June 09, 2004 4:04 PM

To: 

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.