ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: [NEW ISSUE] Anonymous AcksTo and my AI
- From: Doug Davis <dug@us.ibm.com>
- To: ws-rx@lists.oasis-open.org
- Date: Thu, 27 Oct 2005 12:43:32 -0400
Per my AI[1] and after reading the changes
to WS-Addressing w.r.t. the anonymous URI[2] I think it might be good for
the RM spec to add some additional text to help readers understand exactly
how the sending of Acks can greatly impact their soap stack implementations.
In particular I think the text needs to make it clear that:
- An anonymous AcksTo means SeqAcks need
to flow back on the appropriate protocol binding-specific channel - e.g.
on HTTP its the HTTP response
- However, this doesn't mean any
HTTP response flow, rather just ones that are in some way related to the
sequence. For example, the HTTP request included an AckRequested
or a Sequence header referring to the sequence in question.
- In cases when there is no message flowing
on the HTTP response then using an anonymous AcksTo could change current
transport processing logic. In particular, a single HTTP request
message with a non-anonymous wsa:ReplyTo could still cause a message (an
Ack) to flow back on the HTTP response flow.
to that end....a new issue:
Title: Anonymous AcksTo
Descripton: Add text, similar to above,
to the spec. It should be placed in the Sequence Ack section.
Justification: see above
Target: core
Proposal:
After the first paragraph in the SeqAck
section (currently section 3.2) add something like:
----
Sending Sequence Acknowledgement Header
blocks back to the AcksTo EPR could have an impact on current SOAP implementations.
While this specification discusses the ability to add, or piggy-back,
a Sequence Acknowledgement Header block to a message that is targetted
to the AcksTo EPR, the precise mechanism for determining when any particular
message is targetted, or not, to the AcksTo EPR is out of scope for this
specification. However, WS-Addressing does give some guidance on
EPR comparision.
Using the WS-Addressing's anonymous
IRI in the AcksTo EPR may further impact implementations. When the AcksTo
EPR uses the anonymous IRI, Sequence Acknowledgements MUST be sent on the
appropriate protocol binding-specific channel. For example, in the
HTTP case, Sequence Acknowledgements would be expected to flow on the HTTP
response flow. It is worth noting that this may result in new SOAP
messages being generated and sent in certain situations. For example,
if on an HTTP request flow the SOAP message contained a wsa:ReplyTo that
didn't use the anonymous IRI, then it is possible to a new SOAP message
may need to flow back on the HTTP response flow for the sole purpose of
carrying a Sequence Acknowledgement. Because the anonymous IRI is
a general purpose IRI that can be used by many concurrent RM Sequences,
Sequence Acknowledgements that are sent to the AcksTo EPR using these protocol
binding-specific channels SHOULD only be sent when it can be determined
that the channel is related to the RM Sequence. For example, Sequence
Acknowledgements should only be piggy-backed on HTTP response flows where
the message that was sent on the HTTP request flow referenced the Sequence
in question through the use of a Sequence or AckRequested Header block.
-----
Maybe we should say that they should
compare EPRs per WSA's rules? thoughts?
Another option for the anon AcksTo is
to encourage people to use ref-p's to disamiguate anonymous EPRs - but
I still like the idea of restricting back-channel flows.
thanks
-Doug
[1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_item.php?action_item_id=1049
[2] http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200510/msg00169.html
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]