[jbossws-dev] Fwd: Re: WS-AT policy integration

[Alessio Soldano]

-------- Original Message --------
Subject: Re: WS-AT policy integration
Date: Wed, 09 Nov 2011 16:57:20 +0000
From: Paul Robinson <paul.robinson at redhat.com>
Reply-To: paul.robinson at redhat.com
To: Alessio Soldano <asoldano at redhat.com>

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:
>> By beginning a WS-AT
>> transaction on the Client and using the XTS client side interceptor, the
>> TX context will flow with the application soap message and hopefully be
>> accepted by the policy assertion.
> OK, good. I really need to refresh my memory a bit on the final user API
> provided by XTS. 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?

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.


> 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 why I suggested the user to try building the
> client from a local copy of the wsdl contract modified so that the cxf
> policy engine does not fail because of required ws-at.
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'd have to see the WSDL to know if there was an alternative.
>>
>> I can reply on the forum if you would like?
> Yes, please.
> Thanks
> Alessio
>
I'll go do that now.

Thanks,

Paul.

-- 
Paul Robinson
paul.robinson at 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)