Re: [ws-rx] PR001 - Feedback on MSFT's MC proposal

[Paul Fremantle <paul@wso2.com>]

      Looking at another use-case - say there's an RMS is implemented as
    a gateway/proxy - where all messages leaving the environment heading
    for another destination are placed into the same RM Sequence -
    because there's (as I've heard Chris describe it) "one big pipe"
    between the two companies. In this scenario the gateway has no idea
    of the MEPs being used or the application semantics involved - all
    it basically does is add the RM Sequence header to the messages. It
    then becomes up to each individual client (since its the only one
    that knows the MEPs and application semantics) to request the
    responses that may be expected. Again, we need to be able to
    identify which response goes to which client/MakeConnection request.


Doug

This is a usecase we are currently working on implementing using Apache 
Synapse. In our model, the clients do not need to know anything about 
MakeConnection. The gateway correlates responses back to clients using 
either WSA semantics (replyTo and messageID), or by holding onto the 
socket and correlating between the incoming client's socket and the WSA 
messageID that we assign to outgoing messages. The gateway polls for 
responses on the MC(sequenceID) (in the current model). I see no reason 
why the model Marc is proposing wouldn't also work.

So while I agree completely you can implement the model the way you are 
suggesting, it isn't at all a necessity. In fact the model we are 
implementing supports anonymous clients who do not even implement WSA, 
let alone WSRM. For example, JMS clients can be bridged into WSRM reliably.

Paul


