ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ws-rx] Proposal for i021
- From: "Gilbert Pilz" <gpilz@bea.com>
- To: "Doug Davis" <dug@us.ibm.com>, "Patil, Sanjay" <sanjay.patil@sap.com>
- Date: Thu, 14 Dec 2006 15:38:33 -0800
I've been reviewing the message that accompanied this issue
and I'd like to update/revise my position on the points I
made:
1.) Complicates SOAP processing: I think the proposal on
the table for PR018 basically eliminates this concern.
2.) Agreement on use of piggy-backing: I'm still somewhat
concerned about this aspect. I think the spec should make it clear that the
"MAY" in piggy-backing applies to the piggy-backer; it's sender-optional.
RMS and RMD implementations MUST be prepared to handle piggy-backed
SequenceAcknowledgement and AckRequested (respectively)
headers.
3.) EPR comparison: I still think this is a real concern.
We are talking about comparing EPRs, something the WS-Addr group decided was too
hairy to get into. Waving our hands and saying that reference parameters must be
"considered" doesn't cut it. We should profile a small subset of the options for
EPR comparison and say "this is how you compare EPRs for the purposes of
selecting a SOAP message on which to piggy-back". We can afford to be a little
conservative because a false negative comparison (thinking two EPRs are
"different" when they are really "the same") isn't all that
harmful.
- gp
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
smime.p7s
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]