Re: [ws-rx] Usage of Ref parms for WS-Reliable Messaging

[Doug Davis <dug@us.ibm.com>]

Paul,
  RManon vs Anon+ref-p's is the
PR issue - yes I agree.  I, however, don't believe
that defining a new URI is any less
in scope than RM defining an AcksTo EPR and
describing how messages sent to that
EPR are delivered (esp. in the anon case).

thanks,
-Doug

Paul Fremantle <paul@wso2.com>

10/06/2006 08:20 AM

To	Doug Davis/Raleigh/IBM@IBMUS
cc	ws-rx@lists.oasis-open.org
Subject	Re: [ws-rx] Usage of Ref parms for WS-Reliable Messaging

Doug

Since one of the comments of the WSA WG was to question our creation of
a RMAnon URI I'm frankly confused why you don't consider this an issue
at hand.
The use of the WSA anon+refparams is clearly not creating a new 
addressing concept and therefore would not be an issue for this part of
the charter.

Paul

Doug Davis wrote:
>
> I believe the use-cases the "RManon" concept solves, like
CS flowing, 
> are in scope.
> We've been here already and voted - let's focus on the PR issues at
hand.
> thanks,
> -Doug
>
>
>
> *Paul Fremantle <paul@wso2.com>*
>
> 10/06/2006 04:07 AM
>
>                  
> To
>                  Doug
Davis/Raleigh/IBM@IBMUS
> cc
>                  Anish
Karmarkar <Anish.Karmarkar@oracle.com>, Marc Goodner 
> <mgoodner@microsoft.com>, "tom@coastin.com" <tom@coastin.com>,
wsrx 
> <ws-rx@lists.oasis-open.org>
> Subject
>                  Re:
[ws-rx] Usage of Ref parms for WS-Reliable Messaging
>
>
>
>                  
>
>
>
>
>
> Doug
>
> So does the addressing concept "RMAnon" have wider applicability?
>
> "The TC will not attempt to define concepts or renderings for
functions
> that are of wider applicability including but not limited to:
>    ...
>  * Addressing
>    ...
>
> Paul
>
>
> Doug Davis wrote:
> >
> > Not trying to speak for Anish, but from my point of view, the
URI
> > version was designed to
> > solve very specific RM use-cases - like the sending of a
> > CreateSequence.  Any other
> > solution that was proposed was a hack and, IMO, bastardized the
> > protocol.  That fact that
> > the solution we developed for scenarios like CS, /without /any
change,
> > also works for other
> > scenarios is good, not bad.  If we had added a ton of crap
to
> > MakeConnection for the sole
> > purpose of solving those other use-cases then you may have a
point,
> > but that was just not
> > the case.
> >
> > thanks,
> > -Doug
> >
> >
> >
> > *Paul Fremantle <paul@wso2.com>*
> >
> > 10/05/2006 05:55 PM
> >
> >                  
> > To
> >                  Anish
Karmarkar <Anish.Karmarkar@oracle.com>
> > cc
> >                  Marc
Goodner <mgoodner@microsoft.com>, 
> "tom@coastin.com"
> > <tom@coastin.com>, wsrx <ws-rx@lists.oasis-open.org>
> > Subject
> >                  Re:
[ws-rx] Usage of Ref parms for WS-Reliable 
> Messaging
> >
> >
> >
> >                  
> >
> >
> >
> >
> >
> > Anish
> >
> > Firstly there is a general point, which is that good design is
design
> > that meets the design brief and no more. We all know that solutions
that
> > go well beyond the design brief tend to have problems. I would
hazard a
> > guess that at least 50% of security problems come from building
in too
> > much richness. Interoperability is another key issue. If you
look at
> > what WS-I did with WSDL it was specifically addressing the fact
that
> > there was too much richness in the original WSDL specification
which led
> > to massive non-interop.
> >
> > When we came up with the "compromise" proposal I was
of your opinion. I
> > felt that the composability requirement I was pushing was met
by the
> > SeqID model (that we could add reliability to an existing two-way
> > message exchange without interposing at the WSA level and modifying
WSA
> > headers), and that the wider requirements for using anonymous
> > backchannels were met by the URI model.
> >
> > However, with some further time and of course the discussions
from the
> > WSA group, I'm beginning to wonder if I was wrong.
> >
> > I was going to write a note to the TC proposing we redo the URI
model
> > using reference parameters, but I realize my heart is not in
it. I do
> > not believe that option is composable with existing interactions,
and I
> > do not believe it is in the remit of this TC to create new mechanisms
> > that go beyond *adding* reliability to existing SOAP message
flows.
> >
> > Then I re-read the charter.
> >
> > In particular this aspect:
> >
> > "The TC will not attempt to define concepts or renderings
for functions
> > that are of wider applicability including but not limited to:
> >
> >    * Security (Encryption, Integrity and Authentication)
> >    * Addressing
> >    * Policy languages and frameworks"
> >
> > I think that *clearly* rules out what you are saying.
> >
> > Paul
> >
> >
> > Anish Karmarkar wrote:
> > > Marc Goodner wrote:
> > >> This seems to be a discussion of a generic polling model
with no
> > >> connection to RM.
> > >
> > > What is that a bad thing?
> > > Just because RM has this urgent need, does not mean that
the solution
> > > *has* to be RM-specific. It can be, but doesn't have to.
> > >
> > > -Anish
> > > --
> > >
> > >> I think the point on MakeConnection Queue below is important
though.
> > >> The RM anon URI absolutely requires establishing a queue
independent
> > >> of an RM sequence. I'm increasingly troubled by that.
The two
> > >> mechanisms we have for MakeConnection do not seem to
be able to share
> > >> the same queue. At least the SeqID form uses an existing
RM sequence
> > >> and is clearly about solving RM scenarios.
> > >>
> > >> -----Original Message-----
> > >> From: Paul Fremantle [mailto:paul@wso2.com]
> > >> Sent: Friday, September 29, 2006 1:10 AM
> > >> To: tom@coastin.com
> > >> Cc: wsrx
> > >> Subject: Re: [ws-rx] Usage of Ref parms for WS-Reliable
Messaging
> > >>
> > >> Tom
> > >>
> > >> I agree completely.
> > >>
> > >> As an aside, the problem with the concept of a resource
is that it is
> > >> very wide. Looked at with the right mindset, I believe
that any
> > usage of
> > >> reference parameters could be challenged as referring
to a 
> resource. I
> > >> personally don't have such a wide "resource view",
with the 
> result that
> > >> passing a uuid seems a very reasonable usage of a reference
> parameter.
> > >> In fact I think that it makes the whole EPR-based polling
model much
> > >> better. It seemed to me that we decided against this
model because we
> > >> anticipated issues from the WSA WG, and we got that
wrong.
> > >>
> > >> Paul
> > >>
> > >> Tom Rutt wrote:
> > >>> quoted from 9/28 minutes:
> > >>>
> > >>> "
> > >>> Chris: We are not in agreement. I don't want to
use reference params
> > >>> because they violate the Web Architecture. WSA WG
ignored TAGs 
> issues.
> > >>> Paul: I'm not at all in agreement. The reference
parameters are not
> > >>> used to identify a resource, they are used to identify
a particular
> > >>> RMD.
> > >>> "
> > >>>
> > >>> I think that using a ref parm to identify a MakeConnection
Queue 
> could
> > >>> be considered application level information associated
with a
> > >>> particular endpoint address.
> > >>>
> > >>> I really think, if we wanted to, we could work out
a 
> specification of
> > >>> a use of a ref parm, which when added to the generic
> wsa:anonymous URI
> > >>> in the address
> > >>> field of an EPR, identifies the "make connection"
queue which will
> > >>> utiize the back channel only when it is appropriate
(i.e, when a 
> make
> > >>> connection is received with that queue ID).
> > >>>
> > >>> What I am trying to say is that only the address
is needed for
> > >>> dispatching the message to the appropriate location,
and that the a
> > >>> queueID ref parm could indicate when that anonymous
back channel is
> > >>> appropriate for use.
> > >>>
> > >>> Tom Rutt
> > >>>
> > >>
> > >
> >
>