[
https://issues.jboss.org/browse/JBTM-986?page=com.atlassian.jira.plugin.s...
]
Paul Robinson updated JBTM-986:
-------------------------------
Summary: Automatically setup the client side handler chain (was: Setup client
side handler chain if Service wsdl contains WS-Policy Assertion )
Description:
When invoking a WS-AT or WS-BA Web service, the client side handler has to be added to the
client stub to manage transaction context propagation. The code required to do this is as
follows:
{code}
BindingProvider bindingProvider = (BindingProvider) client;
List<Handler> handlers = new ArrayList<Handler>(1);
handlers.add(new JaxWSHeaderContextProcessor());
bindingProvider.getBinding().setHandlerChain(handlers);
{code}
This is not very user friendly.
h2. Using WS-Policy
If the Service WSDL specifies a WS-Policy assertion, we know that WS-AT or WS-BA is
required/supported and we should be able to setup this handler chain automatically.
Another benefit is that we can catch, on the client side, the situation where no WS-AT or
WS-BA transaction context is present. Currently we leave it up to the service to detect
and as a result we have no control over how this fault will be propagated back to the
client. For example, a WrongStateException could be thrown when the service tries to
enlist a participant and a transaction is not present. The Client may receive a generic
fault message back or, in this case some or all of the WrongStateException. In either
case, the developer of the Client is unlikely to realise that this is due to there not
being a transaction present when the service was invoked. If the service mandates a WS-AT
or WS-BA transaction, but none is present, then the client handler throws a suitable
exception explaining what went wrong. If the service supports (i.e. it is optional) a
WS-AT or WS-BA transaction, then the interceptor ignores the situation where non exists.
CXF seems to have a plugin point for adding WS-Policy assertion handlers. This could be
the right integration point for this feature. This is to be investigated.
h2. Without WS-Policy
It could be possible to inject a WS client stub and annotate the injection point such that
the middleware knows to setup the handler chain. I'm not sure what support already
exists for injecting WS client stubs. This needs to be investigated first.
was:See the "Policy Assertions" section of the WS-BA and WS-AT specification
for what this should implement. Ideally this feature would be turned on/off via an
annotation, however we should take a look to see if WS-Policy mandates a particular
method.
Automatically setup the client side handler chain
-------------------------------------------------
Key: JBTM-986
URL:
https://issues.jboss.org/browse/JBTM-986
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: XTS
Reporter: Paul Robinson
Assignee: Paul Robinson
Fix For: 5.0.0.M2
When invoking a WS-AT or WS-BA Web service, the client side handler has to be added to
the client stub to manage transaction context propagation. The code required to do this is
as follows:
{code}
BindingProvider bindingProvider = (BindingProvider) client;
List<Handler> handlers = new ArrayList<Handler>(1);
handlers.add(new JaxWSHeaderContextProcessor());
bindingProvider.getBinding().setHandlerChain(handlers);
{code}
This is not very user friendly.
h2. Using WS-Policy
If the Service WSDL specifies a WS-Policy assertion, we know that WS-AT or WS-BA is
required/supported and we should be able to setup this handler chain automatically.
Another benefit is that we can catch, on the client side, the situation where no WS-AT or
WS-BA transaction context is present. Currently we leave it up to the service to detect
and as a result we have no control over how this fault will be propagated back to the
client. For example, a WrongStateException could be thrown when the service tries to
enlist a participant and a transaction is not present. The Client may receive a generic
fault message back or, in this case some or all of the WrongStateException. In either
case, the developer of the Client is unlikely to realise that this is due to there not
being a transaction present when the service was invoked. If the service mandates a WS-AT
or WS-BA transaction, but none is present, then the client handler throws a suitable
exception explaining what went wrong. If the service supports (i.e. it is optional) a
WS-AT or WS-BA transaction, then the interceptor ignores the situation where non exists.
CXF seems to have a plugin point for adding WS-Policy assertion handlers. This could be
the right integration point for this feature. This is to be investigated.
h2. Without WS-Policy
It could be possible to inject a WS client stub and annotate the injection point such
that the middleware knows to setup the handler chain. I'm not sure what support
already exists for injecting WS client stubs. This needs to be investigated first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira