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 060 ammendment to current proposal


Jacques:

I may be reading the wrong (rev 07 dated 12/05/2005) but I see it defined differently:

Line 174 defines "Deliver" as "The act of transferring a message from the RM Destination to the Application Destination."  To me, this creates the inference of a specific infrastructure, even given the abstract nature of the model.  Perhaps if they stay in the spec, we must strive to be much clearer on what is meant.

Duane


*******************************
Adobe Systems, Inc. - http://www.adobe.com
Vice Chair - UN/CEFACT  http://www.uncefact.org/
Chair - OASIS SOA Reference Model Technical Committee
Personal Blog - http://technoracle.blogspot.com/
******************************* 

________________________________________
From: Jacques Durand [mailto:JDurand@us.fujitsu.com] 
Sent: Thursday, December 08, 2005 11:04 AM
To: Duane Nickull; Gilbert Pilz; Patil, Sanjay; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] Issue 060 ammendment to current proposal

Duane:

I find it hard to be clearer than and more general than the way this DA is defined currently:
"Messages will be delivered in the order that they were sent." The operations "deliver" and "send" are well identified abstract ops in the < AS, RMS, RMD, AD > model, as we need to give  them precise semantics. Yet there is ample room for interpreting them anyway you like: you may decide that "deliver" is put-in-queue, or is "act-upon". Your choice. All we say is that a conforming implementation must fulfill this contract for whatever interpretation has been chosen.

Now, the use of the numbering allows for splitting InOrder DA  into separate contracts that must each be enforced for the overall contract to work:
- Source side: RMS is numbering in same order as AS is sending. (e.g. an invariant to be added to spec)
- Destination side: RMD delivers to AD in same order as sequence numbers.

Do you see any use case that falls out of the (AS, RMS, RMD, AD ) model? I find it abstract enough to cover all we need. More abstract than this and the semantics gets fuzzy... more concrete than that and we step into implementation peculiarities.

Jacques
________________________________________
From: Duane Nickull [mailto:dnickull@adobe.com] 
Sent: Thursday, December 08, 2005 10:20 AM
To: Gilbert Pilz; Jacques Durand; Patil, Sanjay; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] Issue 060 ammendment to current proposal

I hate to be a fly on the ointment, but the very notion of "delivered" in order infers that every service which adheres to this protocol must have a specific architecture whereby a service passes incoming messages to another application and/or the message sent come from another application other than the RMS, presumably that either is on a different network node.  Is it not possible that what we really mean is [ handled || processed || acted upon ] in the order intended by the message source" or perhaps even the more vague 

"that the reliable message destination can re-create the message stream exactly (inferring the sequence tokens are present) as it was when it left the message sender, spanning multiple messages in one exchange"?

Honestly, if we are creating a specification that will withstand the scrutiny of our peers and the tests of time, we may wish to be a bit more precise WRT the wording of this.  The patterns of AS, RMS, RMD, AD is valid in a lot of cases, but should not be mandatory in all cases.

Sorry to sound like a broken record.

Duane





*******************************
Adobe Systems, Inc. - http://www.adobe.com
Vice Chair - UN/CEFACT  http://www.uncefact.org/
Chair - OASIS SOA Reference Model Technical Committee
Personal Blog - http://technoracle.blogspot.com/
******************************* 

________________________________________
From: Gilbert Pilz [mailto:Gilbert.Pilz@bea.com] 
Sent: Wednesday, December 07, 2005 9:16 PM
To: Jacques Durand; Patil, Sanjay; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] Issue 060 ammendment to current proposal

Yeah. What he said . . . .
 
- g

________________________________________
From: Jacques Durand [mailto:JDurand@us.fujitsu.com] 
Sent: Wednesday, December 07, 2005 5:00 PM
To: Gilbert Pilz; Patil, Sanjay; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] Issue 060 ammendment to current proposal
Adding to the wordsmithing, I think the numbering must be scoped by the sequence, yet without the AS knowing it.
it might help to clearly separate these two requirements:
(1) numbers for a sequence must be assigned by RMS in an incremental way (by increment of 1) over time, 
(2) the numbering must reflect the sending order from AS. (I anticipate here on my most recent "new issue" which I expect will not be controversial)

How about the Invariant: 
The RM Source MUST assign message numbers (defined below) to each message to be delivered reliably beginning at 1 for a new sequence and increasing by exactly 1 for the next assignment within the sequence. Within a sequence, these numbers MUST be assigned in the same order in which messages are sent by the Application Source.

Other parts of my amendment (L78, L168, L454) are intended to align with removal of "reliable message" and usage of "reliable delivery" instead.

Jacques

________________________________________
From: Gilbert Pilz [mailto:Gilbert.Pilz@bea.com] 
Sent: Wednesday, December 07, 2005 1:19 PM
To: Patil, Sanjay; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] Issue 060 ammendment to current proposal

This seems to be both redundant and potentially confusing. At this point in the document we are referring to "the protocol" in an abstract sense. The introductory sentence states "During the lifetime of the protocol . . ". A Sequence is a lower level construct for managing the lifetime of "the protocol". The AS and AD need not (and possibly "should not") have any knowledge of the Sequence.
 
- g

________________________________________
From: Patil, Sanjay [mailto:sanjay.patil@sap.com] 
Sent: Wednesday, December 07, 2005 12:52 PM
To: Gilbert Pilz; ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] Issue 060 ammendment to current proposal
 
On a side note, I think the Sequence scoping of the message numbers should be clear from this invariant.
 
How about:
Replace "For each message that is to be delivered reliably ..."
with "In a Sequence, for each message that is to be delivered reliably ..."
 
Thanks,
Sanjay

________________________________________
From: Gilbert Pilz [mailto:Gilbert.Pilz@bea.com] 
Sent: Wednesday, Dec 07, 2005 12:39 PM
To: ws-rx@lists.oasis-open.org
Subject: [ws-rx] Issue 060 ammendment to current proposal
The motion currently on the table is to change first invariant under section 2.3 to:
 
The RM Source MUST assign each message to be delivered reliably a message number (defined below) beginning at 1 and increasing by exactly 1 for each subsequent message to be delivered reliably.
 
In http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200511/msg00152.html Chris made the following suggestion for the same text.
 
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.
 
The intent is to tighten up the contract between the AS and RMS with regards to message numbering.
 
I would like to combine the two proposals into the following:
 
For each message that is to be delivered reliably, the RM Source MUST assign 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 message sent by the Application Source.
 
- g


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