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] Rel 33: some thoughts and proposal...


 
 Peter,

 We are indeed referring to  RM Ack and not Application/Business App. We discussed this
 in the Oracle F2F and we definitely said the latter is outside our realm.  The current proposal
 for REL 33 is more like a transport Ack and Jacques and I are suggesting to make it more like
 a RM Ack. So seems like you are in agreement with us and your only concern is the usage
of words.

 Before I list the choices, I just want to re-emphasize that this (correct usage of words)  issue is
 sort of orthogonal as we use the same phrase in defining the Ordering semantics also.
 
 So let me list the choice of words:
   1) "make it available to the application/user".
   2) "make it available to the next layer".
   3) "RMP passing responsibility for the message to the user"
      [I copied this from the Tom's meeting minutes as Pete W. saying so]
   4) "Transferring the responsibility to the next layer".
      [i vaguely recollect someone saying it in the call.]

 Does any one have any other suggestions? In the above list, I prefer option 2 with a comment
 that the next layer could be the application user itself.

 Thoughts?

 -Sunil

"Furniss, Peter" wrote:

 I'll try and state what was worrying me about this on the call last night:Although the concept "make available to the application/user" can usefully be used to specify the meaning of a sequence, that doesn't imply that it will necessarily happen synchronously to the communication. Perhaps best explained by scenario:an RM receiver receives incoming work overnight and delivers items when they are asked for by the human-driven application during the day. If messages arrive as part of a sequence, the software will only offer them to the user in the right order. It therefore fulfils the sequence requirement of making them available in order, but the time of making available is invariably while the RMP is out of communication with the sender.Now you can try and get round that by claiming that the storage of the message in the queue in circumstances that would permit its later delivery (i.e. all prior msgs received) is the point of "making it available to the user", but that is distinctly artificial and confusing. If you don't bend the rules like that, then the proposed change would mean that *none* of the messages received during any connection session (even if they weren't part of sequences) could be ack'ed until the next night.But the phrase used often last night was that the ack should be sent when the receiver can assure the sender that the receiver now has responsibility for the message, and the sender is absolved of its responsibility. But that can occur on a message-by-message basis and has nothing to do with whether the message is yet delivered or deliverable to the user. Actually, I think the fix to the original problem here is to understand Ack correctly at the sender side - it's just a RM ack, and means the responsibility has been transferred. There is the possibility of another acknowlegement - the message has been delivered, but that's at a higher level - and may itself be sent back queued.

Peter

------------------------------------------
Peter Furniss
Chief Scientist, Choreology Ltd

   Cohesions 1.0 (TM)
   Business transaction management software for application coordination

web: http://www.choreology.com
email:  peter.furniss@choreology.com
phone:  +44 870 739 0066  <-- new, from 4 August 2003
mobile: +44 7951 536168

-----Original Message-----
From: Jacques Durand [mailto:JDurand@fsw.fujitsu.com]
Sent: 18 November 2003 22:10
To: 'wsrm@lists.oasis-open.org'
Subject: [wsrm] Rel 33: some thoughts and proposal...
 
All:
Sorry for a late notification, but here is a proposal for Rel 33 where a change in
the current semantics for Acknowledgements is proposed.
This is in the light of other issues that we are currently  trying to solve these days.

We would appreciate having at least the opportunity to present it to the TC at this meeting, if enough time...
Again, apologies for late notice but that is  a very recent conclusion of ours,
and we'd like at least to get early feedback if possible.

Jacques
-----------------------------------------------------------------
We'd like to propose a change in the semantics of sending an Acknowledgment.
Instead of sending the Ack when the message is received, the Ack. would be sent
when the message is made available to the server-side application/user.
After some discussion related to faults/notifications, we believe this would help
significantly to get both Sender/Receiver aligned,
and also reduce the need for additional faults and notifications, always problematic
(e.g. if polling needed).
The advantages we see with the new proposal are:
- More consistent semantically because the message is made available to
the user once acked, no more when buffered.
- Solves the async. failure notification problems.
- Makes Rel 50, Rel 52, and Rel 57 simpler.
- the main difference is for ordered groups, for pending out-of-order sequence.
- all semantics of RM features (guaranteed delivery, dup elim, ordering) would now be
about conditions of delivery to application.
We have considered cases where Acks of received messages would be delayed
due to out-of-order sequences (not made available to app yet).
To jot some memories back, this was decision we made at the first F2F
at Redwood Shores and was reverted back later as it may have payload
affect during retries. We believe this is a performance issue and
a trade-off on a functional behavior for a performance one.
Performance can be handled without problem (see below)
-------- detail:
For implementations that are concerned about performance hit, an optimization
they could use is to only retry the lowest un-acked message in a grouped
ordered case, i.e., if msgs. 1,2,3 are sent and Sender hasn't received
acks. for 2 and 3, the Sender should not retry 3 until they get an ack. for 2.
For RMP impl. that doesn't worry about retries throttling the Receiver,
they might still send parallel retries. Either approach won't have any effect
on the end user behavior.



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