XTS with existing Web Services

[joe.chuah]

Hi,

I'd just like to confirm this point. Is it impossible to use XTS with existing web services which don't currently implement Participants, Managers and etc classes?

I just started exploring XTS so I'm trying to get a good grasp of it.

Thanks in advance for any info on this.

[paul.robinson]

Wooi,

No it isn't possible. The Web service must participate in the protocol, hence it needs to implement a participant. Do you have any control over the service? If you are interested in using WS-AT, you can update the existing service with minimal effort, to use the TXBridge. The TXBridge generates its own participants and relatively transparently bridges a WS-AT transaction onto a JTA transaction. Take a look at our TXBridge quickstarts for some examples: https://github.com/jbosstm/quickstart

If you are calling a third-party service, then you might be able to do something with WS-BA. WS-BA is different to WS-AT, in that it uses a compensation approach. You might be able to front the legacy service with a WS-BA service that invokes some compensation action on the legacy service, should compensation be required.

Paul.

[joe.chuah]

Hi Paul,

Thanks for pointing me in the right direction (needed a bridge for JTA and WS-AT). I looked through the quickstart and some documentation at http://docs.jboss.org/jbosstm/5.0.0.M1/guides/txbridge_guide/ch04.html

The doc says:

4.5.2. Outbound Bridge

The demonstrator client application can also be used to invoke the XTS Night Out demo Restaurant Service via the outbound bridge. Deploy the XTS demo application services, then select the 'JTA' transaction type in the client. In this scenario the client uses a JTA transaction only, whilst the service understands WS-AT type transactions only. Note that the client has its own copy of the service API, annotated with @HandlerChain(file = "jaxws-handlers-client.xml"), which is the only point of linkage with the transaction bridge. Once again neither the client nor server have any compile time dependency on the bridge.

I don't really understand the underlined part as the quickstart demo only seems to have the following lines to register the handler

         Restaurant restaurant = service.getPort(portName, Restaurant.class);

        //Add client Handlers

        List<Handler> handlers = new ArrayList<Handler>(1);

        handlers.add(new JaxWSTxOutboundBridgeHandler());

        handlers.add(new JaxWSHeaderContextProcessor());

        BindingProvider bindingProvider = (BindingProvider) restaurant;

        bindingProvider.getBinding().setHandlerChain(handlers);

I assume the quickstart is the accurate way to do it?

Also when you said existing services can be updated with minimal effort, does it mean using  an inbound bridge?

[paul.robinson]

Wooi,

Wooi Joe Chuah wrote:

I don't really understand the underlined part as the quickstart demo only seems to have the following lines to register the handler

         Restaurant restaurant = service.getPort(portName, Restaurant.class);

        //Add client Handlers

        List<Handler> handlers = new ArrayList<Handler>(1);

        handlers.add(new JaxWSTxOutboundBridgeHandler());

        handlers.add(new JaxWSHeaderContextProcessor());

        BindingProvider bindingProvider = (BindingProvider) restaurant;

        bindingProvider.getBinding().setHandlerChain(handlers);

This is what you need on the client side, to bridge a JTA transaction to an outgoing WS-AT transaction. Essentially, it add's a SOAP handler into the outgoing handler chain. This handler is responsible for managing the mapping between the JTA anf WS-AT transaction.

Also when you said existing services can be updated with minimal effort, does it mean using  an inbound bridge?

Yes, you just need to add the @HandlerChain(...) annotation to your service. If you want to be sure it's working, also annotate your service with the MANDATORY transaction type. This will fail if there isn't a JTA transaction present when the servie is invoked. If you configured the bridge correctly, the incoming WS-AT transaction will be bridged onto a new JTA transaction, ready for when your service method is invoked.

Also, you can try rolling back your transaction from the client and ensuring that the work done in the Service's JTA transaction is also rolledback. If the Bridge is not configured correctly, you could see the service's JTA transaction commit, whilst the client's transaction rollsback.

Paul.

[joe.chuah]

Hi Paul,

It seems I can't deploy XTS on Jboss EAP 5.1.2 due to this https://issues.jboss.org/browse/JBPAPP-10384 but the issue seems to be resolved already.

Could guide me on how I can get the fixed version?

Thanks

[paul.robinson]

Wooi,

That issue only affects an internal build of EAP (EAP_EWP 5.2.0 ER4), you shouldn't get it in EAP 5.1.2 (or 5.2.0 when it is released).

Are you seeing a problem when you try to deploy XTS onto EAP 5.1.2?

Paul.

[joe.chuah]

Paul,

Yeah I get that problem when I try to deploy XTS on the jboss that comes with Redhat BRMS.

If I'm not mistaken its EAP 5.1.2

[paul.robinson]

Wooi,

Are you absolutely sure it's the same issue as JBPAPP-10384? Do you see the following error on the console:

DEPLOYMENTS IN ERROR:
  Deployment "XTSService" is in error due to the following reason(s): java.lang.SecurityException: class "org.jboss.jbossts.xts.recovery.participant.at.XTSATRecoveryModule"'s signer information does not match signer information of other classes in the same package

As you are using EAP, you should take this up with your support contact at Red Hat. You'll get a better level of service from them. These forums are intended for community support and only serviced at a level of "best effort".

Paul.

[joe.chuah]

Hi Paul,

Apparently they are planning to roll out the fixes with EAP 5.2.1

Thanks for the help so far.

[paul.robinson]

You're welcome,

Glad you're getting a resolution,

Paul.