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

> Can you give me permission? You can subscribe here https://lists.jboss.org/mailman/listinfo/jbossws-dev , it's a public mailing list

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

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