RE: [ws-rx] Issue 050

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

Jacques,

The protocol clearly supports in-order
by virtue of the MessageNumber. I certainly hope that is not at issue.
In fact, I would argue to the contrary.
Because the protocol requires that each message be assigned
a monotonically increasing (from 1 by
1) MessageNumber on each message in a Sequence, the
RMS need not be aware, unless you are
suggesting that an implementation might randomly assign
MessageNumbers.

I would argue that unless the RMS were
implemented by an insane person, that this would not
be an issue. Are you suggesting that
the RMS will behave differently in assigning message numbers
based on whether InOrder is in effect
between the RMD/AD? It shouldn't. In fact, I would assert that
it must not.

The spec reads in section 2.3:

        "During
the lifetime of the protocol, two invariants are REQUIRED for correctness:
        ·
The RM Source MUST assign each reliable message a sequence number (defined
below)
        beginning
at 1 and increasing by exactly 1 for each subsequent reliable message."

Now, reading this, I realize that we
could tighten this up to make this invariant more precise:

        During
the lifetime of a Sequence, two invariants are REQUIRED for correctness:
        ·
The RM Source MUST assign each reliable message in the Sequence a message
number (defined below)
        beginning
at 1 for the first message sent by the Application Source and increasing
by exactly 1 for each 
        subsequent
reliable message sent by the Application Source.

Note to editors, the second bullet in
section 2.3 is styled as a paragraph instead of a bullet item. The
sentence that begins "Every acknowledgement
..." should be the second invariant and styled as a bullet.

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295

Jacques Durand <JDurand@us.fujitsu.com> wrote
on 11/10/2005 02:14:09 AM:

> Duane:
> None of what you say seems to invalidate my points
which only state 
> very precise facts :
>  
> 1. The DAs as described in our charter are not
only different from 
> those defined in WS-RM spec, but at least 2 of them are meaningless
> given the vagueness of "transferred".  This confirms
my opinion that
> a charter is good at scoping the work but is no substitute for 
> definitions that belong to a detailed spec. Now if we are to remove
> any other mention of DA beside those in the charter, then allow me
a
> naïve question: "what is it that our protocol is trying to support
exactly?"
> 2. InOrder (as defined in WS-RM spec) requires
two conditions in 
> addition to the use of the protocol: (a) messages are numbered by
> RMS in same order they are submitted ("sent"), (b) messages
are 
> delivered by RMD in same order as they are numbered. Just saying 
> this, no more no less. You can make of (a) an invariant of RMS 
> behavior if you like, so that the Source side does not have to be
> aware of this DA - fine. But if that is not stated as part of the
> "protocol" spec, then RMS must be made aware of this DA.
>  
> Jacques
>  
> 
> From: Duane Nickull [mailto:dnickull@adobe.com] 
> Sent: Wednesday, November 09, 2005 1:49 PM
> To: wsrx
> Subject: RE: [ws-rx] Issue 050
>  
> Jacques:
>  
> My $0.02 worth on this topic is that all we can
really do in this 
> spec is to ensure that the RMS's understanding of the ordering of
> messages (as intended by the AS) is conveyed to the RMD.  Anything
> else is either out of scope or worse, violates opacity, one of the
> core tenets of SOA and WS.  There are several assumptions that
have 
> to be made in this, but the mechanics of which cannot be placed in
the spec. 
>  
> 1. That the AS will accurately convey the proper
information to the 
> RMS.  We should not attempt to specify any messages or mechanisms
to do that.
>  
> 2. The RMD will receive and be able to reconstruct
the streams as 
> they left the RMS or in the alternative, throw a fault.  This
must 
> be fail proof. Due to the semantics described in our spec, the RMD
> will be able to understand the ordering/delivery intentions of the
> RMS (which we must assume is in alignment with the AS).  The
RMD 
> does not see or care about the RMS- AS relationship.
>  
> 3. The RMD is able to convey the "ordering
intentions" of the RMS to
> the AD (based on the fact that we have a mechanism in the WS-RX 
> protocol to convey it).  We should not specify any 
> mechanics/encodings for this including whether or not messages are
> delivered in order (our charter forbids this).  What really matters
> is that the AD has access to the intentions.   If we word this
as 
> "messages are transferred in order..", that IS a mechanism
from RMD 
> to AD and violates our charter.  
>  
> Accordingly, a runtime DA is not really needed.
  Chris Ferris and I
