Re: [wsrm] Detailed proposal to allow Batching of Acks and RM faultsusing ResponseReply pattern.

[Sunil Kunisetty <sunil.kunisetty@oracle.com>]

 Tony,

 You have took words out of my mouth ;-)

 All,

 I have sent a similar mail to the task group. Attached is that mail
 for a wider audience as the discussion moved to the list
 from the small task force.

 -Sunil

Tony Graham wrote:

> Tom Rutt <tom@coastin.com> wrote at Fri, 20 Feb 2004 22:44:23 -0500:
> > Sunil Kunisetty wrote:
> > >Tom Rutt wrote:
> ...
> > >>Replace the last two sentence in the above quoted text with the following:
> > >>“
> > >>Acknolwedgements or RM fault indications for former requests MAY also be
> > >>included in the response,
> > >>if they were unable to be returned in their own responses.
> > >
> > > -1.
> > >
> > > In R-R case, when the Sender doesn't receive a response, they will
> > > generally do a retry. So I don't see a need to support this use case.
> >
> > If the ack was not able to be sent due to lost transport connection,
> > then the receving rmp may want to
> > send the ack with the response to a future reliable message.
>
> It is true that it may be useful to resend a lost Acknowledgment in a
> subsequent reliable message, but I don't know that it is all that
> useful to do so when the Acknowledgment is for a message sent using
> the Response reply pattern.
>
> In the Request/Response operation (not One-Way), you would expect that
> the sending application blocks until it receives a response to its
> message.
>
> If the Request/Response message is sent using the Response reply
> pattern, you would also expect both the Acknowledgment and the
> response to the payload message to be in the HTTP response to the sent
> Reliable message.
>
> If the HTTP response is lost or not able to be sent due to a lost
> transport connection, sending the Acknowledgment in a subsequenct
> reliable message maybe helps the RMP but doesn't help the application.
>
> If, for the Response reply pattern, the response is lost, all that
> should be expected is that the sending RMP retries.
>
> Regards,
>
> Tony Graham
> ------------------------------------------------------------------------
> Web Products, Technologies and Standards           Phone: +353 1 8199708
> Sun Microsystems                                              x(70)19708
> East Point Business Park, Dublin 3, Ireland
>
> 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.
Subject: Re: New Response schema
Date: Sat, 21 Feb 2004 19:56:41 -0800
From: Sunil Kunisetty <sunil.kunisetty@oracle.com>
Organization: Oracle Corporation
To: Doug Bunting <Doug.Bunting@Sun.COM>,
     Tony Graham <Tony.Graham@Sun.COM>,
     Jacques Durand <JDurand@us.fujitsu.com>,
     Tom Rutt <tom@coastin.com>,
     "'kiwasa@jp.fujitsu.com'" <kiwasa@jp.fujitsu.com>


 Doug,

 Let me try again. I'm also CCing Fujitsu folks as Tom also has
 similar concerns.

 Before I come to this case, let me focus more on my 2nd concern,
 i.e., there is a fundamental problem with this model (batching of
 Acks for a R-R case).

 What is a R-R case? Sender sends a request to a Receiver
 and Receiver processes it and sends the response on the
 underlying transport.

 For all practical reasons, a response is treated as an Ack and
 hence the likelihood of people using RM for R-R is less than 1%
 of total RM usecase. I can think of some small use case for
 RM for R-R case, but that's irrelevant here.

 So lets assume someone has selected RM-AckRequested with
 wsdl 1.1 R-R operation. So currently the spec. says that Ack
 or Fault should be sent back on the SAME underlying transport
 as that of response.

 So delayed or batching of Ack on R-R case is prohibited right there.
 That's what I meant by fundamental problem. If someone really
  wanted a delayed or batched Ack/Fault, they can always use
  Callback or Poll pattern in the first place.

 Lets assume as Tom suggested in one of his mails, that we relax
 this restriction. So ack or fault can be sent back on a different
 (or a later) response. While we have control over to delay the
 Ack or Fault, we as a RMP, have no control over the response.
 So response has to still go on the initial transport response as
 per SOAP & WSDL.

 So lets again assume we only send the Ack or Fault in a different
 underlying transport response than the actual operation's response.
 Again there are 2 fundamental problems here:
    - We don't know for sure that a later response always exist
    - Identity of Sender is not sure

 Lets get to the 2nd problem later. 1st is not that critical. May be
 we can send ONLY when we know that a later response exists
 or when 1st is delayed or so.

 Assume for a second, both are not  issues. So what does it mean
 that I got an Ack or RM-Fault without the response?

 Ex: I've a stockQuote example. It is a R-R one-way operation.
 Operation1:  getStockQuote ("MSFT").
 Assume MSFT stock is being halted ;-) for some reasons and
  there is no response or ack or a fault.

 Operation2: getStockQuote("ORCL");
 So if we have to send the Ack or Fault for the 1st and 2nd one on this
 response, essentially I could have got an Ack for Msg1 without the
 stock quote value for MSFT. What does that really mean? How
 does that help the Sender? He will have to anyway retry the message
 to get the response. Infact, getting an Ack may give an illusion that
 he got the response  without actually getting the response. Just getting
 an Ack or Fault independently to the actual response does more
 harm than good. Infact, this model may result in duplicate acks.
 For ex., in the above example if MSFT trading resumes and the
 receiver wants to send the response back. Does it again have to
 send the Ack or Fault.

 Now coming to the use case I gave where different nodes can
 participate in the same group id, trust me, it is far from being
 hypothetical and is very common is business orchestration,
 and collaboration cases.

 Take this example. Two suppliers have to collaborate. Instead
 of Supplier 1 collaborating directly with Supplier 2, it's partners
 such as Inventory1 and CreditCheck1 will talk with Supplier2
 orchestrated by Supplier 1. Supplier1 asks CreditCheck1
 to do a check for PurchaseOrder and request the response to
 be sent to Supplier2 with a given group id and a seq num (0).
 And then Supplier1 will also Inventory1 to do an inventory
 check and send the response to Supplier2 with the same
 groupId and a seq num (1). RM features are used end to
 end.

 So if the Supplier2 to sends an ack (via batching) to CreditCheck1,
 how does it make sense of it.

 This is exactly how collaboration/workflow/orchestration processes
 work and there is where RM will be used mostly. Most enterprise
 applications are not simple peer to peer, rather complex end-to-end
 as illustrated above.

 Another prominent usecase would be the group-unordered case.
 We have mentioned that group-unordered will be used for
 efficient DE when MO is not needed. We also discussed (though
 not mentioned in the spec.), a Sender may send the same groupId
 when processing both related or un-related 'truncations'. An example
 case of the latter would be a middleware processing many concurrent
 client requests. In such case, an ack of request for an un-related
 'transaction' doesn't make sense.

 If still not convinced, I can give more examples.

 Just to some up. RM-Ack for wsdl 1.1 R-R is case is a very insignificant
 requirement. Adding batching capabilities to that is even more
 insignificant.  I don't see enough justifications to compromise on the
 protocol for such insignificant.

 Restrictions in this case will simplify the protocol and implementation.

 For the reasons mentioned above, I'm very strongly opposed to it.
 I really appreciate if we can put to rest this issue as this one is coming
 on and on and I've spent lot of time on this.

 -Sunil

