Re: [ws-rx] NEW ISSUE: Inefficient close/terminate of offered sequences

[Christopher B Ferris <chrisfer@us.ibm.com>]

I don't like CS/Offer because I consider
it a premature optimization, and I like TS/Offer even less
for largely the same reasons. I really
don't understand why people get all excited about
an extra message exchange. All this
does is add complexity to the protocol for what I would
consider an insignificant gain.

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295

paul@wso2.com wrote on 05/16/2006 05:44:20 PM:

> Description:
> Currently the spec allows one side to optimise creation of two sequences
> using the Offer. However, to close and/or terminate a pair of sequences
> requires a pair of request-response operations.
> To properly initiate and terminate a two-way reliable messaging exchange
> therefore has an overhead of 3 extra message exchanges (Create+Offer,
> TermSeq outbound, TermSeq inbound). A simple improvement is to allow
the
> client to optionally close and/or terminate the offered sequence at
the
> same time as the outbound sequence. Note this is not attempting to
tie the
> two sequences together. It is an option to leave the offered sequence
> open. The attached sequence diagram shows the overhead when a single
> req-resp is used.
> 
> Target: core
> 
> Type: design
> 
> Proposal:
> 
> Based on WD12
> 
> At line 446 add:
> <wsrm:Offer><wsrm:Identifier>xs:anyURI</wsrm:Identifier>...</wsrm:Offer>?
> 
> At line 484 add:
> /wsrm:TerminateSequence/wsrm:Offer
> This element, if present, enables the RM Source to signal that it
is
> terminating an 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.
> 
> /wsrm:TerminateSequence/wsrm:Offer/wsrm:Identifier
> This REQUIRED element MUST contain an absolute URI conformant with
RFC3986
> [URI] that uniquely identifies the offered Sequence that is to be
> terminated.
> 
> /wsrm:TerminateSequence/wsrm:Offer/{any}
> This is an extensibility mechanism to allow different (extensible)
types
> of information, based on a schema,
> to be passed.
> 
> /wsrm:TerminateSequence/wsrm:Offer/@{any}
> This is an extensibility mechanism to allow additional attributes,
based
> on schemas, to be added to the
> element.
> 
> 
> At end line 492 insert:
> 
> 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.
> 
> After line 405 insert:
> 
> /wsrm:CloseSequence/wsrm:Offer
> This element, if present, enables the RM Source to signal that it
is
> closing an Offered Sequence. This MUST only be used to close a sequence
> that was established through <wsrm:Offer>. A final SequenceAcknowledgement
> header for the Offered Sequence MUST be included with this message.
> 
> /wsrm:CloseSequence/wsrm:Offer/wsrm:Identifier
> This REQUIRED element MUST contain an absolute URI conformant with
RFC3986
> [URI] that uniquely identifies the offered Sequence that is to be
> terminated.
> 
> /wsrm:CloseSequence/wsrm:Offer/{any}
> This is an extensibility mechanism to allow different (extensible)
types
> of information, based on a schema,
> to be passed.
> 
> /wsrm:CloseSequence/wsrm:Offer/@{any}
> This is an extensibility mechanism to allow additional attributes,
based
> on schemas, to be added to the
> element.
> 
> After line 435 insert:
> 
> A CloseSequenceResponse message sent in response to a message containing
> wsrm:CloseSequence/wsrm:Offer shall be taken to indicate that the
RM
> Destination has received the signal that the Offered Sequence is 
> closed.[attachment "twowayoverhead.PNG" deleted by Christopher
B 
> Ferris/Waltham/IBM]