Chris:
Your rewording would address the concern
(my point #2) - I know I may sound a bit obsessed by the precision of the
wording, but some implementations don't have to be insane to send out
messages in the wrong order... with multithreading you may loose control on
the order in which things happen. There are always odd cases beside the 95%
that are straightforward. (the 5% that might keep lawyers busy...) Precision
never hurts.
Regards,
Jacques
From: Christopher B
Ferris [mailto:chrisfer@us.ibm.com]
Sent: Thursday, November 10, 2005
3:44 AM
To: wsrx
Subject: RE: [ws-rx] Issue 050
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