[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 > > >>> > > >> > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]