Doug Davis wrote:
>
> Jacques,
> responses *inline*.
> -Doug
>
>
>
> *"Durand, Jacques R." <JDurand@us.fujitsu.com>*
>
> 11/03/2006 10:41 PM
>
> 	
> To
> 	Doug Davis/Raleigh/IBM@IBMUS
> cc
> 	"Marc Goodner" <mgoodner@microsoft.com>, <ws-rx@lists.oasis-open.org>
> Subject
> 	RE: [ws-rx] PR001 - Feedback on MSFT's MC proposal
>
>
>
> 	
>
>
>
>
>
> Doug:
>
> ------------------------------------------------------------------------
>
> *From:* Doug Davis [mailto:dug@us.ibm.com] *
> Sent:* Friday, November 03, 2006 7:16 AM*
> To:* Durand, Jacques R.*
> Cc:* Marc Goodner; ws-rx@lists.oasis-open.org*
> Subject:* RE: [ws-rx] PR001 - Feedback on MSFT's MC proposal
>
>
> Jacques,
> I disagree that its a non-requirement. There are lots of scenarios in 
> which a series of messages need to sent where the order must be 
> preserved. Clearly one way to achieve this is to serialize the sending 
> of the messages so that message number N is not sent until message 
> number N-1's response is received. However, this is not a very 
> efficient model. RM is an obvious choice here.
> By using RM a sending endpoint can parallelize its sending of the 
> messages and be assured that the other side will reorder them 
> appropriately. Thus adding a firewall into the environment you now 
> have a series of anonymous clients all sending messages that need to 
> be in the same RM Sequence in order to achieve the desired results. 
> Saying that the clients should not be anonymous in the first place is 
> simply ignoring the problem that many of our customers have. BTW, we 
> have a requirement for this in some notification systems, where we 
> need to ensure that the events we're sending are not processed out of 
> order.
> <JD> So I think we agree on the “business” requirement you describe 
> here – a single seq may need be shared among a set of consumers. But 
> couldn’t these endpoints still be given each a unique EPR? After all, 
> you are proposing to identify them anyway (WS-RM anon URI).
> *<dug> definately could - each one may have a unique RManonURI or they 
> each may share the same one - it depends on the environment and the 
> current spec allows for both choices. But the key point here is that 
> its the implementation/user's choice - not the RM spec's choice.*
>
> I believe that they could still be given a regular EPR (not an RM 
> anon) *<dug> LOL solve anon by not using anon - funny - but I'll keep 
> reading :-) </dug> *and that could still work with a “limited” MC, as 
> proposed in Marc’s. But let me start by describing what I think might 
> be a problem for both proposals (Marc’s and current spec – meaning 
> yours). Unless I miss something, your above use case may require some 
> upgrade to both proposals in fact. Consider the two variants:
> Use Case “shared-sequence” A: each consumer endpoint kind of 
> “initiate” the connection to open a back-channel, as this seems to 
> have been suggested in the call yesterday. So the consumer endpoint 
> would control the MC sending, and be the direct recipient of the HTTP 
> response generated (e.g. RMD implemented as Java handler). But that is 
> incompatible with several consumers sharing the same sequence, 
> especially if the sequence is ordered (consumer C1 does not know when 
> to pull a message for himself – the next msg in the sequence on RMS 
> side might be for C3 or C4). So consumer endpoints should not be the 
> ones initiating a pulling if they share same sequence. Instead, the MC 
> should open a connection for whatever message is in this sequence, and 
> the MC should not indicate in wsrm:Address any consumer-specific 
> identifier (which I believe is a problem with our current solution).
> *<dug> No I totally disagree. And this is a very important point 
> because this applies to both the anon and the async cases. In the 
> InOrder case, whenever an endpoint receives a message that is sent 
> using RM, the RM processor (the RMD) MUST take control over that 
> message at some point - if for nothing else to block it from being 
> delivered to the AD before any lowered numbered message. The order in 
> which the messages arrive at the RMD themselves it totally irrelevant 
> - that's the point of using RM - it will reorder them. So, in the anon 
> client case it doesn't matter which client receives the "next" message 
> because the RM logic on the RMD will block it, if needed, from being 
> delivered until all lower numbered messages for that Sequences arrive. 
> This is the exact same thing that happens in the async world - it 
> doesn't matter how many endpoint are being spanned by a single virtual 
> RMD, it doesn't matter in what order the messages arrive, the RMD 
> logic will make sure that they are delivered in the proper order. And 
> to be fair, what's missing from Marc's proposal isn't this ordering 
> stuff (that's just normal RM logic), its the delivery of the message 
> to the right endpoint.*
> Therefore, the right model for your use case, is use case B below:
> Use Case “shared-sequence” B: each consumer endpoint let the RMD they 
> share initiate the pulling on the common sequence. The RMD is the one 
> opening the new connection with MC and does so NOT on behalf of a 
> consumer in particular. In that case, the MC/wsrm:Address in current 
> spec, as well as MakeConTo EPR in Marc ‘s is associated with the RMD, 
> not with the consumers behind. Issue: the RMS must be able to 
> initially know somehow which consumer endpoints are behind this RMD 
> EPR. I see no other way than to communicate somehow the list of 
> consumer endpoints EPRs that are associated with this RMD, to RMS, so 
> that the RMS knows that this RMD is proxying for these endpoints and 
> can authorize the RMD, as the MC connection will be initiated from the 
> RMD. In Marc’s , the MakeConTo EPR is well named: this is the 
> “connection” EPR – not necessarily the destination EPR (wsa:To) of the 
> pulled message. The dispatching to the right consumer endpoint on RMD 
> side is based on wsa:To.
> I think in Marc’s the wording “… e.g. when sent to anonymous endpoint” 
> should be replaced with “…e.g. when sent to unreachable endpoint”.
> *<dug> I have to admit this makes no sense to me. But I think my 
> previous comments should address this. I think you're forgetting that 
> if an RMD (or and RMS) spans multiple endpoint then they share RM 
> state data and that includes when messages are allowed to continue on 
> to the AD*
>
> Looking at another use-case - say there's an RMS is implemented as a 
> gateway/proxy - where all messages leaving the environment heading for 
> another destination are placed into the same RM Sequence - because 
> there's (as I've heard Chris describe it) "one big pipe" between the 
> two companies. In this scenario the gateway has no idea of the MEPs 
> being used or the application semantics involved - all it basically 
> does is add the RM Sequence header to the messages. It then becomes up 
> to each individual client (since its the only one that knows the MEPs 
> and application semantics) to request the responses that may be 
> expected. Again, we need to be able to identify which response goes to 
> which client/MakeConnection request.
>
> <JD> Asre you saying that this same sequence would be dispatched to 
> several RMD instances? I guess you assume in fact a single RMD (even 
> if it uses several URLs, still behaving virtually as one, RMstate-wise).
> *<dug> Actually, I was thinking a little bit of both :-) You can have 
> a single RMD in front of several AD machines - this is normal proxy 
> stuff. Or you could have an RMD span multiple endpoints as we 
> discussed in the previous comments.*
> So in that case it looks like we fall back on the previous use case. 
> Only it makes it clearer that consumer endpoints need in fact be well 
> identified (EPR)* Nope *, but RMD **also** be able to behave like a 
> proxy, being the one handling the MC connection dealing 
> indiscriminately with all messages in the “big pipe” and then 
> supporting the forwarding (or queuing) to the right consumer based on 
> wsa. The big pipe model seems at odd with clients trying to pull 
> selectively from the same sequence/pipe the message they want – the 
> only requirement associated with the addressing info in MC is “make 
> sure to NOT send me back a message for a different address” , not 
> “please give me next message for this address right away” , so that 
> could be quite inefficient (many more “empty” MCs). Note that in a 
> configuration based on gateways, it makes sense to me that the RMD 
> also be a gateway, and handles its own connections.
> *<dug> I had trouble following this. The current spec (and I think 
> Marc's proposal) doesn't really place any restriction on which message 
> is send back beyond (for lack of a better term) the query/scoping 
> data. The receiver of the MC (the RMS) decides which message is 
> appropriate to send next - either based on Seq or destination URI. All 
> versions of MC bascially just open a connection and from that point on 
> its up to the receiving side to decide what to do - this is just like 
> the async model except who opened the connection - but I think I'm 
> totally lost by the point you're trying making here </dug>*
>
> (On a side note - this is actually a good use-case for why the AcksTo 
> exists at all. The RMS and the AS may not be co-located - so the RMS 
> may need to be separately identified (by an EPR) from the AS. Meaning, 
> the AS doesn't want to receive the Seq Faults, its the RMS that does).
>
> Expanding this discussion to my 2nd point in my issue list - the 
> grouping of messages into a Sequence based on the wsa:To. Again, look 
> at the Gateway/proxy scenario. Here an RMS may be setup to choose 
> which "big pipe/sequence" each message should be placed into based on 
> the message's destination. If all of the messages have a wsa:To of 
> anonymous then the RMS is unable to effectively do its job. We need a 
> way to uniquely identify endpoints - something that the static 
> anonymous URI does not give us today.
>
> <JD> agree on this point: these destinations must be well identified 
> and wsa:To be usable for routing. But I see that both proposals work 
> fine on this sscenario. Assuming here this use case is about a single 
> destination for each sequence, the MC can be initiated from the 
> consumer endpoint that can identify itself with wsa:From. The 
> MakeConTo in Marc’s can be associated with this endpoint, and the MC 
> pull on the right sequence.
> *<dug> *IF* a Sequence is scoped down to just a single endpoint per 
> sequence then yes I agree, all variants of MC work. But that's not the 
> point. The issue I'm raising is that Marc's proposal does not allow 
> for anything but a 1-1 relationship between an endpoint and a 
> Sequence. I think you're agreeing with me that my issue is valid and 
> my point is valid - marc's proposal does not work in these use-cases.*
>
> Now, let's examine this from a lower level - the implementation point 
> of view. Simply because these clients share RM state information does 
> not mean that they can all be treated as the same endpoint and get 
> each other responses. To show why this can't be let's examine the 
> non-failure situation where the response is ready immediately to flow 
> back on the HTTP response of the request. If we were to actually treat 
> all anon clients from the same RM sequence equally then using that 
> logic when we have 2 clients talking to the server (using the same RM 
> sequence) then client 1 should be allowed to get client 2's response 
> on the http response flow to client 1's request. Did that parse right? 
> :-) In other words, the message flows would look like this:
> client 1 sends request1 - on http response flow it gets client 2's 
> response2
> client 2 sends request2 - on http response flow it gets client 1's 
> response1
> This violates WSA's response processing rules and is just plain wrong 
> :-) but that's the implication by saying that all anon clients are the 
> same - which just can't be. The RMD must be able to know which client 
> is which in order to properly deliver the messages to the appropriate 
> endpoint unless we severely restrict the use-cases that RM will 
> support when clients are forced to live in a synchronous environment - 
> which I know our customers would not be happy with.
> <JD> this case is moot w/r to my solution B above: your (legitimate) 
> issue would not occur. Clients should not be “anon”. But back to my 
> initial point, this use case is again a problem for the current 
> solution in spec in case the sequence must be ordered: this selective 
> pulling would not make much sense. What I like in Marc’s proposal is 
> that it supports well the gateway model for RMD too, with MC focused 
> on getting a sequence and initiated from RMD itself – regardless of 
> how many consumers behind. And no need for the hybrid animal we have 
> today that combines wsrm:Identifier + wsrm:Address, resulting from 
> merging two previous proposals (design by committee would some say 
> ;-)…this besides the fact that an MC serving only reliable messaging 
> has a tighter semantics that would not present the composition 
> unknowns and interop loose ends of a more general one.
> *<dug> couple of points:*
> *1 - saying we support anon by not using anon isn't a valid argument :-)*
> *2 - I think I've made it clear, from the stuff above, that you're 
> incorrect in your claims about the current spec lacking support for 
> these scenarios*
> *3 - there are no composition problems - I made this clear on 
> Thursday's call - RM composes just fine with WSA (as is!). CR33 was 
> opened because of a problem with WSA all by itself - RM just helped 
> discover it - and dispite all of the pain its causing the WSA WG I do 
> think that in the end WSA will be better off because of it - but I'm 
> trying to be optimistic about the outcome ;-)*
> *4 - re:hybrid animal - I agree its not ideal but that's part of the 
> world of compromising :-) The MC+SeqID variant was added to the spec 
> with the understanding that it only supported a limited set of 
> use-cases - the ones discussed in this note are not part of that set. 
> For the cases where people are fine with being confined to situations 
> where they have just a 1-1 relationship between an endpoint and a 
> Sequence, and they can live with always sending/accepting the Offer, 
> and they can live with their AcksTo EPR always being the same as the 
> replyTo EPR, and they can live with the fact that the server-side can 
> not create new Sequences as needed, and they know through some out of 
> bands means whether or not the client will actually ever send a MC at 
> all, then they can use the MC+seqID variant. All other use-cases (and 
> of course this limited one) are supported by the MC+RManonURI variant 
> - but people are free to choose how they want to work. I would also 
> point out that its exactly because of these "known limitations" that 
> PR issues were not opened during the interop testing of MC+SeqID. From 
> our side, we had to make sure that when we deployed our endpoint that 
> we configured thing just right to make it work - in other words, force 
> ourselves into the tight boundaries that MC+SeqID requires. If we 
> didn't go into this knowing that we could avoid those issue by 
> switching over to the MC+RManonURI variant then issues would have been 
> filed.*
> *5 - Please explain the "interop loose ends" comment because I have 
> yet to hear a single interop issue raised against what's currently in 
> the spec. All I've heard are political (or personal) attacks. I've 
> tried very hard to list all of the _technical_ issues I have with 
> Marc's proposal [1] - and not make general unsubstantiated claims 
> (like "things are broken" or "there are interop issues") as other's 
> have made. *
>
> *[1] 
> http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200611/msg00011.html* 
>
>
> Disclaimer: I do not pretend that my above use cases are comprehensive 
> enough or fully addressed ;-) may have overlooked some points I am not 
> aware of – e.g. having not been closely involved in WSA, or may have 
> left some corner cases… (trust you guys to find these if any ;-)
> Cheers,
> Jacques
>
>
> We spent a lot of time trying to make sure that all of the full range 
> of features that RM offers when a customer is living in an 
> asynchronous world would still be available once a firewall was added 
> to the picture. Obviously, it may not always be possible to achieve 
> this, but the fact that the current MC solution that's in the spec 
> does not place additional restrictions on the RM processing model or 
> _any_ of its features available to implementers and users is, IMO, one 
> of its key strengths. Since RM is such a base specification that for 
> us to (w/o good reason) summarily discount certain features of RM 
> simply because a firewall was introduced is immediately labeling our 
> spec as deficient before it even 'hits the streets' - and removing 
> support for scenarios like the ones mentioned above would do exactly 
> that. But that's just my unbiased opinion. :-)
>
> thanks
> -Doug
>
> *"Durand, Jacques R." <JDurand@us.fujitsu.com>*
>
> 11/02/2006 03:48 PM
>
> 	
> To
> 	Doug Davis/Raleigh/IBM@IBMUS, "Marc Goodner" <mgoodner@microsoft.com>
> cc
> 	<ws-rx@lists.oasis-open.org>
> Subject
> 	RE: [ws-rx] PR001 - Feedback on MSFT's MC proposal
>
>
>
> 	
>
>
>
>
>
>
> Several “anon clients” sharing the same RMD and the same sequence, and 
> still expecting to be identified for getting each their message, seems 
> to me a non-requirement.
> They should not be anonymous in the first place – which does not 
> remove the possibility that the RMD is unreachable and needs to use 
> MCs to get this sequence.
>
> The latest proposal from Marc (“MakeConTo”) removes the concerns I had 
> on overloading AcksTo.
> It could be more explicit on how the CSR in Fig 2 received on another 
> connection, is correlated with the CS by the RMS of the in-bound 
> (wsa:relatesTo I assume)
>
> -Jacques
>
>
>
> ------------------------------------------------------------------------
>
> *
> From:* Doug Davis [mailto:dug@us.ibm.com] *
> Sent:* Wednesday, November 01, 2006 3:17 PM*
> To:* Marc Goodner*
> Cc:* ws-rx@lists.oasis-open.org*
> Subject:* RE: [ws-rx] PR001 - Feedback on MSFT's MC proposal
>
>
> Marc,
> comments *inline*. Overall, I think you need to show a lot of concrete 
> sample message flows to prove that your proposal is not only better 
> than what's in the spec but can even work at all because most of your 
> answers don't address the issues I've mentioned.
>
> Another issue was realized the other day, so I might as well mention 
> it here:
>
> Sequence Faults are sent to the AcksTo EPR - this means that faults 
> for the client->server sequence are sent to the AcksTo EPR - which may 
> be anonymous.
> Normally when we talk about MC being used we talk about it polling for 
> messages related to the Offered Sequence *not* the 
> outbound/client->server sequence. However, in order for these 
> client->server Sequence Faults to be delivered the client MUST 
> periodically poll for them. So in this proposal how do the Sequence 
> Faults get returned? This proposal is based on the MC being sent to 
> the AcksTo EPR but the AcksTo EPR is on the wrong side of the 
> connection for this sequence. This proposal doesn't address how these 
> Fault messages can be delivered.
> The current spec doesn't have this issue because the AcksTo EPR can 
> use the same RManonURI as the other EPRs - which means a single MC can 
> be used to pull back any message that needs to be sent - whether its 
> an RM-enabled response or a SeqFault for the outbound sequence.
>
> -Doug
>
> *Marc Goodner <mgoodner@microsoft.com>*
>
> 11/01/2006 02:28 PM
>
> 	
>
>
> To
> 	Doug Davis/Raleigh/IBM@IBMUS, "ws-rx@lists.oasis-open.org" 
> <ws-rx@lists.oasis-open.org>
> cc
> 	
> Subject
> 	RE: [ws-rx] PR001 - Feedback on MSFT's MC proposal
>
>
>
>
> 	
>
>
>
>
>
>
> Doug,
>
> Thanks for the feedback. Detailed responses inline below.
>
> The net is I don’t see anything below that can’t already be done using 
> the proposal I made. As I already mentioned in the response to Anish’s 
> message the only potential change to the proposal I made is adding a 
> new EPR specifically for MC.
>
> *
> From:* Doug Davis [mailto:dug@us.ibm.com] *
> Sent:* Thursday, October 26, 2006 8:57 AM*
> To:* ws-rx@lists.oasis-open.org*
> Subject:* [ws-rx] PR001 - Feedback on MSFT's MC proposal
>
>
> Per my todo, here's feedback on the MSFT proposal for PR001 which
> also has the various use-cases interspersed.
> MG: My understanding is that the AI you took was to provide a set of 
> enumerated use cases so the two proposals could be compared. I do not 
> believe that this mail does that. However, I’m willing to see the AI 
> closed if you agree that you don’t have any additional use cases 
> beyond this for MC.
>
> Metacomments:
> - Current solution in spec is not broken nor incompatible with WSA
>
> MG: If this were true CR33 would not have been filed. *
> DUG: No matter how CR33 ends up (even close w/no action) the current 
> RM spec can compose with WSA - the only thing that needs to be made 
> clear is the value people should use for wsaw:Anonymous. No biggie. 
> CR33 wasn't opened because RM couldn't work today but rather because 
> of a problem with WSA.*
>
> - This proposal will force a new PR review and Interop
>
> MG: This is not a technical argument against the proposal. The TC 
> always planned on a second PR review and it’s up to the TC whether or 
> not we really need another round of interop.
>
> - This proposal does not address any new features or use-cases
>
> MG: I agree. It fixes a part of the spec that did not work as 
> designed. It also clearly describes the feature and what it is 
> intended to. I see that as an improvement over the current spec. *
> DUG: Which parts of the current spec do not work? Making wild claims 
> like this need to be proven.*
>
> Legend:
> MC = MakeConnection
> MP = MessagePending
> CS = CreateSequence
>
> Specific comments:
> - Lack of support for multiple endpoints per Sequence.
> When a MC is received the receiver can determine which Sequence
> is being targeted by the ref-p's of the incoming message. However,
> not all messages being sent on that Sequence can be received by
> all anon endpoints. How can the receiver of MC ensure that the
> proper message (e.g. response) is given to the proper anon endpoint?
> Ability to share RM state does not equate to share of messages.
>
> MG: I think you are mixing two different scenarios here.
> 1) Support for using a single sequence to and from multiple endpoints. 
> The proposal I made certainly supports this.* * *
> DUG: This isn't an answer. Please show how it works with your 
> proposal. I think concrete message flows are needed.*
>
> 2) Support for querying a endpoint for specific messages. This is not 
> needed to support 1, nor is it needed for any RM scenario. Which 
> unreachable endpoint receives and processes a given message and when 
> it does so are implementation problems in the Client RMD and part of 
> its contract with the applications that use it. *
> DUG: Again, not an answer. Please show how two anon clients can be 
> assured that when they turn on RM and use your MC proposal they will 
> each receive the correct response. Saying that's an implementation 
> problem is not only not answer but leaves things wide open to interop 
> problems. Please show the message flows for how this would work.*
>
> - Restrictions on RM Processing model.
> Base specifications should, within reason, try to avoid restricting the
> usage pattens under which they are used. Since the RM spec is silent on
> algorithm used to determine when (and how many) Sequences are used we 
> need
> to be careful about adding things to the spec that would restrict the
> impl's choices. Above we talk about a single Sequence spanning multiple
> endpoints, but going the other direction there may be RM processors that
> choose to group messages destined to the same endpoint under one 
> Sequence.
> In essence what we're talking about grouping based on wsa:To. This 
> proposal
> would not allow for this type of processing model because all wsa:To 
> values
> would be the WSA Anon URI.
>
> MG: This is an implementation style argument and I don’t see a 
> scenario here. However, this can be accomplished by the server 
> returning a MP header with an appropriate EPR and the unreachable 
> endpoint occasionally sending an empty MC to that EPR. *
> DUG: Please show how grouping by wsa:To is achieved because I just 
> don't see how a MP header+an EPR solves it. Please show concrete 
> message flows.*
>
> - How many MC messages are needed?
> This proposal would require one MC per Sequence. If there are multiple
> Sequences at play between the two endpoints the current spec allows
> for a single MC to pull back messages from any Sequence. This could be
> a significant performance issue.
>
> MG: Both proposals require one MC per Sequence. The only difference is 
> that in this proposal one MC is for a specific Sequence; but the same 
> number of messages are exchanged. There is not an issue here. *
> DUG: Not true. This proposal requires one MC per Sequence - which 
> means if there are two active Sequences then there MUST always be two 
> MC's sent - in the current spec only one MC is needed. Yes one MC per 
> message is needed, but if there's nothing to pull back then this 
> proposal is quite a bit more chatty and far less optimal.*
>
> - Since MC is an optional feature, how does the receiver know it will 
> be used?
> Here there are two reasons the receiver of the MC would like to know
> whether or not MC will be used at all. First, the receiver may choose to
> reject requests to use the anon EPR if MC will not be used - thus saving
> resources. Second, in cases where RM is optional for messages targeted
> to the Anon EPR, if the receiver knows that MC will not be used it may
> choose to not turn on RM at all, thus allowing normal WSA rules to
> apply to its delivery. This would still allow a non-MC enabled client
> to function, where if the receiving end assumed that MC were always
> an option it may never actually deliver any message until a MC is sent.
> Thus never sending any messages.
> MG: The receiver can fault on receipt of MC if it wished to, so the 
> first point above isn’t an issue. The second point does not have a 
> clear use case. Why would an endpoint turn off RM if it knew MC wasn’t 
> going to be used? That sounds like this is no longer an RM scenario. 
> My proposal does not cover using MC for non-RM messages. I don’t 
> understand how the current spec would address what you just described 
> either. *
> DUG: This issue is about cases where MC is not used so I don't 
> understand your statements at all. How can it fault on a MC that is 
> never sent? The RMD may choose, at run-time by examining the replyTo 
> of the request, to decide whether or not to use RM at all for the 
> responses. You keep forgetting about cases where RM is available but 
> optional. So, the RMD may turn off RM and just use WSA rules because 
> it just doesn't want to support MC at all - would have thought you, of 
> all people, would want this option :-) *
>
> Also, if the receiver of the MC makes the wrong choice (meaning it thinks
> MC will not be used) and MC's do flow then a new (unused) Sequence will
> be created.
>
> MG: If you are not expecting an MC why would you create a sequence 
> instead of just faulting? *
> DUG: Because your proposal says that when an MC flows to an unknown 
> AcksTo EPR or to the Server EPR it means the client wants a new 
> Sequence - according to your proposal what else can the RMD do but 
> create a new Sequence?*
>
> - Requires special AcksTo EPR construction.
> While obviously its possible to create AcksTo EPRs with distinguishing
> ref-p's, w/o this proposal there is no need to. All RM protocol
> messages have a wsrm:Identifier already that is used to identify which
> Sequence is at play. This would require a secondary mechanism to also
> be used. While not a deal-breaker it is a duplication of function and
> forces exposure of the MC feature into the other RM aspects. Current
> version has no impact the rest of the RM spec - thus when this RM
> feature is turned on it doesn't require a change to the rest of the RM
> stack.
> MG: The current MC also has distinguishing information in it separate 
> from the wsrm:Identifier. I do not see an issue here. *
> DUG: Not true. Sequence based MC uses RM's SeqID. Since the MC+URI 
> variant isn't based on pulling by RM sequence it doesn't need to worry 
> about this. This proposal dups things unnecessarily and trying to 
> point the finger some place else doesn't change the issue.*
>
> - The AcksTo is not the same thing as the RMS.
> Implicit in this proposal is that the AcksTo endpoint has access to all
> of the same information as the RMS - which is not necessarily true. The
> AcksTo EPR is not required to do anything more than be able to update the
> state of the RM Sequences w.r.t. Acks - nothing more. This is one of the
> reasons we have a dedicated AcksTo EPR at all - otherwise we would have
> just overloaded an existing EPR - like wsa:ReplyTo or wsa:From. Using the
> AcksTo EPR for this purpose is forcing a certain implementation choice.
> MG: There was a lot of discussion on last week’s call of sending 
> protocol faults to the AcksTo EPR as they were protocol control 
> messages. So this EPR is already overloaded. I think the MC is another 
> type of protocol control message so I don’t see a problem here either. 
> That said, I’m open to seeing a new MC EPR defined. *
> DUG: Yet another change to the base RM protocol needed to support this 
> proposal.*
>
> - Orphan AcksTo
> This proposal suggests that a MP header may contain an AcksTo EPR as a
> signal that the receiver of the MP should then send a MC to that EPR
> as a mechanism by which new Sequences can be created. This would then
> create an 'orphan' AcksTo EPR. This EPR is not associated with a
> Sequence, thus its an orphan, and quite a change to how RM works.
> Or if it is associated with a Sequence then what is the state of that
> Sequence? This would imply that a Sequence is created before a CS is
> actually processed.
>
> MG: Reusing the AcksTo EPR from the MP in the CS that flows back would 
> solve this. I don’t really see an issue here either. *
> DUG: Again, you're creating an AcksTo EPR w/o creating a Sequence - 
> this goes against the current RM model - of course there's an issue 
> here. *
>
> - MP on nonexistent message.
> This proposal talks about a MP being able to flow so that the sender of
> message can signal to the anon endpoint that a MC needs to be sent so a
> CS can flow. But in cases where this is the first message being sent
> how can this work? There is no back-channel from the anon endpoint to
> send it on. Also, even if there was some incoming message how did
> the sender of the MP who which anon endpoint sent it? There is no 
> identifying
> info in the message to distinguish one endpoint from another.
> MG: The unreachable endpoint can poll with empty MCs.
> If the receiver of MCs receives an empty MC with no other identifying 
> headers (e.g. no previously communicated ref-params) then the sender 
> of the MC is truly anonymous and the response to the MC will include a 
> CS and information that will make the unreachable client identifiable 
> in the future. This is a non-issue. *
> DUG: I need a concreate message flow example here because this makes 
> no sense. If there is no message going back there's nothing to 
> piggy-back the MP onto. How does the client know to send a MC at all? 
> If there are multiple clients how does the RMD know which new/empty-MC 
> coming in is related at all to an existing request/response MEP. All 
> of these "this is a non-issue" type of responses makes it clear to me 
> that you haven't thought about this from an implementation point of 
> view because there are just too many unknowns or assumptions going on 
> here.*
>
> - Poor performing CreateSequence
> When the sending endpoint needs to use MP to create new Sequence we see
> the following message exchanges:
> Client -> some msg -> Server
> Client <- some msg+MP/AcksTo <- Server
> Client -> MakeConnection -> Server/AcksTo
> Client <- CreateSequence <- Server/AcksTo
>
> vs current solution:
> Client -> MakeConnection -> Server
> Client <- CreateSequence <- Server
> MG: This is not correct. My proposal allows for polling for the CS 
> with MC as well, so the minimal exchange in both cases is exactly the 
> same. I see the first form above as a distinct advantage of my 
> proposal over the current form in that it allows the server side to 
> set an explicit relation between previously received messages and 
> messages over a newly established sequence. *
> DUG: Please show how this works when there are multiple clients 
> talking to the same server. Above you said that the RMD can fault on 
> the receipt of a MC if it wants to - so relate that to this scenario. 
> The RMD gets new MC's from unknown/anon clientts how does it know 
> which should get back a CS and which should get a fault? There is no 
> correlating info at all. The only possible way I saw it working is how 
> I showed it above so I don't see how your claim holds up.*
>
> As stated in the previous bullet, there's no guarantee that the "some 
> msg"
> data is actually available to do that msg exchange, but also this
> proposed solution is quite a bit more verbose and non-optimized.
>
> - Unreliable-in/Reliable-Out not supported.
> Client sends a GetQuote, ReplyTo=anon. Server decides to use RM to
> send the response. How can this work? The proposal implies that
> either a CS or a MP is sent back but how and on what socket?
>
> MG: No, the proposal is clear. It sends a MP on the backchannel 
> triggering the client to respond with the MC to get the CS. *
> DUG: there is no back-channel to send it on. please show concrete 
> message flows to show how this works. *
>
> Anon replyTo means the only thing that can flow back on the current
> sockets is the GetQuoteResponse so how does the CS flow?
> Anon doesn't allow the GetQuoteResponse to flow back on any other
> socket than the one carrying the request. Some people argue that it
> can if we're in the error case (broken socket) and using RM, but what
> about the non-error case - socket is still there and waiting for a
> response? WSA rules would still need to apply. Or are we suggesting
> this proposal changes WSA processing rules?
>
> MG: If this is a true req/resp WSDL then how does the current spec 
> address this? That the server violate its own published contract at 
> its whim? I would argue that if you are expecting a reliable response 
> you need to establish the inbound sequence to handle it before you 
> invoke that operation. There isn’t a good way to handle the error case 
> otherwise. *
> DUG: current spec works just fine because we don't use the WSA anon 
> URI and we clearly define the semantics of the new URI. This proposal 
> violates WSA's definition of anonymous. Concrete message flows are 
> needed to prove that this works in your proposal.*
>
> - Places burden of creating new sequences on the wrong side.
> There are scenarios mentioned in this proposal where the RMD sends a
> MC to, in essence, ask for a CS to flow. This is quite a change to
> the current RM processing model where its the RMS that is always in
> control over when to create new Sequence. Also, this then leads to
> the question of how did the RMD know a new Sequence is needed?
>
> MG: In both proposals you have to poll with MC. *
> DUG: This isn't an answer. Your proposal says there are times when the 
> client wants a new Sequence for the inbound messages - how does it 
> know this? *
>
> - Client Identification
> Following on the previous comment, the proposal says:
> When an unreachable client requires a new inbound sequence it MAY
> send the MakeConnection header independently to RM service endpoint.
> Upon receipt of a MakeConnection header block that the RM Source
> cannot relate to an existing sequence it MUST respond with either
> a CreateSequence message on the protocol specific back channel
> of the request, or with a MakeConnectionRefused fault.
> How does the service know if a Sequence already exists? What unique
> info is there to compare?
>
> MG: If the MC previously returned identifying ref params it can 
> identify the sender. There is not an issue here. *
> DUG: This doesn't solve it. How does the MC return identifying ref-p's 
> that are specific to a sender when it has no idea if its seen a 
> particular sender before? There is nothing to distinguish one anon 
> client from another.*
>
> Since these MC's can be delayed in the
> network, its possible that many may be sent and thus lots of
> CreateSequences may flow - meaning lots of unused Sequences may be
> created. See next point.
>
> - Unnecessary Sequences/Message flows.
> Since we're talking about RM here we need to think about what happens
> in cases where messages are late to the party. In this proposal if a
> rogue MC is received and the AcksTo EPR it pointed to is for a terminated
> Sequence then a CS will flow back. This will cause an unused Sequence
> on both endpoints and cause the generation of unused MC's that will
> continually flow until the Sequence expires. And worse, what if the
> CS had an Offer - we then double the number of unused Sequences.
>
> MG: If the AcksTo is for a terminated seq then a fault can always be 
> returned. This is an implementation detail. *
> DUG: "Can"? Once a seq is terminate the state data may be gone - per 
> your proposal the RMD has no choice but to create a new sequence. 
> Again, this means that lots of unused sequences will be created unless 
> there's some special magic around that allows the RMD to know more 
> than what you're specified in your proposal. *
>
> - MP sent to unidentified client
> The proposal says that a MP can be sent on inbound traffic to the
> unreachable endpoint, but it doesn't link the MP header to the
> client or to the Sequence so how does the sender of the MP know
> whether or not any particular message can carry the MP header.
>
> MG: The MP can be related to the sequence of the RM message it is 
> piggy-backed on. *
> DUG: This doens't answer my question so again please show concrete 
> message flows to prove this works.*
>
> - MP & client id again
> The proposal says:
> In the circumstance where an RM Source wishes to initiate a sequence
> with an anonymous client, the RM Source MAY return a MessagePending
> header over an existing transport backchannel. The MessagePending
> header MAY contain an AcksTo EPR...
> How does the RMS know which anon client its talking to?
>
> MG: The MP can be related to the sequence of the RM message it is 
> piggy-backed on. *
> DUG: there is no sequence so this non-answer makes no sense. *
>
> Misc:
>
> Some pointers to old discussions:
> Discussion if i089 at Raleigh f2f:
> http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/17492/MinutesWSRX-f2f-032306.html#_Toc131830356 
>
>
> Old proposal for i089 but the word doc contains a lot of the rationale
> behind the thinking:
> http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200605/msg00123.html 
>
>
> Pointer to i010, which dealt with Sequences spanning multiple endpoints:
> http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i010
>
> thanks
> -Doug
>

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

http://bloglines.com/blog/paulfremantle
paul@wso2.com
(646) 290 8050

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