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] NEW ISSUE: Inefficient close/terminate of offered sequences


Doug

Thanks for the review. Comments below.
> Paul,
>
> A few questions...

> What prevents an RMS or RMD putting 2 close or terminate sequence
> requests in the same message?  Each exchange is carefully identified and
> may be handled separately without conflict.

I guess it would be just the same as the original Offer - just an aspect
of the schema and the definition. It seems simplest to me to restrict this
to closing a single Offered sequence.
>> This MUST only be used to terminate a
>> sequence that was established through <wsrm:Offer>. It is RECOMMENDED
>> that
>> a final SequenceAcknowledgement header for the Offered Sequence is
>> included with this message.
>>
> The MUST doesn't require that Offer be used to close a sequence opened
> as part of the same create sequence exchange.  Was that intentional?

Not really. We could restrict it further, but it didn't seem necessary to
me. After all either side can terminate a sequence at any time, and the
RMD doesn't usually inform the RMS. Would you prefer this if it was
restricted further? I guess that would require the server to maintain a
link between the main sequence and the offered sequence in order to
validate the client's request.

>
> The RECOMMENDED seems a higher bar than set in the regular termination
> exchange.  Why is a sequence acknowledgement needed in this case but not
> the regular one?

I agree this is a higher bar. Usually a TS flows from the RMS to the RMD,
and the RMS has had the opportunity to get a full set of acks and "knows"
the sequence is complete. However, in this case its the client's RMD that
is terminating the sequence, so the server's RMS may not have recently
requested an acknowledgement, and so might be in doubt as to the state. So
this seemed like a useful recommendation.

>
> i093 crops up again in your proposed changes, though more below than in
> this first section.  Don't personify elements or attributes.  Instead,
> state what the RMS and / or RMD MUST / MAY / SHOULD do.

Good point. I did review it but obviously not thoroughly enough! I'll add
it to this weeks agenda.

>> A TerminateSequenceResponse message sent in response to a message
>> containing wsrm:TerminateSequence/wsrm:Offer shall be taken to indicate
>> that the RM Destination has received the signal that the Offered
>> Sequence
>> is terminated.
>>
> How does an RMD fault the offer but not the "main" sequence identified
> in the terminate sequence request?  Visa versa?

The way I thought of it was that this is terminating the Client RMD's
sequence, and this is really "informational". An RMD can terminate a
sequence at any point and the sequence should be terminated irrespective
of whether the Server RMS successfully processes the message. The aim here
is simply to let the Server RMS know that the sequence is terminated and
save having to send its own TS.

So any faults returned should be for the main sequence.

>> After line 405 insert:
>>
> Why are we moving through the document in this order?

Because my brain works backwards. Its the just the order I addressed it in.

Thanks,
Paul


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