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
- From: Doug Davis <dug@us.ibm.com>
- To: "Durand, Jacques R." <JDurand@us.fujitsu.com>
- Date: Mon, 6 Nov 2006 22:51:26 -0700
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]