Re: [ws-rx] Issue 050

[Tom Rutt <tom@coastin.com>]

Doug Davis wrote:

>
> Just to add to this...you don't even need a new endpoint - you could 
> just use a new sequence to the same endpoint as well if you don't want 
> messages (targeted to different operations) to interfere with each other.
> thanks
> -Doug

that is exactly what I would like to happen. However, there needs to be 
some mechanism for asserting what DA level is associated with each of the
sequences terminating at that endpoint. The RMD needs to know which 
sequence is ordered delivery, and which sequence is not ordered delivery 
(for my example of one sequence with exactly once ordered - the other 
with exactly once not ordered).

Tom Rutt

>
>
>
> *Christopher B Ferris/Waltham/IBM@IBMUS*
>
> 11/10/2005 06:44 AM
>
> 	
> To
> 	tom@coastin.com
> cc
> 	Duane Nickull <dnickull@adobe.com>, wsrx <ws-rx@lists.oasis-open.org>
> Subject
> 	Re: [ws-rx] Issue 050
>
>
>
> 	
>
>
>
>
>
>
> You can separate out the operation requiring different QoS into a 
> separate endpoint
> such that it will get a different Sequence with its own DA.
>
> 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
>
> Tom Rutt <tom@coastin.com> wrote on 11/10/2005 02:06:35 AM:
>
> > 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
> >
> >



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