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.
- 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.
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.
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.
- 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.
- 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.
- 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.
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?
- 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.
- 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.
- 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.
- 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.
- 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.
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.
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.
- 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.
- 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.
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.
- 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.
- 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.
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