ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ws-rx] Issue 050
- From: Christopher B Ferris <chrisfer@us.ibm.com>
- To: tom@coastin.com
- Date: Thu, 10 Nov 2005 06:44:18 -0500
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]