Doug – it looks like we could spend
a long time beating this use case to death…
I still am not convinced this ordered-pulled-shared-sequence
case can’t be dealt with as well if not better with the pulling
controlled by the RMD, while satisfying other requirements.
It appears Gil has posted some comparison
that may provide a broader benchmark than this particular use case, so willing
to look into it for now.
(also distracted by election night ;-)
-Jacques
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Monday, November 06, 2006
9:51 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,
comments inline.
-Doug
"Durand, Jacques R."
<JDurand@us.fujitsu.com>
11/06/2006 11:49 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:
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. <dug> No, they just know what
URI each message is targeted to - just like normal URIs </dug> 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 ?). <dug> not without the source having
to violate EPR opacity </dug>
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) <dug> sure why not - and that's a
good thing </dug>
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. <dug>
the phrase "same RMD" can be misleading because it implies one
physical one and it need to be thought of as a virtual one. There could
be multiple endpoints behind a single virtual RMD </dug> 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. <dug> which is no different
than the async world - if a response is never sent (asynchronously) to an
endpoint waiting for a response it will either block or return an empty
response </dug>
- 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). <dug> I don't think you're
following. Think about what happens in the pure async case - if response
number N is sent asyncrhonously to an endpoint but message number N-1 is never
sent for some reason then the receiver of message N MUST block the delivery of
that message (if we're doing InOrder) this is normal RM stuff - anon endpoint
should be no different </dug> 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. <dug> If I understand what you're
saying... no. The MC should never block - if there are no messages
waiting to be sent then it just returns a 202 type of response. I feel
like you're trying to make it harder than it really is </dug>
That sounds extremely convoluted… (frankly, our
implementers laughed at that). <dug> If they laughed then they either
don't understand MC (and we may need to add clarifying text to the spec) or
they don't understand how things would work in the async cases either because
its basically the same logic - and I think they need to understand how they
works before they look at the anon cases</dug> Why let all these “identified” MCs hit the RMS for
their specific messages, which will generate significant traffic overhead and
useless requests?
<dug> this is just the nature of a polling solution - if people don't
want to poll then setup an listener and go to the async model </dug> 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.
<dug> I still think
you're missing the point. Not everyone can live with the constraints of
Marc's proposal -even if it did work as advertised. If there is only one
endpoint behind a sequence then everything can work just as you've described -
one MC is sent from one anon endpoint. But what's nice about the current
spec is that it also allow for a more flexible environment. </dug>
-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