[jbossws-dev] WS-AT policy integration

[Paul Robinson]

Alessio,

See below...

On 09/11/11 18:06, Alessio Soldano wrote:
>> Can you give me permission?
> You can subscribe here
> https://lists.jboss.org/mailman/listinfo/jbossws-dev , it's a public
> mailing list
Done. Should have guessed that was what I needed to do.


>> 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.
This would be nice. Handler is automatically added when service 
advertises the need for WS-AT/WS-BA. Otherwise the client developer has 
a nice simple method to specify it's need. Whether this is using a JAXWS 
2.1 feature or some other mechanism. Maybe we could inject WS-AT 
"enabled" clients with CDI or do some other CDI "magic". Something to be 
investigated, we know the requirements which is enough for now.


>> 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.
I'm glad it's gaining traction. It does sound like a very sensible thing 
to do.

>> 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.
I agree. I think the top-level requirements come from the WS-TX user, so 
I'll put together some high level Jiras in the JBossTS project and we 
can link through to JBossWS when required.

I'd like to run these ideas by Andrew Dinn first, just to make sure 
there's not something I'm missing.

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)