Re: [ws-rx] i089 proposal

[Paul Fremantle <paul@wso2.com>]

Chris
> But, your proposal does not support "out-only" RM. 
You state my proposal does not support "out-only" RM. Firstly, I'd like 
to understand that more fully. It's not clear exactly what out-only RM 
is with an anonymous client. The server must presumable have some kind 
of knowledge or context under which to send messages to the client. If 
that is an EPRId that the server has generated, then how does it 
validate that the client getting messages for this EPRId is the right 
one. If the client has previously passed the EPRId to the server, then 
it makes sense. However, my proposal could also support that model. The 
client could offer a sequence to the server, and pass the offered 
sequence identifier to whatever is generating the out-only messages. 
Then these would be reliably delivered under the offered sequence. So I 
believe my proposal can support out-only. If this is a serious use case 
then perhaps we could add section 4.2 back in to optimise it.
> What makes you think that the server must "keep track" of this? The 
> server
> has to "keep track" of nothing, IMO.
> What state? 
In order for Doug's proposal to work, the "server" needs to buffer 
messages associated with an EPRId until those messages are picked up. 
That is state. However, unlike a sequence, there is no well-defined 
model for this. How long does the server hold onto messages for? What 
happens if it doesn't want to buffer messages for this client - how does 
it indicate that? [Of course we could add it.... maybe a 
CreateEPRId/CEIResponse pair. How about a 
TerminateEPRId/TerminateEPRIdResponse to clean up when I'm done.]

Paul


Christopher B Ferris wrote:
>
> Paul,
>
> Please see my comments inlined below.
>
> Cheers,
>
> Christopher Ferris
> STSM, Software Group Standards Strategy
> email: chrisfer@us.ibm.com
> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> phone: +1 508 377 9295
>
> Paul Fremantle <paul@wso2.com> wrote on 05/04/2006 02:55:55 AM:
>
> > Doug
> >
> > Some comments:
> > > I'm not promoting a general solution - not exactly :-). What I'm
> > > promoting is a solution that
> > > solves all of the various use-cases that I believe the RM spec should
> > > address. In developing
> > > the solution however, many people have noticed that it can work even
> > > when RM (the resend
> > > until acked part of RM) is not turned on - and that is true but
> > > nothing was added to the solution to
> > > make that happen.
> > However, you have defined (elsewhere) reliability very widely, 
> including
> > getting messages to endpoints that aren't reachable. So this 
> argument is
> > really circular. Effectively what is says is that because I've included
> > all the use cases for any polling situation in my requirements, I've
> > ended up designing a system that supports them, even without any
> > relation to the reliability mechanisms the WSRM spec has focussed 
> on. So
> > effectively your proposal is completely orthogonal to the existing RM
> > spec. If we took your proposal, changed the namespace, and published it
> > separately, it would be a valid standalone spec that could be composed
> > with RM or not.
> > > In fact, it would take a lot of effort (and IMO hurt the proposal) if
> > > it was modified
> > > to only work like Paul's proposal - he tried very hard to tie his
> > > proposal to RM sequences, and
> > > as a result he limited the RM scenarios he can support
> > I actually believe that my proposal can support almost any scenario.
> > However it focuses on the core scenario and requirement that we see in
> > the marketplace - which is supporting anonymous clients doing in,
> > in-out, and in-multi-out MEPs against a server with a well-known 
> endpoint.
>
> But, your proposal does not support "out-only" RM.
>
> > > - and he will end up changing the core RM processing model too.
> > The phrase "core RM processing model" is very dangerous if not
> > disingenuous. The specification does not define the RM processing 
> model.
> > It is up to each implementor to build a processing model for RM that
> > supports the protocol. And so what you consider important about your RM
> > processing model may not be what I consider important. The use of this
> > term, as if it were something sacrosanct and untouchable, is 
> misleading.
> > If we focus on the actual use cases, scenarios and implementation
> > details then the discussion will be much more open.
>
> If we analyze the proposals in terms of the RM use cases, then I think 
> that
> Doug's proposal is a more complete solution. The fact that it also 
> satisfies
> non-RM uses cases is besides the point. It could, and maybe should, be 
> scoped
> to RM use cases only.
>
> >
> > For example, I think what you mean in this case is that either side can
> > create a sequence with the other side whenever it wants, and that in my
> > proposal this isn't true as the Client must Offer a sequence to the 
> Server.
> >
> > Of course in real life this is completely untrue. In the current spec
> > the server cannot actually create a sequence with an unreachable
> > endpoint. Simply because it can't reach it. My proposal doesn't change
>
> Actually, that isn't quite true unless you consider the transport binding
> as one with the RM processing. The act of transfering a message is 
> orthogonal
> to its purpose/intent. Clearly, when RM is engaged, the application can
> "send" a message at a time when the destination endpoint is unreachable
> because of a network partition. How is that different?
>
> > this. It is up to the TC to decide whether they want to support this
> > aspect or not. However, it has very little to do with "changing the 
> core
> > RM processing model".
> >
> > I deliberately didn't try to solve this because as you have shown the
> > only way to do this is to create a complete alternative polling model
> > under which the server can communicate with the client. In order to
> > connect to an anonymous client, you need a context under which to
> > communicate. You simply have a choice - use the existing context (the
> > sequence) that the RM spec defines, or create a new one. The EPRId 
> model
> > that you have proposed effectively adds a new context that the server
>
> What makes you think that the server must "keep track" of this? The 
> server
> has to "keep track" of nothing, IMO.
>
> > must keep track of. Not only is this adding a new set of state to be
> > managed, but nowhere in your spec does it define the lifecycle of this
>
> What state?
>
> > state. So it is undefined how long the server must keep track of this
> > state. The server must buffer messages under this EPRId context and has
> > no defined mechanism for cleaning this state up. There is no fault 
> model
> > around this. There is no way for the client to signal a clean up of 
> this
>
> That is because that is an implementation detail. This spec covers
> the protocol aspects exclusively, not the implementation details.
>
> > state. So your proposal adds significantly to the implementation of an
> > RM agent, and also adds a considerable amount of ill-defined machinery
> > that will come out in the interoperability testing and in 
> implementation.
> >
> > My proposal is designed to work with the existing context model that RM
> > defines (a sequence) and to make minimal changes to how the server and
> > client manage and use that context. Because of the work the TC has done
> > in tightening up the lifecycle of this context and in interop testing,
> > my proposal builds on top of an already stable and interoperable base
> > with a small and clearly defined addition.
>
> So does Doug's proposal, IMO.
>
> >
> > Paul
> >
> > >
> > >
> > > *Doug Bunting <Doug.Bunting@Sun.COM>*
> > > Sent by: Doug.Bunting@Sun.COM
> > >
> > > 05/01/2006 03:00 PM
> > >
> > >
> > > To
> > > Doug Davis/Raleigh/IBM@IBMUS
> > > cc
> > > ws-rx@lists.oasis-open.org
> > > Subject
> > > Re: [ws-rx] i089 proposal
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Doug,
> > >
> > > I may be struggling with a similar issue to Marc though I would phrase
> > > it differently: Could you please describe how your "general" solution
> > > fits into the Charter[1] under which our group was formed?
> > >
> > > thanx,
> > > doug
> > >
> > > [1] <http://www.oasis-open.org/committees/ws-rx/charter.php>
> > >
> > > On 30/04/06 17:57, Doug Davis wrote:
> > > >
> > > > Marc,
> > > > First, I'm glad that I think we're all in agreement that a polling
> > > > solution is the right solution for these issues - I think that alone
> > > > is progress. So, as you say, the question then becomes a matter of
> > > > placement of function. Up to now I think most people have chosen to
> > > > ignore this issue. Yes some groups (like WS-BaseNotification or
> > > > WS-Management) saw the issue and defined their own domain specific
> > > > solutions, but they are just that - domain specific. As you say in
> > > > your note, a more foundational architectural solution is a better
> > > > approach. So, is RM one of those specs? RM clearly isn't domain
> > > > specific and it deals with transfer of messages between endpoint 
> - so
> > > > far so good. As I've said several times, I don't think its a stretch
> > > > to think of reliability as more than just resend until acked. Right
> > > > now RM already deals with reaching unreachable endpoints - but we've
> > > > been thinking of it limiting itself to 'unreachable' meaning
> > > > temporarily down - or poor networks connections. I really don't 
> think
> > > > its hard to see anon endpoints as being part of that grouping - 
> there
> > > > really isn't much of a difference. In all cases the other side isn't
> > > > guaranteed to be there - the only thing that's special about 
> this case
> > > > is how the connection between the two endpoints is established -
> > > > beyond that everything else is the same (at least for our proposal -
> > > > Paul's doesn't keep everything else the same but that's a different
> > > > note :-).
> > > > Perhaps I didn't say it correctly, but its not that I think its RM's
> > > > job to get the anon/sync world to look as much like the async 
> world -
> > > > what I meant to say is that we wanted our polling solution to allow
> > > > them to look the same to the code that makes use of it.
> > > > thanks,
> > > > -Doug
> > > >
> > > >
> > > >
> > > > *"Marc Goodner" <mgoodner@microsoft.com>*
> > > >
> > > > 04/28/2006 04:32 AM
> > > >
> > > >
> > > > To
> > > > Doug Davis/Raleigh/IBM@IBMUS,
> > > <ws-rx@lists.oasis-open.org>
> > > > cc
> > > >
> > > > Subject
> > > > RE: [ws-rx] i089 proposal
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > I’m certainly against banning anon. Why is it the mandate of RM to
> > > > “get the anon/sync world to look as much like the async world as
> > > > possible”? Your proposal makes it clear that is what your goal 
> is, but
> > > > that is also foremost in my mind why it has nothing to do with RM.
> > > > That statement clearly scopes the problem you are trying to 
> solve as a
> > > > foundational architectural concern below the level of RM.
> > > >
> > > > Marc Goodner
> > > > Technical Diplomat
> > > > Microsoft Corporation
> > > > Tel: (425) 703-1903
> > > > Blog: _http://spaces.msn.com/mrgoodner/_
> > > >
> > > > 
> ------------------------------------------------------------------------
> > > >
> > > > *From:* Doug Davis [mailto:dug@us.ibm.com] *
> > > > Sent:* Friday, April 28, 2006 1:28 AM*
> > > > To:* ws-rx@lists.oasis-open.org*
> > > > Subject:* RE: [ws-rx] i089 proposal
> > > >
> > > >
> > > > I think this scenario is required for RM. At the last f2f we talked
> > > > about how an RMS may need to create new sequences for a variety of
> > > > reasons - one of which was because people wanted to be able to 
> create
> > > > a new sequence based on the soap version, but there are lots of 
> other
> > > > reasons people may need to create 'em. IMO, the use of the anon EPR
> > > > should not impact these types of decisions - remember we're 
> trying to
> > > > get the anon/sync world to look as much like the async world as
> > > > possible. If we allowed anon EPRs to impact our RM
> > > > processing/decision-making model then we would need to explore 
> banning
> > > > the use of anon, which I believe is something your against.
> > > > -Doug
> > > >
> > > > *"Marc Goodner" <mgoodner@microsoft.com>*
> > > >
> > > > 04/28/2006 04:14 AM
> > > >
> > > >
> > > > To
> > > > Doug Davis/Raleigh/IBM@IBMUS,
> > > <ws-rx@lists.oasis-open.org>
> > > > cc
> > > >
> > > > Subject
> > > > RE: [ws-rx] i089 proposal
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Doug, is that scenario required for RM or polling in general? As 
> soon
> > > > as you start talking about a server side RMS establishing a sequence
> > > > to an un-addressable client I think you are beyond RM. You can’t
> > > > establish inbound communications from a server to an un-addressable
> > > > client without RM so why is this an RM problem?
> > > >
> > > > If we are looking to add a tightly scoped polling mechanism to 
> RM for
> > > > specific scenarios this one would not be high on my list.
> > > >
> > > > Marc Goodner
> > > > Technical Diplomat
> > > > Microsoft Corporation
> > > > Tel: (425) 703-1903
> > > > Blog: _http://spaces.msn.com/mrgoodner/_
> > > >
> > > >
> > > >
> > > > 
> ------------------------------------------------------------------------
> > > >
> > > > *
> > > > From:* Doug Davis [mailto:dug@us.ibm.com] *
> > > > Sent:* Friday, April 28, 2006 1:05 AM*
> > > > To:* ws-rx@lists.oasis-open.org*
> > > > Subject:* Re: [ws-rx] i089 proposal
> > > >
> > > >
> > > > I do believe that the scenario you're talking about is a 
> required one
> > > > but I would phrase it
> > > > a bit differently. An RMS (whether its the client-side RMS or the
> > > > server-side RMS) needs
> > > > to be able to follow the same RM processing model. And part of the
> > > > processing model
> > > > is the ability to decide "if", "when" and "how" to use RM. As we 
> talk
> > > > about in the Q&A
> > > > section of our proposal, an RMS having the option of choosing to
> > > > decide which RM sequence
> > > > to use, when to create new ones, or even when to use RM at all 
> are all
> > > > part of the RM
> > > > processing model and those aspects need to be maintained even in 
> these
> > > > anon cases.
> > > > In your proposal you put the burden on the RMD to make a lot 
> decisions
> > > > on behalf of
> > > > the RMS, that's quite a change to the RM processing model and I have
> > > > no idea how the
> > > > RMD could ever know all it would need to know to make those 
> decisions.
> > > > For example, how
> > > > would it know when a new sequence is needed by the RMS? That is 
> why I
> > > > believe our
> > > > proposal is a better fit for RM - it allows the RMS to retain all of
> > > > the same logic and choices
> > > > that it has in the async world. Our proposal simply re-establishes
> > > > the backchannel that
> > > > the RMS (on the server side) is looking for - nothing more. Once 
> that
> > > > is there, it is then
> > > > back to "standard operating procedures" - the RMS can do whatever it
> > > > would normally
> > > > do.
> > > > thanks,
> > > > -Doug
> > > >
> > > > *Paul Fremantle <paul@wso2.com>*
> > > >
> > > > 04/27/2006 05:51 PM
> > > >
> > > >
> > > >
> > > >
> > > > To
> > > > Marc Goodner <mgoodner@microsoft.com>
> > > > cc
> > > > wsrx <ws-rx@lists.oasis-open.org>
> > > > Subject
> > > > Re: [ws-rx] i089 proposal
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > If the TC isn't attached to this scenario then this section can be
> > > > deleted. The scenario is simply when you want to send unreliably but
> > > > receive reliable responses. I've heard this stated as a 
> requirement in
> > > > some scenarios, but WSO2 doesn't have any pressing scenarios of 
> this ilk
> > > > so we would be happy either way.
> > > >
> > > > Paul
> > > >
> > > > Marc Goodner wrote:
> > > > > So is an RMS engaged at the client side or not? This is weird, 
> why
> > > would
> > > > > the infrastructure on the client side decide to do this?
> > > > >
> > > > > Marc Goodner
> > > > > Technical Diplomat
> > > > > Microsoft Corporation
> > > > > Tel: (425) 703-1903
> > > > > Blog: http://spaces.msn.com/mrgoodner/
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Paul Fremantle [mailto:paul@wso2.com]
> > > > > Sent: Thursday, April 27, 2006 12:57 PM
> > > > > To: Marc Goodner
> > > > > Cc: wsrx
> > > > > Subject: Re: [ws-rx] i089 proposal
> > > > >
> > > > > Marc
> > > > >
> > > > > This is the case where the client is making an offer but not
> > > creating an
> > > > >
> > > > > outbound sequence - thats all. A client offers a sequence, and 
> then
> > > > > reliably gets messages from the server that are buffered under 
> that
> > > > > sequenceID.
> > > > >
> > > > > Paul
> > > > >
> > > > > Marc Goodner wrote:
> > > > >
> > > > >> I still don't understand why offered sequence is being used 
> in the
> > > > >> explanation. If this is going to usually be used with an offered
> > > > >> sequence I'd like to understand how, that isn't explained in 
> my mind.
> > > > >>
> > > > > If
> > > > >
> > > > >> it is applicable for any sequence, offered or not, I'd like to
> > > > >> understand that as well. The current text only confuses me in 
> its use
> > > > >>
> > > > > of
> > > > >
> > > > >> the term and I'm afraid your explanation below isn't helping 
> me get
> > > > >>
> > > > > past
> > > > >
> > > > >> it. Perhaps comparing the two modes would be a better approach.
> > > > >>
> > > > >> On 4.2, "Offer a sequence without the overhead of requesting 
> one"? I
> > > > >> don't understand. The text refers to the RMD requesting a 
> sequence
> > > > >>
> > > > > from
> > > > >
> > > > >> the RMS, but it sounds like this is an unreliable request so 
> doesn't
> > > > >> that mean there is no RMS at the client? Isn't this about the 
> service
> > > > >> acting as an RMS and the client acting as an RMD? So the pattern
> > > would
> > > > >> be client sends one way message to service (GetMessage?), 
> response is
> > > > >> Offer, then client sends a response to the response of 
> Accept? What
> > > > >>
> > > > > does
> > > > >
> > > > >> the service return to that? Why wouldn't the service send a CS
> > > in the
> > > > >> body of the GetMessage response to the client?
> > > > >>
> > > > >> Marc Goodner
> > > > >> Technical Diplomat
> > > > >> Microsoft Corporation
> > > > >> Tel: (425) 703-1903
> > > > >> Blog: http://spaces.msn.com/mrgoodner/
> > > > >>
> > > > >>
> > > > >> -----Original Message-----
> > > > >> From: Paul Fremantle [mailto:paul@wso2.com]
> > > > >> Sent: Monday, April 24, 2006 1:11 AM
> > > > >> To: Marc Goodner
> > > > >> Cc: wsrx
> > > > >> Subject: Re: [ws-rx] i089 proposal
> > > > >>
> > > > >> Marc
> > > > >>
> > > > >> I use the words "Offered Sequence" informatively and 
> non-normatively.
> > > > >> This is most likely to be used with an offered sequence, but 
> isn't
> > > > >>
> > > > > tied
> > > > >
> > > > >> to that.
> > > > >>
> > > > >> As regards 4.2, this is there to satisfy the scenario where 
> you only
> > > > >> want reliable responses. I added this in for discussion 
> because I
> > > know
> > > > >>
> > > > >
> > > > >
> > > > >> that some members find this an important scenario. In that 
> case you
> > > > >>
> > > > > need
> > > > >
> > > > >> to be able to Offer a sequence without the overhead of 
> requesting
> > > one.
> > > > >>
> > > > >
> > > > >
> > > > >> It is related to the anonymous client because without a real 
> endpoint
> > > > >> the server cannot send a CS to the client so it relies on an 
> offer.
> > > > >>
> > > > >> Paul
> > > > >>
> > > > >> Marc Goodner wrote:
> > > > >>
> > > > >>
> > > > >>> Given 1 and 2, yes some text that clarified that not only is 
> this
> > > > >>> specific to RM but that a general solution would be 
> preferable would
> > > > >>>
> > > > >>>
> > > > >> be
> > > > >>
> > > > >>
> > > > >>> best.
> > > > >>>
> > > > >>> On 3 I suppose, I don't like seeing WS-A headers in the body 
> of a
> > > > >>> message though. Do you really even need the response for a 
> specific
> > > > >>> message? Why not return any responses or messages for that 
> sequence
> > > > >>>
> > > > >>>
> > > > >> that
> > > > >>
> > > > >>
> > > > >>> have not been acknowledged? And what are you talking about 
> when you
> > > > >>>
> > > > >>>
> > > > >> say
> > > > >>
> > > > >>
> > > > >>> this is tied to the offered sequence? What offered sequence? 
> I don't
> > > > >>>
> > > > >>>
> > > > >> see
> > > > >>
> > > > >>
> > > > >>> anything here that ties the use of your GetMessage proposal 
> to an
> > > > >>> offered sequence.
> > > > >>>
> > > > >>> I don't understand section 4.2 in your proposal at all. What 
> does
> > > > >>>
> > > > > this
> > > > >
> > > > >>> have to do with the rest of this proposal?
> > > > >>>
> > > > >>> Marc Goodner
> > > > >>> Technical Diplomat
> > > > >>> Microsoft Corporation
> > > > >>> Tel: (425) 703-1903
> > > > >>> Blog: http://spaces.msn.com/mrgoodner/
> > > > >>>
> > > > >>>
> > > > >>> -----Original Message-----
> > > > >>> From: Paul Fremantle [mailto:paul@wso2.com]
> > > > >>> Sent: Thursday, April 20, 2006 1:57 AM
> > > > >>> To: Marc Goodner
> > > > >>> Cc: wsrx
> > > > >>> Subject: Re: [ws-rx] i089 proposal
> > > > >>>
> > > > >>> Marc
> > > > >>>
> > > > >>> 1) Yes - I completely aimed this to be a specific model for 
> RM. I
> > > > >>>
> > > > >>>
> > > > >> would
> > > > >>
> > > > >>
> > > > >>> be happy to include language that indicates that if a more 
> general
> > > > >>> purpose firewall crossing mechanism was in place this should 
> not be
> > > > >>> used.
> > > > >>> 2) The wsrm:Identifier is a required part of my proposal, and
> > > > >>> As a much lower technical detail, I do not believe your
> > > > proposal addresses one of the major issues
> > > > >>>
> > > > >> therefore
> > > > >>
> > > > >>
> > > > >>> this proposal is completely tied to the use of RM.
> > > > >>> 3) The suggestion of using messageNumber is interesting. The
> > > > >>>
> > > > >>>
> > > > >> motivation
> > > > >>
> > > > >>
> > > > >>> for using a message ID was that there may be situations where I
> > > > >>>
> > > > > really
> > > > >
> > > > >>>
> > > > >>>
> > > > >>
> > > > >>
> > > > >>> want the response to a given message. We do not - so far - 
> have any
> > > > >>> concept of a response to a given RM messageID, so that 
> seemed like a
> > > > >>>
> > > > >>>
> > > > >> new
> > > > >> As a much lower technical detail, I do not believe your proposal
> > > > addresses one of the major issues
> > > > >>
> > > > >>> concept to me, whereas WS-A systems do keep track of 
> responses to
> > > > >>>
> > > > >>>
> > > > >> given
> > > > >>
> > > > >>
> > > > >>> messageIDs. But I'm not averse to your suggestion. However I 
> wish to
> > > > >>> make clear that in my proposal you MUST have both the 
> Identifier and
> > > > >>>
> > > > >>>
> > > > >> the
> > > > >>
> > > > >>
> > > > >>> messageID - so it is still very closely tied to the offered
> > > sequence.
> > > > >>>
> > > > >>> Paul
> > > > >>>
> > > > >>> Marc Goodner wrote:
> > > > >>>
> > > > >>> As a much lower technical detail, I do not believe your
> > > > proposal addresses one of the major issues
> > > > >>>
> > > > >>>> I hope that this is scoped to RM and not a general purpose 
> polling
> > > > >>>> mechanism. I assume that is your intent in that you use the
> > > > >>>> wsrm:Identifier and indicate that you see this being part 
> of the
> > > > >>>>
> > > > > core
> > > > >
> > > > >>>> spec. Still it seems like including language that indicates 
> that
> > > > >>>>
> > > > >>>>
> > > > >> would
> > > > >>
> > > > >>
> > > > >>>> be advised, particularly noting that if there were a general
> > > purpose
> > > > >>>> polling mechanism that it might be preferred over this one.
> > > > >>>>
> > > > >>>> So following from that why is MessageID in the GetMessage?
> > > Isn't the
> > > > >>>> identifier enough? If it isn't wouldn't the addition of
> > > > >>>> wsrm:MessageNumber do the trick?
> > > > >>>>
> > > > >>>> Marc Goodner
> > > > >>>> Technical Diplomat
> > > > >>>> Microsoft Corporation
> > > > >>>> Tel: (425) 703-1903
> > > > >>>> Blog: http://spaces.msn.com/mrgoodner/
> > > > >>>>
> > > > >>>>
> > > > >>>> -----Original Message-----
> > > > >>>> From: Paul Fremantle [mailto:paul@wso2.com]
> > > > >>>> Sent: Thursday, April 06, 2006 12:40 PM
> > > > >>>> To: wsrx
> > > > >>>> Subject: [ws-rx] i089 proposal
> > > > >>>>
> > > > >>>> Folks
> > > > >>>>
> > > > >>>> At the F2F I took away an action to come up with a proposal 
> for
> > > i089
> > > > >>>>
> > > > >
> > > > >
> > > > >>>> before the call. I'm sorry its so close to the call.
> > > > >>>>
> > > > >>>> I've attached a proposal for review. This is a work in
> > > progress, but
> > > > >>>>
> > > > >>>>
> > > > >> I
> > > > >>
> > > > >>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>> think it helps call out some of the issues involved around 
> i089.
> > > > >>>>
> > > > >>>> I think the most important questions for the TC are:
> > > > >>>>
> > > > >>>> (1) How does a customer/user use WSRM in a two-way scenario 
> if one
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>> side
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>> is anonymous?
> > > > >>>> (2) Adding a "GetMessage" makes the protocol more 
> symmetric, but
> > > > >>>>
> > > > > also
> > > > >
> > > > >>>>
> > > > >>>>
> > > > >>
> > > > >>
> > > > >>>> might overlap with a wider non-reliable solution to this
> > > problem. Is
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>> it
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>> in the scope of this TC to add this?
> > > > >>>> (3) In the case we do add it, what criteria do we use to select
> > > > >>>>
> > > > > which
> > > > >
> > > > >>>>
> > > > >>>>
> > > > >>
> > > > >>
> > > > >>>> message to request.
> > > > >>>> (4) Is this a generic solution (i.e. can the RMD request 
> messages
> > > > >>>>
> > > > >>>>
> > > > >> from
> > > > >>
> > > > >>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>> the RMS in all cases) or special cased to anonURI scenarios?
> > > > >>>>
> > > > >>>> Paul
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > >
> > > > --
> > > >
> > > > Paul Fremantle
> > > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> > > >
> > > > http://feeds.feedburner.com/bloglines/pzf
> > > > paul@wso2.com
> > > >
> > > > "Oxygenating the Web Service Platform", www.wso2.com
> > > >
> > >
> >
> > --
> >
> > Paul Fremantle
> > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> >
> > http://feeds.feedburner.com/bloglines/pzf
> > paul@wso2.com
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
> >

-- 

Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://feeds.feedburner.com/bloglines/pzf
paul@wso2.com

"Oxygenating the Web Service Platform", www.wso2.com