[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]