[jbossws-dev] WS-AT policy integration

[Alessio Soldano]

Hi Paul,

On 11/09/2011 05:57 PM, Paul Robinson wrote:
> Alessio,
> 
> Can you forward this to jbossws-dev as i don't have permission to email
> the group.

Sure

> Can you give me permission?

You can subscribe here
https://lists.jboss.org/mailman/listinfo/jbossws-dev , it's a public
mailing list

> On 09/11/11 13:28, Alessio Soldano wrote:
>> It might even be possible to have JBossWS-CXF associate
>> that interceptor to the Apache CXF policy engine, so that the
>> interceptor is automatically installed when the server policy requires
>> that... ?
> 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?

I remember some discussion on where exactly the @HandlerChain can be
used on client side...

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

Right. In any case, afaiu you basically need a JAXWS handler to be added
to the handler chain for having the WS-AT processing happen. That's
certainly something doable automatically when detecting a given
assertion in the policy engine. I need to figure out the details, but
this should definitely be doable.
Btw, in order for improving the API, we might also check if it's
possible to mask the handler addition behind a JAXWS 2.1 feature the
user can pass in when building the client instead of having to go
through the binding provider.


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

If using WS-Policy, yes that's indeed good practice. WS-Policy is
becoming more and more popular since it allows for advertising WS-*
functionalities into WSDL contracts. So being able to support the
policies for WS-AT would really be nice.


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

OK, thanks. Basically that's the other half of the topic. I think I
remember that for instance Glassfish has an annotation (@Transactional
or something) to be used for having the server automatically generate
WS-AT assertions into the wsdl contract when that's not provided (code
first approach).


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

OK, I think we should probably define what to do and start by creating
some jiras.


>> Btw, the exception the user is getting is actually thrown by CXF on
>> client side, when processing the server wsdl to prepare the client stubs
>> for the invocation. So afaics from the logs, the Glassfish server is not
>> even reached atm.
> 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.

That's tightly related with what I wrote above, the cxf policy engine
needs to be instructed with our ability of dealing with ws-at
assertions. And that customization is likely to have to be added in
jbossws-cxf.

Cheers
Alessio

-- 
Alessio Soldano
Web Service Lead, JBoss