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] Usage of Ref parms for WS-Reliable Messaging



On the 'queuing' issue...  the spec says its an impl detail and out of scope.  While I think some people would assume that some sort of queuing mechanism may be used there actually is no requirement for that.  So, its very possible that upon receipt of the MakeConnection the receiver could ask an application if it had a message for the sender.  Personally, when MakeConnection was first developed I hadn't really thought about this implementation choice, but it is a valid one and kind of an interesting one w.r.t. optimizing things.  wow - keeps getting better all the time  :-)

thanks,
-Doug



Marc Goodner <mgoodner@microsoft.com>

10/05/2006 12:07 PM

To
Christopher B Ferris/Waltham/IBM@IBMUS
cc
Doug Davis/Raleigh/IBM@IBMUS, "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





The RM anon URI is defined in the spec as indicating that a protocol specific back channel will be used.
This URI template in an EPR indicates a protocol-specific back-channel will be established through a mechanism such as…
 
It is also defined explicitly as being used for the unique identification of anonymous Endpoints.
This specification defines a URI template (the WS-RM anonymous URI) which may be used to uniquely identify anonymous Endpoints.
 
I don’t agree that an implementation may choose whether or not to pool up messages waiting for this, that’s pretty much the point isn’t it?
 
Your statement on that the RM anon URI identifies an RMD resource is even more interesting. I don’t see any mention in the spec of that beyond an example.  In fact doesn’t the spec say it identifies an anonymous endpoint? The description of how this is used in relation to an RMD or RMS just isn’t there. It seems there is a lot of room for interpretation on how this would be implemented.
 
From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
Sent:
Thursday, October 05, 2006 8:44 AM
To:
Marc Goodner
Cc:
Doug Davis; tom@coastin.com; wsrx
Subject:
RE: [ws-rx] Usage of Ref parms for WS-Reliable Messaging

 

No, the RM anon URI identifies the RMD resource. The fact that an implementation may choose to establish

a queue of messages targetted at a specific RMD resource does not imply that the URI identifies that queue

of messages.


The RM anon URI does not identify the back-channel either. It identifies the anon RMD resource. The

MakeConnection mechanism uses the protocol-specific back-channel to enable the sending endpoint to

transfer any messages targetted to a particular RMD resource identified in the MakeConnection message.


You are creating issues out of nothing.


Cheers,


Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 377 9295


Marc Goodner <mgoodner@microsoft.com> wrote on 09/29/2006 09:32:26 PM:

> The RM anon URI identifies the client, the
> queue/bucket/store/whatever on the server to hold pending messages
> to the client, and the backchannel. I count three resources there. A
> URI represents a resource.  So the current approach is not without
> its issues either.

>  

> From: Doug Davis [mailto:dug@us.ibm.com]
> Sent: Friday, September 29, 2006 4:04 PM
> To: tom@coastin.com
> Cc: wsrx
> Subject: Re: [ws-rx] Usage of Ref parms for WS-Reliable Messaging

>  

>
> Tom,
>  Where in the RM spec does it talk about queues?  It doesn't, so I think
> you're bringing in an impl choice into the discussion.  The spec says:
>   This specification defines a URI template (the WS-RM anonymous URI)
>   which may be used to uniquely identify anonymous Endpoints.
> Its very consistent in this respect.
> The URI template was not created to specify a queue, it was established
> so that we can uniquely identity one anonymous endpoint from another.
> Clearly a fixed URI (wsa's anon) doesn't allow for this.  Given all
> of the heated discussions around whether ref-p's can or should be used
> to identify an endpoint it would not be wise to reverse decisions that
> have been made that clearly indicate ref-p's are not for this purpose.
> All of that being said, w.r.t. queues...how an implementation chooses
> to manage messages targeted to a particular endpoint is up to it and
> is out of scope for this spec to specify.
>
> thanks,
> -Doug
>
> Tom Rutt <tom@coastin.com> wrote on 09/29/2006 02:32:55 AM:
> > 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]