OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]