[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] Proposal for i006 (and some comments on i008)
Marc Goodner wrote: > i006 Source based delivery QoS policy assertion > > http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i006 > > > > It does not make sense to allow the RMS to signal anything about a > desired guarantee to be used for a sequence at the RMD when it does not > affect protocol behavior otherwise. This is an unnecessary complication > that does not provide any additional benefits in providing reliable web > service messages. This is also contrary to one of the principles of > WS-RM that the guarantee is a private contract between the application > and the RM layer. > How is it a private contract? It can be made publicly available through the policy. The TC already made a decision on issue i009 [1] which exposes the DAs in the policy. I don't see where the complication arises, especially when there is no new message/header introduced. And it seems quite necessary to me (more on this below). DAs don't affect the protocol and are implemented by RMD/AD, but the AS certainly cares about the DAs. They are in fact quite important to the applications and the AS. Here are a few cases where it is important : 1) Support for multiple DAs are advertised by the endpoint through WS-Policy (eg, two alternatives in wsp:ExactlyOne). This means that the user of the service gets to choose which DA is implemented for a particular Sequence and that may indeed be important to the AS or the application logic. How does the AS indicate to the RMD/AD which DA is in play for the Sequence? In addition, resolution of issue i010 does not restrict an RMD necessarily to a single endpoint. Keep in mind that the Sequence gets started when the connection is set up using the CS/CSR message. The CS/CSR message provide absolutely no information (in the SOAP body or through Action) about the WSDL port(s)/operation(s) that will be invoked within the Sequence. 2) Consider multiple operations within a portType that require different DAs (this is issue i008 [2] and we'll have to wait to resolve that issue before resolving this one). Or even multiple DAs for different messages in the same operation (it is quite reasonable to say that the input messages has to be ordered, but the output message -- app level ack -- does not). What one has to consider here is a long running Sequence and a mix of Ordered Delivery and non-ordered delivery (the mix is at the endpoint/port *not* within a Sequence) -- as this is the case where the costs can be significantly different. For short sequences and when Ordered delivery is not mixed with un-Ordered delivery, the costs aren't very high and all of this doesn't matter. If cost saving is important, the only thing one can do is to split the operations amongst multiple portTypes and have multiple endpoints for those operations. This seems a little backward to me, sort of a case of the tail wagging the dog. That's not how applications get designed. Essentially, the QoS is imposing design constraints on WSDL. Typically, application developers create WSDL based on what kind of grouping of operation/policies makes sense independent of QoS (security, reliability etc). In fact a lot of times these are added in later. Services are deployed in a test environment to figure out all the bugs, quirks etc. Once things are ready for further testing (or deployment on production systems), more infrastructural things (such as reliability) get added in. Redesigning WSDL, re-associated endpoint policies, re-configuration is not something that typically happens at this point. To add to that, if you envision a secure/reliable intermediary, where security/reliability capabilities are implemented say at the firewall boundary (or the boundary of reliable/unreliable node in the network). Or even a reliable intermediary supporting multiple services/endpoints (running on a big machine with lots of resources and durability/persistence capability), splitting the operations into multiple portTypes/endpoints trick does not work in this case. I would like to understand why you think adding this capability adds so much complexity to the implementation. I don't quite see it that way. The RMD has to implement the DAs anyway. In fact by including the wsrm:DeliveryAssurance element (see my proposal at [3]), which we have already defined, in the CreateSequence message we get to very easily solve this problem which does not impose a lot on RMD (a quick cross-check on its capabilities/policy with what is requested). This does not require a new protocol element or another message. This adds much, much less complexity than what we did with the 'Close' message for a significant benefit. -Anish -- [1] http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i009 [2] http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i008 [3] http://lists.oasis-open.org/archives/ws-rx/200510/msg00263.html > > > Proposal: close with no action. > > > > Marc Goodner > > Technical Diplomat > > Microsoft Corporation > > Tel: (425) 703-1903 > > Blog: http://spaces.msn.com/members/mrgoodner/ > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]