> (and others) have been trying to explain this, perhaps poorly.  We
> have to assume that both the AS-RMS and RMD-AD relationships are 
> sound but not try to assume any specific details.  It really
doesn't
> matter since if the intentions of the service as a whole are not 
> met, the invocation should fail.
>  
> Chris states:
>  
> "As I have tried, apparently unsuccessfully,
in the past to 
> explain... regardless of the DA 
> in force, in effect or observed at the RMD, the source CAN ONLY know
> which messages have 
> been received. It can make NO assumptions (unless it wants to 
> succumb to the Felix Unger 
> ass-u-me adage) as to which messages have been or ever will be 
> "delivered" to the AD."
>  
> Any wording such as "...Messages are "transferred"
in order..." 
> specifies an assumption of a specific mechanism behind a service 
> boundary, something which I do not like.  We should not constrain
> all applications to serial processing only based on message 
> reception events.  Many, including myself, would probably prefer
to 
> architect serial processing of the message payloads, but not 
> constrain that they have to be actually delivered in serial order.
 
> This is a bad practice as it creates an unnecessary dependency on
> the base transport routing between RMD and AD and also adds a 
> requirement for some form of RM behind the service to detect out of
> order messages.  A far more elegant solution would be for the
RMD to
> convey the ordering information to the AD, deliver the messages in
> whatever sequence it likes and let the AD use that information to
do
> its' job or processing them correctly.  We should assume that
people
> implementing this are not idiots and will take proper precautions
in
> the manner they feel is best and not constrain behavior behind firewalls.
>  
> Duane
> 
> From: Jacques Durand [mailto:JDurand@us.fujitsu.com] 
> Sent: Tuesday, November 08, 2005 7:05 PM
> To: Duane Nickull; Yalcinalp, Umit; wsrx
> Subject: RE: [ws-rx] Issue 050
>  
> (assuming this is the right thread for this...
can't say I am as 
> lazy as some Canadians for an excuse ;-)
>  
> As far as I can tell, there are two proposals
on the table for i050:
> both consist of removing DAs from "this" protocol specification,
yet
> they are very different:
>  
> 1-       Proposal currently logged
with the issue def: DAs are 
> simply moved to another document(s):
>  
> (a)     Remove all references to delivery
assurances from the WS-RM spec
> (b) Describe, in detail, DA's in the policy spec
(since we're adding
> an Assurances element to that document anyway).
> (c ) Create a new deliverable for the TC; a profiles
document. The 
> profiles would describe how the protocol should be used to implement
> the various delivery assurances
>  
>  
> 2-       The one informally proposed
in October discussions:
> That any mention of DAs be removed altogether
from any doc produced 
> by this TC (if I interpret well) 
>              
          
> I would consider (2) only if I were convinced
that the protocol 
> specification *really* supports the DAs that we are after all 
> chartered to support, and if these DAs were defined in an 
> unambiguous way for a starter. Two examples of why I think it is 
> premature to shut down any talk on DA at this stage:
>  
> - I note that InOrder is defined differently
in our charter ("
> Messages are transferred in the order in which they are sent")
 and 
> in our draft ("..delivered in the order in which they are sent").
I 
> do not consider a charter a precise-enough doc to look for an 
> accurate definition of what we really are supposed to enable in a
> final spec. DAs have to be more accurately defined somewhere else.
>  
> - at this time I'm not convinced that InOrder
will work if defined 
> as purely an RMD/AD contract. For this to work out, more needs to
be
> done, e.g. there must be a requirement (today absent) for the RMS
to
> assign sequence numbers to messages in the order they have been 
> submitted (sent), which is an obvious precondition for the order to
> be restored on destination side (hint: that looks to me like an 
> AS/RMS contract...).
>  
>  
> Jacques
>  
> 
> From: Duane Nickull [mailto:dnickull@adobe.com] 
> Sent: Friday, November 04, 2005 4:48 PM
> To: Yalcinalp, Umit; wsrx
> Subject: RE: [ws-rx] Issue 050
>  
> Pure laziness.  Rather than make a new email
I simply copied an 
> existing one and replied.  While I changed the thread subject,
I did
> neglect to delete the existing text in the body. It is gone now.
> Most Canadian are lazy.  I am no exception.
What can I say ;-)
>  
> May I ask why you not support the first proposed
resolution?  I 
> would be interested in hearing a counter argument for keeping it.
>  
> Thanks
>  
> Duane 
>  
>  
> 
> From: Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com] 
> Sent: Friday, November 04, 2005 4:18 PM
> To: Duane Nickull; wsrx
> Subject: RE: [ws-rx] Issue 050
>  
>  I am not sure why this is put forward in
this thread, but 
>  
> A big -1. 
>  
> --umit
>  
>  
> 
> From: Duane Nickull [mailto:dnickull@adobe.com] 
> Sent: Friday, Nov 04, 2005 10:27 AM
> To: wsrx
> Subject: RE: [ws-rx] Issue 050
> After more contemplation, I would like to suggest
we accept Marc's 
> proposal #1 WRT 050.  Remove all DA's from the spec.
>  
> Duane