OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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



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]