Re: CR33: Just wondering - Does anyone actually need wsaw:anonymous in WSDL?

Katy,

I'll change the question slightly and answer it:
Does anyone need to be able to indicate statically (not at runtime) that 
'anon' is required or 'prohibited'?

The answer is most definitely 'yes'.

As you mentioned there was a discussion on this at the Tokyo F2F. The 
usefulness of this is not just for legacy apps and providing a run-time 
exception is not an acceptable solution.

DavidH has already explained how it is useful to say 'anon' is required 
because the service understands WSA but the transport is not capable of 
anything but 'anon' connections.

An important and quite useful use case is when the req-res are separated 
by a large amount of time and the service wants to make it very clear 
that the response will always be sent over a separate connection. This 
is useful in variety of applications the most talked about being 
workflow. How does one describe such a req-res? One can use the WSDL 
req-res operation and provide additional marker to say that 'anon' is 
not allowed or provide two WSDL one-way operation with some way to 
specify that they are correlated. I've been telling a lot of folks (and 
so has WS-I, to a recent query from RosettaNet) that WSDL req-res 
operation does not mean that the operation is "synchronous" -- which it 
isn't. That is up to the binding and things like WS-A.

Currently, the wsa:Anonymous maker is the best way to describe a 
"asynchornous" req-res operation. I don't particularly care how it is 
specified. If a single wsa:Anonymous makes sense, so be it. If it makes 
more sense to have three markers so as to best fit the way WS-Policy 
works (so has to allow the markers to be used as WSDL markers as well as 
policy, a la wsa:UsingAddressing), then lets do that. But I'm certainly 
opposed to removing this marker without providing a way to specify the 
same information statically.

-Anish
--

Katy Warr wrote:
> 
> David
> 
> <dh> I think there was agreement that we needed a way to say "this 
> endpoint understands WSA headers, but won't do anything but anonymous" 
> </dh>
> The question is: does anyone need to be able to indicate this via a WSDL 
> marker?
> 
> Thanks
> Katy
> 
> 
> 
> *David Hull <dmh@tibco.com>*
> Sent by: public-ws-addressing-request@w3.org
> 
> 14/09/2006 15:36
> 
> 	
> To
> 	Katy Warr/UK/IBM@IBMGB
> cc
> 	public-ws-addressing@w3.org
> Subject
> 	Re: CR33: Just wondering - Does anyone actually need wsaw:anonymous in 
>  WSDL?
> 
> 
> 	
> 
> 
> 
> 
> 
> I thought this was more to do with anon "prohibited" than the whole 
> marker.  I think there was agreement that we needed a way to say "this 
> endpoint understands WSA headers, but won't do anything but anonymous" 
> (basically the SOAP layer is WSA-aware but the transport layer isn't). 
>  This would be the "required" value (except for the "none" thing).
> 
> That said, a policy assertion is needed to handle the more general 
> question of "just what addresses can I use for async responses", and it 
> looks like it would also handle the other use cases, including (I think) 
> the "required" case.
> 
> Katy Warr wrote:
> 
> I'd like to raise the question:
> 
>         ** Does anyone actually need the <wsaw:anonymous> marker in the 
> WSDL Binding spec? **
> 
> You may recall this being discussed at the tokyo F2F and it resulted in 
> a very close vote.  I believe people voted for it because the long term 
> implications/complications weren't appreciated.  We took the attitude - 
> "it's not complicated and might be useful for legacy apps, so why not?" 
>  Now we have more information and can appreciate the complexities of 
> this flag, it might be appropriate to revisit this decision.
> 
> Here's a proposal:
> 1) Remove the wsaw:anonymous flag from the WSDL Binding spec entirely.  
> 2) If required, endpoints can indicate their lack of support for either 
> non-anonymous responses or anonymous responses via a runtime fault or 
> policy assertion (which we can consider separately from the WSDL marker).
> 
> regards
> Katy
>

Received on Monday, 18 September 2006 18:07:11 UTC