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