ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ws-rx] i061 proposal / directions
- From: Christopher B Ferris <chrisfer@us.ibm.com>
- To: ws-rx@lists.oasis-open.org
- Date: Wed, 18 Jan 2006 10:14:02 -0500
Umit,
Please see my comments below.
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
"Yalcinalp, Umit" <umit.yalcinalp@sap.com>
wrote on 01/17/2006 07:36:32 PM:
> Chris,
>
> You think that we should not be constrained by
WS-I BP conformance,
> but WS-A discussion has been just the opposite. I note that there
> has been a lot of discussion not to support the behaviour that has
> been advocated by some of the vendors due to the incompatibility
> introduced with WS-I BP 1.x. Especially in situations with request-
> response with an non-anonymous reply endpoint and an anonymous
> AcksTo, this specific use case is reduced to two one-way SOAP
> exchanges. There has not been yet an agreement whether the HTTP
> response may carry a SOAP Envelope and thus allow the
> acknowledgement to appear. This is due to the fact that this
> specific case ends up being modeled with two one-way "undefined"
> SOAP one-way MEPs and thus depends on the assumptions on how the
> one-way MEP is defined. I am quite sure that you have been following
> the discussion in WS-A ;-)
Nope, I haven't been following the discussions in
WS-A. I have been
following the discussions in XMLP and my point all
along has been that
the whole notion of an explicit or implicit relationship
between
the SOAP MEP and the WSDL (or higher-level) MEP is
something to be
avoided at all costs *especially* when one adds WS-Addressing
into the
mix.
>
> IMO, if the specification assumes behaviour which
contradicts other
> specifications, it is preferable to state it explicitly. Better yet,
> a special markup in the WSDL/Policy that indicates when the
> assumption MAY NOT be supported:
<Rolls eyes/>
>
> My anology for this is the wsaw:UsingAddressing
[1]
> markup/assertion. It indicates that an endpoint engaged in WS-A
> supports both anonymous and non-anonymous URIs as addresses of
> response endpoints. The engagement of WS-RM may also assume a
> similar semantic and use a similar approach.
>
> We currently have wsaw:Anonymous element in WS-Addressing
that
> indicates whether anonymous URI as addresses of response EPRs are
> allowed to fine tune the semantics of wsaw:UsingAddressing marker.
> This element may have three different values,
> "optional"/"required"/"prohibited".
I've seen this much at least in the WS-A discussions
and frankly, I find
it suboptimal from an interoperability standpoint
because it
provides for too much optionality. IMO, stuff should
"just work".
It should not have to be configured differently depending
upon
what the other endpoint has or has not implemented.
It only
adds unnecessary complication.
We are hearing from customers that an *important*
use case for them
is to be able to send a WSDL oneway message and receive
the RM ack
on the HTTP response. They either do not wish to,
or cannot, expose
a separate endpoint for receiving the RM acks.
Providing a WSDL annotation such as you have described
above
might help in terms of informing the sending side
what configurations
are supported, but it doesn't help at all solve the
problem when
the HTTP response flow is the ONLY viable vehicle
for the RM
ack.
>
> One option for us may be to indicate endpoints
which could not
> support anonymous URIs (AcksTo) with a "prohibited" value
in
> conjunction with the WS-RM policy assertion to indicate that
> Anonymous Acks can not be sent on a backchannel. This will allow
See above. Blech. This doesn't help customers to solve
their
problems. It only unnecessarily complicates matters.
> those with WS-I BP semantics not to allow Acks to flow in the
> backchannel as they may not be able to support it. This is a
> possible option. It will also force a non-anonymous AcksTo destination.
See above. Not an option if the purpose is to solve
customer problems.
The WS-I BP is what it is, but that does not make
it right. When
the BPWG was deliberating this matter, I argued fiercely
that it was
a decision that the WG would later regret. Yet again,
I get to say
"I told you so" :-)
If you ask me, all of this discussion of adding some
psuedo-policy
gunk is a cop-out that doesn't benefit the customer,
it only benefits
the vendor by allowing them to do as little as possible
and still
claim support for a standard while at the same time,
diminishing
the value of the standard as regards interoperability.
>
> Note that the burden is on the vendor to make
this additional
> declaration when backflows are not supported, not the other way
> around. This option also serves as "the caveat" as it formally
> provides a definition as to when the backchannel can not be used.
See above. This places no "burden" on the
vendor. It's a cop-out. It places the
"burden" on the *customer* who has to deal
with unnecessary complication
and who has to kludge up a sub-optimal work-around
configuration when
dealing with an endpoint that doesn't support sending
a SOAP message
on an available channel (the HTTP response flow) just
because the WS-I
BPWG made a foolish decision.
I added the quote from The Matrix for a reason. We
should make our own
reality. We have a valid, and IMO compelling, use
case that we seem
to be throwing out with the WS-I BP bath-water.
WS-I BP is what it is because its primary purpose
was to facilitate
interoperability of BASIC Web services that lacked
an addressing
component such as WS-Addressing. It has served its
purpose well in
that regard. However, as we seek to move beyond "Basic"
Web services,
I do not believe for a moment that we should be constrained
to abide
by the guidance of the WS-I BP.
>
> I am not sure whether Gil was also going to suggest
this possibility
> for (1) in his proposal as we discussed the uses of this markup
> during one of the WS-A concalls.
>
> Since we are discussing options, I thought this
should be put onto the table.
>
> --umit
>
> [1] http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-
> wsdl.html?content-type=text/html;%20charset=utf-8
>
> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
> Sent: Tuesday, Jan 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>
> > > > >
> > > > >
> > > >
> > >
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]