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). I believe that they could still be
given a regular EPR (not an RM anon) 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).
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”.
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). 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), 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 handles its own connections.
(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.
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.
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