>
>
> Doug Bunting wrote:
>
>> Sunil,
>>
>> I continue to have a great deal of trouble understanding your issue
>> around
>> acknowledging only a single message in the response reply pattern.  If
>> the
>> two systems cannot treat each other as unified entities and if the group
>>
>> identifiers do not scope such consistency, we are lost already.
>>
>> I believe you are arguing for a much less efficient protocol based on an
>>
>> unlikely use case.  Your use case involves two message senders
>> coordinated
>> enough to share a single group identifier without overlapping their
>> message
>> identifiers but not coordinated enough to share acknowledgments.  For
>> every
>> other sender, the simple need to resend every message until it is
>> individually acknowledged will remove any value in using ordered
>> delivery
>> and the response reply pattern together.
>>
>> thanx,
>>         doug
>>
>> On 20-Feb-04 18:13, Sunil Kunisetty wrote:
>> ...
>>
>> >>Another example that makes the protocol itself (not an individual
>> >>implementation per se) less efficient would be disallowing
>> acknowledgment
>> >>of other messages in a sequence previously held for the one just
>> received
>> >>(that is, messages 3 and 4) when using the Response reply pattern.  I
>> >>generally prefer SHOULD to MUST NOT.
>> >
>> >
>> >  It has to be MUST NOT, because
>> >  1) As per our definition of Response Ack. pattern, the Ack/Fault for
>> msg1.
>> >      and msg2 MUST be sent back on the same underlying response as
>> >      that of the request.
>> >  2) The identification of Sender in Response or Poll case is not
>> specified.
>> ...
>