[jbossws-dev] WS-AT policy integration

Paul Robinson paul.robinson at redhat.com
Mon Nov 28 12:46:05 EST 2011


Alessio,

I've finally put together those Jiras I promised:

https://issues.jboss.org/browse/JBTM-985
https://issues.jboss.org/browse/JBTM-986

They are part of my grand plan to improve usability as a whole for users 
of XTS. This is why it took me so long to file the issues; I needed to 
think about how they fitted into the bigger picture first.

The next steps are for me to schedule this and other issues, so don't 
pay too much attention to where these are currently on our roadmap.

I don't think I need anything from you just yet. I should be able to do 
the preliminary research, after which i should have a better idea what 
is needed from JBossWS to make this work.

Thanks,

Paul.

On 10/11/11 14:07, Paul Robinson wrote:
> 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
Web service transactions lead
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)



More information about the jbossws-dev mailing list