ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ws-rx] PR issue 1 - WS-Addressing comment on ws-rm related to use ofextended anonymous uri
- From: Doug Davis <dug@us.ibm.com>
- To: Paul Fremantle <paul@wso2.com>
- Date: Wed, 27 Sep 2006 05:38:29 -0400
Paul Fremantle <paul@wso2.com> wrote on 09/27/2006
05:14:17 AM:
> Doug Davis wrote:
> > IIRC there were some other reasons as well. One of the
ones that kept
> > nagging at me
> > is the notion of a soap processor examining the ref-p's of an
outgoing
> > message. While
> > they must look at things like the wsa:To URI, a requirement to
now
> > check for some
> > soap header (even if its well defined) on an outgoing message
can be
> > quite a change
> > for some processors.
> Can you explain which bit of the processing chain you are thinking
of?
In my head the transport layer is separate from the
rest of the processing.
So, the app generates part (most) of the message and
then soap engine
does what it needs to do to generate the rest of the
envelope - like
serialize the app's data, add soap headers (including
wsa's). But
at some point the soap stack will hand it off to a
transport layer who's
job it is to 'get it to the other side'. And
its this layer that
would look at the wsa:To to figure out how to make
that happen. And its
this code that would check for anon/none/other. This
allows for the
construction of the message to be totally independent
from the transport
mechanism or even what URI the message was being sent
to. So while the
detection of anon/none/other-special-uri can be
done in other places for optimization reasons, its
this conceptual model
that I'm following. I think its the most extreme
view of separation of
concerns and provides the most flexibility in term
of impl choices.
I imagine that all soap engines have some if-statement,
someplace, that
checks for anon/none - what I like about our current
solution is that we
are asking them to simply add more if's (or else's)
to that existing
logic - no matter where it may be. Checking
for certain ref-p's on an
outgoing message is not something I feel comfortable
with assuming everyone
does today, therefore I viewed this as a pretty radical
change.
> > I'm really disappointed with the WSA WG because while we (rx)
may or
> > may not have
> > made the right choice by defining a new URI, that really isn't
the
> > issue. Other specs
> > _can_ define their own special (non-addressable) URI and, IMO,
WSA
> > should be
> > extensible/composable enough to allow for them. And as
such, they
> > (wsa) should
> > address this issue in the general sense and not try to deflect
it onto
> > RM. We can
> > obviously revisit our decision, but even if we do decide on a
> > different answer (like
> > ref-p's) the WSA issue would still exist.
> As chair of this TC I'm afraid I don't think that is our (RX's) concern.
> I'm happy for you to lobby the WSA WG as you wish, but the primary
issue
> we have to deal with is that they have publicly commented on our spec
> and we have to take that into account. If the WSA issue gets
punted
> into a later revision of WSA then that's their problem :-)
Their issue is not our concern, I agree, which is
why I posted the
solution I did.
-Doug
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]