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