ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: PR001 - Feedback on MSFT's MC proposal
- From: Doug Davis <dug@us.ibm.com>
- To: ws-rx@lists.oasis-open.org
- Date: Thu, 26 Oct 2006 11:57:04 -0400
Per my todo, here's feedback on the MSFT proposal
for PR001 which
also has the various use-cases interspersed.
Metacomments:
- Current solution in spec is not broken nor incompatible
with WSA
- This proposal will force a new PR review and Interop
- This proposal does not address any new features
or use-cases
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.
- 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.
- 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.
- 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.
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.
- 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.
- 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.
- 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.
- 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.
- 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
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?
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?
- 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?
- 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? 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.
- 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.
- 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?
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]