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] i001 and Proposal


+1

I too see wsrm:Offer as merely an optimization. It should neither be 
required (when there
are req/resp operations in the WSDL) nor should it necessarily be 
disallowed (when there
are not).

I haven't double-checked the proposal to determine that the line numbers 
are correct, but
if they remove the constraints as above, then I completely concur.

There is a separate issue that I think needs clarification related to 
wsrm:Offer, that I will
post separately, that has to do with what obligation the RMD that accepts 
an Offer has
with regards to its use.

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

"Lei Jin" <ljin@bea.com> wrote on 08/25/2005 01:29:56 PM:

> I'm restating issue 001 to provide more details.
> 
> Title: Bilateral sequence negotiation
> 
> Description: The current draft of the WS-ReliableMessaging specification
> defines the wsrm:Offer element as follows: "This element, if present,
> enables an RM source to offer a corresponding Sequence for the reliable
> exchange of messages transmitted from RM destination to RM source".  As
> per the text above, the spec does not constrain what messages an offered
> sequence can be used to send, nor does it define when an offer element
> must or must not be present. 
> 
> However, WSRX-ReliableMessagingPolicy document, lines 221-226, states
> that an offer element must be present if and only if the endpoint
> declares output messages.
> 
> "Per WS-ReliableMessaging [WS-RM], a wsrm:CreateSequence request MAY
> contain an offer to create an "inbound" Sequence. If the RM policy
> assertion is attached to an endpoint declaring only input messages, the
> endpoint MUST reject a wsrm:CreateSequence request containing a
> wsrm:Offer to create a corresponding Sequence. If the assertion is
> attached to an endpoint declaring both input and output messages, the
> endpoint MUST reject a wsrm:CreateSequence request that does not contain
> a wsrm:Offer to create a corresponding Sequence."
> 
> IMO, an offer is an optimization to allow a reverse reliable sequence to
> be set up without going through the whole CreateSequence handshake.
> Thus, this limitation in the policy documents seems to be unnecessary.
> 
> Justification: There are cases when I need to send reliable messages to
> an endpoint, but I don't require responses to be sent back reliably.
> (see i021)  In that case, requiring an offer is unnecessary.  There are
> also cases when the destination endpoint doesn't declare output
> messages, but needs to send messages reliably to the source endpoint in
> other types of MEP (eg: oneway, callback MEP).  In that case, having an
> offer is a useful optimization.
> 
> Related Issues: i021
> 
> Origin: Lei Jin
> 
> Owner: Lei Jin
> 
> Proposal:
> 
> Delete lines 221-226 of WSRX-ReliableMessagingPolicy document.



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