-------- Original Message -------- Subject: Re: WS-AT policy integration Date: Wed, 09 Nov 2011 16:57:20 +0000 From: Paul Robinson <paul.robinson(a)redhat.com&gt; Reply-To: paul.robinson(a)redhat.com To: Alessio Soldano <asoldano(a)redhat.com&gt; Alessio, Can you forward this to jbossws-dev as i don't have permission to email the group. Can you give me permission? See below... On 09/11/11 13:28, Alessio Soldano wrote: This could be a good idea. The way we have to specify the client side handler is pretty nasty at the moment: BindingProvider bindingProvider = (BindingProvider) client; List<Handler> handlers = new ArrayList<Handler>(1); handlers.add(new JaxWSHeaderContextProcessor()); bindingProvider.getBinding().setHandlerChain(handlers); My understanding is that we used to be able to define a @HandlerChain on the client's SEI, but that feature was removed when you guys realised it went against the JAX-WS spec. Is this correct? The @HandlerChain annotation was certainly nicer than the above method, but it was still something extra for the client developer to remember and understand. Plus it's absence causes a failure in the service which is unlikely to be intuitive to the client. I don't know how widely used wsat:ATAssertion is on WSDLs for WS-AT enabled services, so I don't know how many users will benefit from this feature. But automatically generating the handler chain would seem like a good approach as: 1. We can automatically define the handler chain. Less burden on the developer. 2. We can detect that the client has tried to invoke the service without beginning a WS-AT transaction. This gives us control over how we notify the client application. Hopefully we can do this in a nice clear way. If we leave it up to the service to detect the lack of a transaction, we have no control over how the client is notified of the error. For example, a badly coded service may throw a NullPointerException (or even worse a generic soap fault) when it gets back a null TXID and tries to do something with it. It's going to be difficult for the developer to realise that a NPE or empty SoapFault from the service is due to them not beginning a transaction. This of course assumes that the service advertises the fact that it needs WS-AT, which I think would be good practice. On the server side I think there should be a simple way of having the wsat assertion added to the WSDL. From the WS-AT spec it looks like this feature is required. I'll check the XTS code base to see if its already been implemented. My main goal with XTS is to improve usability; pretty much everything I have planned for XTS boils down to a usability improvement. WS-AT is getting some users, but WS-BA very few. We think this is down to the steep learning curve of WS-BA in particular. Therefore, this feature really interests me as it makes the Client API much more usable. Ah ok, I didn't notice that. In that case we may need a new feature in CXF to support this. Maybe it's just a matter of creating a plugin that understands this assertion. Something for us to investigate. This may not work. It's likely that the service will make the assumption that it is being invoked in a WS-AT transaction. Totally reasonable given that any invocations without a TX context should be blocked by the policy assertion. The service will likely try to enlist participants in a null transaction which will cause a failure. I'll go do that now. Thanks, Paul. -- Paul Robinson paul.robinson(a)redhat.com JBoss, a Division of Red Hat Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson (USA), Charlie Peters (USA)