RE: [ws-rx] Proposal for i021

[Doug Davis <dug@us.ibm.com>]

s/should be/should not be/  
obviously  :-)

thanks
-Doug
__________________________________________________
STSM | Web Services Architect | IBM Software Group
(919) 254-6905 | IBM T/L 444-6906 | dug@us.ibm.com

Doug Davis/Raleigh/IBM@IBMUS

12/14/2006 04:05 PM

To	"Patil, Sanjay" <sanjay.patil@sap.com>
cc	"Paul Fremantle" <paul@wso2.com>, ws-rx@lists.oasis-open.org
Subject	RE: [ws-rx] Proposal for i021

Been a while but I think I'm saying we should close w/no action.  AcksTo
EPR MUST have an RM agent or it should be tagged as the AcksTo EPR.
As for the piggy-backing issue - I can agree that perhaps the text around
piggy-backing should be tigher but in general I think we should keep the
idea of piggy-backing.

thanks
-Doug
__________________________________________________
STSM | Web Services Architect | IBM Software Group
(919) 254-6905 | IBM T/L 444-6906 | dug@us.ibm.com

"Patil, Sanjay" <sanjay.patil@sap.com>

12/14/2006 02:11 PM

To	Doug Davis/Raleigh/IBM@IBMUS, "Paul Fremantle" <paul@wso2.com>
cc	<ws-rx@lists.oasis-open.org>
Subject	RE: [ws-rx] Proposal for i021

Doug, 
  
Are you proposing that we do not need to add any restrictions since AcksTo
EPR is expected to point to an RM agent? 
  
Also, how would you propose to deal with the problems related to piggybacking
(cited by Gil in raising the issue 21) in the context of AckRequested header
block? 
  
-- Sanjay

---

From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Thursday, Nov 30, 2006 12:40 PM
To: Paul Fremantle
Cc: ws-rx@lists.oasis-open.org
Subject: Re: [ws-rx] Proposal for i021


Still thinking about this one but my initial thought is that the AcksTo
EPR is specifically called the "AcksTo" EPR for a reason - there
must be an RM processor there to handle Acks.  So, I'm not really
sure any restrictions are needed - this goes to your first paragraph.

To your specific text - your first bullet would prevent us from optimizing
things and putting Acks for lots of sequences onto the same message.
You're 2nd bullet (I think) is related to this in that it seems to acknowledge
that we may want to put multiple acks for multiple sequences into the message
and we're just concerned with knowing that some RM processor is at the
EPR - well, then we're back to my first point - if there wasn't an RM processor
there then the AcksTo EPR is bad.

thanks
-Doug
__________________________________________________
STSM | Web Services Architect | IBM Software Group
(919) 254-6905 | IBM T/L 444-6906 | dug@us.ibm.com

Paul Fremantle <paul@wso2.com>

11/30/2006 02:34 PM

To	"ws-rx@lists.oasis-open.org" <ws-rx@lists.oasis-open.org>
cc
Subject	[ws-rx] Proposal for i021

The high-level view is that it would be nice to restrict the 
piggybacking of acks to situations where we are sure that there is an RM
agent at the other end.

Replace the beginning of section 3.9 with the following:

The RM Destination informs the RM Source of successful message receipt
using a
SequenceAcknowledgement header block. The RM Destination MAY Transmit the
SequenceAcknowledgement header block independently or it MAY include the
SequenceAcknowledgement header block on existing messages targeted to 
the AcksTo EPR.

When the SequenceAcknowledgement header block is included on existing 
messages, this is known as piggybacking. Piggybacking MAY occur in two
cases:

 * The first case is where the SequenceAcknowledgement header block
   is piggybacked onto a reply to a Sequence Traffic Message. In this
   case the SequenceAcknowledgement must apply to the same Sequence
   as the SequenceTrafficMessage. The definition of reply used is
   that defined by the WS-Addressing relationship URI
   "http://www.w3.org/2005/08/addressing/reply".
 * The second case is where the existing message is a Sequence
   Traffic Message. In this case the Sequence of the Sequence Traffic
   Message does not need to be the same as the Sequence of the
   SequenceAcknowledgement header block.

Piggybacking MUST not occur unless one or both of these cases apply.

Paul

-- 
Paul Fremantle
VP/Technology and Partnerships, WSO2 
OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
paul@wso2.com
(646) 290 8050

"Oxygenating the Web Service Platform", www.wso2.com





-- 
Paul Fremantle
VP/Technology and Partnerships, WSO2 
OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
paul@wso2.com
(646) 290 8050

"Oxygenating the Web Service Platform", www.wso2.com