[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] Proposal to resolve Issue 006 - refined argument
Anish Karmarkar wrote: > Tom Rutt wrote: > >> Description >> >> Is there a requirement that the sender can assert that >> the receiver must >> deliver a particular reliability assurance on a given >> sequence? >> >> Discussion It has been agreed that the protocol is the same >> on any ws -rm Sequence, regardless of DA level agreements in place >> between RMD and Destination Application. There is no need to have >> a standard protocol mechanism for the RMS to signal DA requirments on >> the sequence for the RMD. >> >> If reliaiblity policy is attached to a destination endpoint at a >> finer level of granularity than endpoint subject level, an >> implementaton (extension beyond normal conformance) would have to use >> means outside the scope of this standard to convey such requirements >> (e.g., RMD could be aware of the wsdl description). >> > > I don't see this issue as being tied to finer level of granularity. > Say the granularity is at the message-level or operation-level. When > the receiver receives a message, it is clear from the message which > operation is being invoked. > > The issue is about -- how does a sender indicate to the receiver that > a particular QoS is required for a particular Sequence? This may be > needed because the receiver supports multiple QoS and the sender wants > to choose OR the sender is not aware of the QoS being implemented and > wants to assert the QoS for the Sequence (and have the receiver fault > on the CS message if it cannot). > > One way I can think of doing this is to include the > wsrm:DeliveryAssertion (as defined by the resolution of issue i009) as > an optional element in the CreateSequence message and define a > specific fault that the RMD can send when the wsrm:DeliveryAssertion > is not supported/allowed. > > -Anish > -- > I beleive that such a negotiation mechanism is the best way to handle multiple levels of DA on the same endpoint. My point is either we have this negotiation level, and support operation level DA at the destination, or we support only endpoint level DA attachemnt at the destination without the sender negotiation. Knowing what is invoked is not the problem. The problem is that it is impossible for the RMD to know what the operation type of a missing message in a sequence is. As I already stated in my response to Marc G: Say one operation type (opA) on the port only needs at most once, while the other (opB) needs exactly once in order DA. Only obB needs to have its messages buffered, while waiting for a prior. if both operations are send over the same sequence, the opA request messages will be in the same sequence as the opB request messages. If a obB message number 101 is received by the rmd, and message 100 was not yet received, that message 101 must be held waiting for 100 to be delivered before 101 is delivered. Now suppose message 102 is a request for opA, it does not require ordered delivery, and if it were on a sequence which did not have ordered delivery DA in place it would be delivered immediately. Now, according to the comment from Anish, if the rmd knows the operation level DA requirements it could deliver the request message 102 immediately, since it can detect opA signature in the soap body. However message 101 will be held until message 100 is received, even though message 100 is a request for opA. So I stand corrected, in that the problem is less severe than I thought, given the RMD has knowledge of the operation type and the operation level requirements. One important point remains: placing all opA requests on one sequence which is negotiated at creation to support At least once at the RMS/RA agreement, and placing all opB requests on another sequence which is negotiated to support exactly once in order, simplifies greatly the implementation of the RMD. It would not have to know the operation type to do its job. My own position is that endpoint policy attachment for WSRM should be the default, with finer grained attachment an extension point. This default mechanism would not require negotation of DA on a sequence at creation time,. or RMD awareness of operation level requirements Users of the extension point would have to also define how the rms determines which operation types to put on each of multiple concurrent sequences between the rms and rmd, and which sequence has which DA level at destination. >> Proposed resolution to Issue 006: >> >> close issue with no changes to specfication. >> >> > -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]