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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

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


Subject: RE: [wsrm] Rel 82


I would try to avoid faulting such cases...
If we push a proposal where any group-level semantics does not need be repeated in all messages
but only be determined unambiguously by - ideally - the first message of the group,
we must handle the cases where the first ("start") message is lost, or is not the first to be received.
We could do:
 
- when the group is "ordered" (and therefore acks are sent back) the Sender must keep repeating
[identical] group info in each message until it receives first ack.
Receiver would take first  received "group info" as the decisive one.
Any different or absent "group info" will be ignored by receiver after this.
 
 - when group is unordered, and not even with guaranteed delivery, the Ack can't be used.
Receiver still behaves like above:
if the first , or few first messages of a group have not been received yet but say message N is received first,
then Receiver would take first  received "group info" (here in  mesg(N)) as the decisive one.
 If none is there, Receiver would default on some general parameter, e.g. for max duration of the group.
If no group info and no parameter, in last resort, a fault would be sent back so the Sender is reminded to insert group info
in its next message (note that receiver can still correctly process previous messages... group "attributes"
like removeAfter do not need be known right away)
 
Nothing prevents of course a Sender to repeat "group info" in every message. But even so, the spec should be clear as
how to treat possible discrepancies or changes within a group.
 
In spite of the elaborate "rules" above,  I believe things would be much simpler implementation-wise if we decide to treat
all messages of a group the same way w/r to reliability features (G.Ordering, DE, GD), as well as other parameters,
and that could be determined by what is in first received message of the group.
 
Jacques
-----Original Message-----
From: John Fuller [mailto:jfuller@wernervas.com]
Sent: Wednesday, October 15, 2003 5:57 AM
To: Jacques Durand
Cc: 'wsrm@lists.oasis-open.org'
Subject: Re: [wsrm] Rel 82

If the first received message in the group is not the "start" message do we just fault then?


On Tuesday, October 14, 2003, at 07:57 PM, Jacques Durand wrote:


John: inline.


-----Original Message-----

From: John Fuller [mailto:jfuller@wernervas.com]

Sent: Tuesday, October 14, 2003 4:25 PM

To: 'wsrm@lists.oasis-open.org'

Subject: [wsrm] Rel 82



82

The original document was difficult to work from as far as how to deal

with conceivably different

values for the optional group removeAfter attribute for messages in the

same group.

For example, most recent message's value could take precedence, or the

maximum or minimum value

could win. 


<JD> There is a more general issue that you raise here: when the semantics

of some value (header element or attribute) is about the entire group,

not just about the individual message that carries it, we only

need -in theory- to pick these values from the first message of a group.

So a bold way to address the possible "contradiction" issue across messages

of the same group is to pick the values of the first message(s) of the group,

and ignore what the other messages say about it.

We have the case also with "MessageOrder" element: if it is in the 1st

message of a group, I'd say the entire group is ordered... regardless

of whether it is or not in following messages.

Any "dynamic" readjustment or exception within a group, would be

confusing and make implemenations more complex.



Rel 57 clarified that the most recent timeout takes

precedence, though I don't believe

it's in the original specification.


<JD> I think the spec did not restrict what kind of ExpiryTime

each messages of a same (ordered) group, should have/not, so we

are allowed to consider any possible sequence of ExpiryTime values.

(note this is a message-level value , not group-level, so several

messages could not conflict with each other here).

We take the "earliest" of all ExpiryTime, which may come frm any message

in the broken sequence...



Maximum idle time also seems legitimate, but it would be helpful to

clarify which parameters

take precedence over which when in conflict, and explicitly that the

last group values

overwrite previous assumptions, and if null values indicate default to

service-level parameters

or default to previous parameters in the group if any?


<JD>, yes, we need to state some general rule for group-level values.

I'd propose that unless we accept the trouble of allowing group-level

parameters to change mid-way or have exceptions

 (e.g. removeAfter be re-adjusted during a group),

the initial value is the good one.




I think it would be good to have service-level default

parameters/policies for cases where

the header doesn't contain the parameters.


<JD> Agree some "configuration" values/parameters should have a standalone

existence, as it would be contrived to put them in headers just to be able to

talk about them... Such parameters don't have to be described as RMP parameters

(implementation level), but rather as part of the RM agreement between two parties.

Even so, I believe we can keep referring to them in an "abstract" way

(no need to come-up with an XML schema)


To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.




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