Shirley you can't be serious by stating
"all cases of interop of WS-ReliableMessaging spec were interoperably
exchanging oneway messages" proves interop in anything other than trivial
scenarios. Those were not interop scenarios, they were bare bones proof
of concepts. They certainly weren't testing SOAP intermediary behaviour,
as SOAP intermediaries have been ruled out of scope by the powers that be for
every specification and every interop event. And I bet if we tried to
introduce a SOAP intermediary in this group to test the anon acksTo behaviour,
somebody would jump up and down and say "we're testing WS-RX, not testing
SOAP intermediaries".
Secondly, XMLP WG has not decided formally
whether it will amed Req Response rather than introduce one-way mep. It
is very possible that that WG may not be able to do that change to the existing
MEP. But so what? If people are doing one-way messages all over the
place, then it shouldn't be that hard to write it down in a spec.
This really gets down to a very simple question of specifying behaviour
in the face of intermediaries. That is, assuming you want to write things
down in specs rather than "just have them work" with magic pixie
dust.
Riddle me this: MUST a SOAP intermediary
wait for the status code and HTTP response body from the next node before it
can respond to the first? Does the answer depend upon whether a
WSDL one-way or req-resp is specified for the SOAP request? In other
words, is it ever legal for a SOAP intermediary to respond with 202 and an
empty response body for a WSDL one-way without waiting for the next node?
If you say it may be legal to respond with 202 and empty response (and
that MUST should be a SHOULD or MAY), then anon acksTo is problematic. If
you say it is never legal for intermediary to respond without waiting for next
node, then anon acksTo is not a problem. But I seriously wonder about real
world implementation conformance to that MUST.
Cheers,
Dave
From: Christopher B
Ferris [mailto:chrisfer@us.ibm.com]
Sent: Tuesday, January 17, 2006
3:43 PM
To: Gilbert Pilz
Cc: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] i061 proposal
/ directions
I would point out that the SOAP1.2 specification
actually REQUIRES that there be a SOAP
envelope
in both the request AND response flows of the SOAP/HTTP binding for the
Request
Response MEP. There is no formally defined oneway MEP defined for SOAP1.2
and
the XMLP WG is actually pursuing a strategy of amending the Request Response
MEP
such that the response SOAP envelope is optional, rather than define a new MEP
for
oneway.
I
would also point out that in all cases of interop of the WS-Reliable Messaging
spec, prior to
submission
to this TC, implementations were interoperably exchanging oneway messages
with
acks on the HTTP response flow. I am unaware of any implementations that were
unable
to
do this.
I
understand that many current SOAP stacks that offer WS-I BP conformance do not
send
a SOAP envelope in the response to a WSDL input only operation, however, I
don't think
that
we should necessarily be constrained by that.
Additionally,
regardless of whether the RM spec says that an AcksTo that carries the anon
URI
means that SeqAcks flow on the HTTP response flow does not require that an
implementation
actually
support that mode of operation. An RMD should be free (IMO) to decline a
CS
with an AcksTo of the anonymous URI if in fact it cannot support sending
SeqAcks on the
response
to a oneway WSDL operation. As for the RMS, it would not send a CS with an
AcksTo
specifying
the anonymous URI if it was unprepared to handle SOAP envelopes sent in the
HTTP
response to a WSDL oneway (unless it was a very confused implementation:-)
I
think it is fine if the spec might include a caveat that indicated that use of
the anonymous URI
in
AcksTo might not be supported in all implementations, but personally, I would
think that
the
spec is fine as it stands.
There
is no spoon, Neo.
Finally,
it is not in the scope of the TC to specify a polling mechanism. If someone is
in need
of
one of these, Doug has published one here:
http://www.w3.org/Submission/ws-polling/
Cheers,
Christopher
Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295
"Gilbert
Pilz" <Gilbert.Pilz@bea.com> wrote on 01/17/2006 06:15:56 PM:
> My main objection to the current proposal is
that it requires the
> existence of a back-channel along the entire
message path between the
> RMS and the RMD. I think most of us are aware
of the sturm und drang
> around this issue (BP 1.1 says you don't have
a back-channel [1], WS-A
> is currently entertaining a definition of
"one way over SOAP 1.1" that
> precludes a back-channel [2], the
WS-Addressing [3] and WS-Description
> [4] WG's have each asked the XMLP WG to
define a one-way SOAP MEP and
> corresponding HTTP binding that may include a
back-channel, etc.)
>
> Considering that the various specifications
in this area are still in
> flux, I don't think we can presume any
uniformity of implementations (in
> regards to one-way messages using SOAP 1.1)
any time soon. That being
> the case I think it's a very bad idea for
WS-RM to specify behavior that
> presupposes the existence of a back-channel
in the case of one-way SOAP
> 1.1/HTTP.
>
> Its important to stress that I'm raising this
argument as a *practical*
> matter. I'm not making any arguments about
how one-way SOAP 1.1/HTTP
> *should* behave (nor do I think it is the
function of the WS-RM TC to
> consider such arguments). I'm simply noting
that, as of today, you can't
> make assumptions about how the underlying
SOAP/HTTP stack will behave
> with regards to one-way messages and
back-channels.
>
> I think that we should do the following
instead:
>
> 1.) Note the circumstances under which the
use of the anonymous URI for
> AcksTo may result in the inability of the RMS
to receive
> acknowledgments.
>
> 2.) Specify a mechanism (synchronous polling
via an empty SOAP body and
> an AckRequested header?) that allows the RMS
to get the acknowledgements
> in cases where (1) pertains.
>
> I'll be sending out a more formal proposal
for this tomorrow.
>
> - g
>
> [1]
>
http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#One-Way_Op
> erations
>
> [2]
>
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Dec/att-008
> 0/ws-addr-wsdlProposedRevision1.62.html#wsdl11oneway
>
> [3]
>
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Oct/0003.ht
> ml
>
> [4]
http://lists.w3.org/Archives/Public/www-ws-desc/2005Jun/0060.html
>
> > -----Original Message-----
> > From: Marc Goodner [mailto:mgoodner@microsoft.com]
> > Sent: Monday, January 16, 2006 9:47 PM
> > To: Yalcinalp, Umit; Patil, Sanjay; Doug
Davis
> > Cc: ws-rx@lists.oasis-open.org
> > Subject: [ws-rx] i061 proposal /
directions
> >
> > Retitled to indicate topic better.
> >
> > The proposal is in the issue list
already. Not sure if there
> > has been any updates to this one or not,
I don't recall any.
> >
> >
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssue
> > s.xml#i061
> >
> >
> > Marc Goodner
> > Technical Diplomat
> > Microsoft Corporation
> > Tel: (425) 703-1903
> > Blog:
http://spaces.msn.com/members/mrgoodner/
> >
> > -----Original Message-----
> > From: Yalcinalp, Umit
[mailto:umit.yalcinalp@sap.com]
> > Sent: Monday, January 16, 2006 5:24 PM
> > To: Patil, Sanjay; Marc Goodner; Doug
Davis
> > Cc: ws-rx@lists.oasis-open.org
> > Subject: RE: [ws-rx] Proposed list of
issues for discussion
> > on the 1/19 conf-call
> >
> >
> >
> > > -----Original Message-----
> > > From: Patil, Sanjay
[mailto:sanjay.patil@sap.com]
> > > Sent: Monday, Jan 16, 2006 4:58 PM
> > > To: Marc Goodner; Doug Davis;
ws-rx@lists.oasis-open.org
> > > Subject: RE: [ws-rx] Proposed list
of issues for discussion on the
> > > 1/19 conf-call
> > >
> > >
> > > Hi Marc,
> > >
> > > I don't remember having seen a
clear and specific proposal on this
> > > issue yet. If I may have missed it,
could you please point
> > me to the
> > > same.
> > >
> > > The current proposal in the issue
text is more of a
> > discussion of the
> > > matter and alludes to different
alternatives. For example, the
> > > proposal as it stands suggests two
ways of deciding when to use a
> > > backchannel (in the case where the
AcksTo EPR has anon
> > value) - a> EPR
> > > comparison, and
> > > b> correlation with sequence
identifier.
> > >
> > > The proposal also assumes a
particular disposition of the WS-I BP
> > > compliance issue about using a SOAP
response on the backchannel for
> > > one-way messages. I am not sure if
the entire TC has agreed to this.
> >
> > +1.
> >
> > Based on my experience/discussions in
WS-A, it is not clear
> > to me whether there is yet a universal
agreement to allowing
> > anonymous Acks on the backchannel since
it will require a
> > SOAP envelope on the HTTP response just
to be able to include
> > protocol headers.
> >
> > If the idea is to agree on this
behaviour in this tc and push
> > the requirement elsewhere, that is an
approach. Whatever we
> > do, however, we need to make sure that
the protocol
> > requirements are "allowed" to
be expressed since the stack
> > /the specs need to compose together.
Even if we may decide to
> > break/extend the rules here, if it is
prevented by the
> > baseline specs it will not be desirable.
Hence, we can not
> > avoid taking WS-A/XMLP into account
eventually.
> >
> > >
> > > I feel that the group needs to
further discuss this issue on the
> > > mailing list first.
> >
> > >I am quite willing to approach the
WS-A WG chair with a formal
> > >requirement coming from the WS-RX TC
once we discuss and formulate
> > >succinctly our needs.
> > >
> > > Thanks,
> > > Sanjay
> >
> > --umit
> >
> > >
> > > > -----Original Message-----
> > > > From: Marc Goodner
[mailto:mgoodner@microsoft.com]
> > > > Sent: Monday, Jan 16, 2006
16:18 PM
> > > > To: Patil, Sanjay; Doug Davis;
ws-rx@lists.oasis-open.org
> > > > Subject: RE: [ws-rx] Proposed
list of issues for
> > discussion on the
> > > > 1/19 conf-call
> > > >
> > > > When are we going to take on
i061? Doug had a specific
> > proposal for
> > > > that one some time ago that
did not depend on waiting on
> > another TC
> > > > or WG. My understanding is
that Addressing was waiting on
> > XP. That
> > > > seems indirect enough that we shouldn't
hold our breath,
> > should we
> > > > move on?
> > > >
> > > > Marc Goodner
> > > > Technical Diplomat
> > > > Microsoft Corporation
> > > > Tel: (425) 703-1903
> > > > Blog:
http://spaces.msn.com/members/mrgoodner/
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Patil, Sanjay
[mailto:sanjay.patil@sap.com]
> > > > Sent: Monday, January 16, 2006
3:19 PM
> > > > To: Doug Davis;
ws-rx@lists.oasis-open.org
> > > > Subject: RE: [ws-rx] Proposed
list of issues for
> > discussion on the
> > > > 1/19 conf-call
> > > >
> > > >
> > > > You are right. i085
(proposed-01 on 1/12 conf-call) was
> > resolved on
> > > > the last call itself.
> > > >
> > > > Here is the updated proposed
list of issues (i085
> > replaced by i082):
> > > >
> > > > a> i082 Level of
"response message" unclear, for SequenceResponse
> > > >
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssue
> > > s.xml#i082
> > > >
> > > > b> i086 Alternative
approach for MaxMessage
> > > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssue
> > > s.xml#i086
> > > >
> > > > c> i087 Acknowledgement
Interval in CreateSequenceResponse
> > > >
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssue
> > > s.xml#i087
> > > >
> > > > d> i075 Case of multiple RM
Policies and DAs within an RMD scope
> > > >
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssue
> > > s.xml#i075
> > > >
> > > > e> i083 Tom Rutt Fault
Messages for Terminated Sequence
> > > >
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssue
> > > s.xml#i083
> > > >
> > > >
> > > >
> > > >
________________________________
> > > >
> > > > From: Doug Davis
[mailto:dug@us.ibm.com]
> > > > Sent: Monday, Jan
16, 2006 12:39 PM
> > > > To:
ws-rx@lists.oasis-open.org
> > > > Subject: Re:
[ws-rx] Proposed list of issues for
> > discussion on the
> > > > 1/19 conf-call
> > > >
> > > >
> > > >
> > > > I might be
remembering incorrectly but I thought we adopted the
> > > > proposal for i085 already (and
I think the notes refelect that as
> > > > well).
> > > >
> > > > -Doug
> > > >
> > > >
> > > >
> > > >
> > > > "Patil,
Sanjay" <sanjay.patil@sap.com>
> > > >
> > > > 01/16/2006 03:32
PM
> > > >
> > > >
> > > > To
> > > >
<ws-rx@lists.oasis-open.org>
> > > > cc
> > > >
> > > > Subject
> > > > [ws-rx]
Proposed list of issues for discussion on the
> > > > 1/19 conf-call
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > The first three
issues below are essentially the ones that we
> > > > accepted on the last call
(1/12). The issues list is
> > currently being
> > > > updated and therefore the URLs
for these three issues may become
> > > > active some time later today!
> > > >
> > > > Thanks,
> > > > Sanjay
> > > >
> > > > A> i085
CloseSequence element is inconsistent
> > > >
> > > >
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssue
> > > s.xml#i085
> > > >
<http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssu
> > > es.xml#i08
> > > > 5>
> > > >
> > > > B> i086
Alternative approach for MaxMessage
> > > >
> > > >
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssue
> > > s.xml#i086
> > > >
<http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssu
> > > es.xml#i08
> > > > 6>
> > > >
> > > > C> i087
Acknowledgement Interval in CreateSequenceResponse
> > > >
> > > >
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssue
> > > s.xml#i087
> > > >
<http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssu
> > > es.xml#i08
> > > > 7>
> > > >
> > > > D> i075 Case
of multiple RM Policies and DAs within an RMD scope
> > > >
> > > >
> > > >
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssue
> > > s.xml#i075
> > > >
<http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssu
> > > es.xml#i07
> > > > 5>
> > > >
> > > > E> i083 Tom
Rutt Fault Messages for Terminated Sequence
> > > >
> > > >
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssue
> > > s.xml#i083
> > > >
<http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssu
> > > es.xml#i08
> > > > 3>
> > > >
> > > >
> > >
> >
|