Re: [ws-rx] Issue 050

[Tom Rutt <tom@coastin.com>]

Duane Nickull wrote:
My comments in line

> 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.
>
There is one point which I would like to re-assert at this time.

The sender may in many cases care whether there is a delay associated 
with in-order exactly once delivery DA being present.

If we go with the " give the destination endpoint the most stringent DA 
across its operations" approach, the sender can be
stuck with a behavour which they do not wish to accept. If an operation 
does not require ordering, it should not be delayed due to a missing prior.

My point regards behaviour expected by the sender when a particular DA 
is in use at the sender, regardless of whether the protocol does not 
depend on the DA level in use.

Tom Rutt

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


-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133