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] PR001 - Feedback on MSFT's MC proposal


Doug:

 

1 - saying we support anon by not using anon isn't a valid argument  :-)

 

In the context of your pulled shared-sequence use case, an “RM anon URI” is treated no differently than a regular EPR on the source side: it just identifies the client (not used as an actionable address). Someone on the source side, must know the uuid associated with each response. I still have the feeling that somehow we reinvented what WSA could do here ( couldn’t that RM anon URI have been mapped to an EPR + ref parameter? Or couldn’t  in general  this client ID info be carried by ref parameters ?).

Note that your use case should also work when the clients are addressable, in case we want so. Would we still need an RM anon URI to identify them in MC? (some of the clients may be addressable, some may not, and yet all may need use same sequence)

I do agree that Marc’s proposal does not show the details of this, but after all there seems to be several ways to do this – sounds to me like a good profiling opportunity, or a policy decision ;-)  

 

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

 

So the way things would work with current spec support, for the shared sequence:

- each anonymous-yet-identified client (of possibly dozens) takes responsibility for pulling (MC with RM anon URI) its own messages, via the same RMD. The MC call may fail to find a message for its client in the RMS, and then will either block (wait) or just return empty.

- if the MC gets a message in RMS, it will pull it, regardless whether this message is in order or not – the RMD will block it as long as needed to reorder (this certainly will create more entropy on RMD side than if messages were simply pulled in sequence order or close). This blocking will in turn likely cause an exception – the client will have to pull again later and this new MC would be blocked by the RMD (not go to the RMS) because the message is already there waiting in RMD, so the RMD will just return it on the back-channel.

 

That sounds extremely convoluted… (frankly, our implementers laughed at that). Why let all these “identified” MCs hit the RMS for their specific messages, which will generate significant traffic overhead and useless requests? If the clients should bother fetching their messages, such requests (MC or other) don’t have to go beyond the RMD: a simpler design would have the RMD just issue its own MCs (targeted to anything for this sequence) pull everything it can, then assign (in order) each message to Client’s requests based on  ID info that I’d leave out of scope.

Just saying that there are quite efficient ways to address this use case , other than yours, for which Marc’s proposal works.

                                                                                                                                         

-Jacques

 

 


From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Saturday, November 04, 2006 12:49 PM
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,
  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.

<JD>  I just do not see what is the benefit of  an MC controlled by the client in the shared sequence scenario you describe… In an ordered sequence, the RMS must assign numbers to messages in the order they are submitted by AS.


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 handl es 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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]