RE: [ws-rx] PR001 - Feedback on MSFT's MC proposal

[Christopher B Ferris <chrisfer@us.ibm.com>]

Marc,

please see my comments inlined below.

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 377 9295

Marc Goodner <mgoodner@microsoft.com> wrote
on 11/01/2006 02:28:42 PM:

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

Not true. MC is consistent and composable with core
WS-A. It CR33 relates to the
WSDL binding, and as I understand it, the WS-A is
changing that. Thus, MC is 
neither broken nor incompatible with WS-A.

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

When was the decision to have another PR made? I certainly
don't recall that.
The OASIS process provides for the TC to determine,
based on the nature of
changes made as a result of incorporation of changes
related to PR feedback
and implementation experience, to either conduct another
PR or to simply advance
directly to CS. This is a decision that the TC still
needs to make unless I am
grievously mistaken.

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

What didn't work as designed?

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

How? You can't simply make this assertion without
backing it up with
concerete evidence that demonstrates how this can
be effected with
the proposal you are advocating.

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

No, both proposals do NOT require one MC per Sequence.
I don't know where you
got that from, but as currently specified, this is
certainly not the case. It is,
however, the case with the MSFT proposal.

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

Really? How is this consistent with WS-Addressing?
This seems to be a direct
violation of WS-Addressing SOAP binding which stipulates
that THE response
message MUST flow on the back-channel when the anon
URI is used.

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

+1 to Doug's point here.

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


Because we define our own URI. That URI has similar,
but not the same
semantic as WS-A anon. Similar in the sense that it
specifies that
the response message is to be delivered over a protocol
back-channel
for a connection that carries the same address URI
as the request
message.

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

Really? 

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

No, I think that you are missing Doug's point. In
your proposal, you have
a 1:1 relationship between an endpoint and a Sequence.
This is not the
case in the current spec. The fact that the CS messages
both flow over
the back-channel of a connection established with
a MC is orthogonal to the
issue that Doug raised, and for which your response
is non-responsive.

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

Actually, I disagree that this is merely an implementation
detail. You have
claimed repeatedly that the problem you have with
the current MC spec is that
it is unclear as to handling of all conditions. IMO,
you need to be explicit
in the handling of this case to ensure interop and
also to ensure that
there will be no orphaned Sequences resulting from
a common case of 
a late-to-the-party message.

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

Can be, and are are two different things. I think
that the proposal needs
to be more explicit in this regard. I think that you
are going to have to 
clarify the proposal to require or explicitly imply
such a relationship.

I would also point out that your response also indicates
that there can be
at most one Sequence active for a client. No such
constraint exists in the
spec today. We have worked to ensure that no such
a constraint exists. Now,
you are proposing that we incorporate such a constraint
with this proposal.
This certainly seems inconsistent.

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

Now I am confused. If the MP is related to the Sequence
of the message upon
which it is being carried, then how does this permit
the creation of a new
Sequence? Does it presume that the two are related?
I am very confused.

As with many of the responses, this is, IMO unresponsive
to the question.

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