Clarification on the use of the Transaction bridge in a inbound bridging

[mauromol]

Hello!

After having successfully integrated JBossTS JTA into our web application, we're now planning to go further and make the web services of our application to be transactional.

I read with care all the documentation of XTS and the transaction bridge and I find the topic very very interesting!

However, I have a little doubt of one aspect I couldn't fully understand from the documentation.

Suppose I have the following scenario: my web application exposes a web service called MyService, a very simple one that, once called, just starts a JTA transaction, writes something to a database and commits the transaction. At first, suppose this web service is not a transactional one, so the typical workflow is that a web service client invokes it outside of any transactional context just to do a persistent modification to the application database. Saying in other words, it's like MyService were working in "auto-commit" mode, or, using the terminology of Mark Richards at http://www.ibm.com/developerworks/java/library/j-ts2.html, that the transaction strategy were managed at the API layer (where API here is the web service).

Now, suppose I want to switch to a client orchestrated transaction strategy, by making this web service transactional. Suppose I set up the whole XTS thing on both the client side and the server side (so that the appropriate handlers for both WS-AT and the bridge are configured, the coordination service is running, etc.) and that I change the client so that it:

- starts a WS-AT transaction

- invokes my simple web service in that transaction context

- then commits the WS-AT transaction

My question is: do I have to change the code of MyService?

My concern is about the fact that MyService actually commits the JTA transaction after having started it (and after having made some changes in the DB). I understood the interposition and the parent-subordinate coordinator mechanism, but it's not clear to me if the fact that I issue a commit in a JTA transaction which is actually a subordinate transaction of a WS-AT parent one, automatically translates in the system to actually post-pone the "real" commit only when the "commit" command is issued on the parent WS-AT transaction.

If it is so, it's really great, because the changes needed to make our web services transactional is almost null.

If not, how do I have to change the code of MyService to accomplish the result?

Thanks in advance,

Mauro.

[adinn]

Hi Mauro,

Mauro Molinari wrote:

. . .

Now, suppose I want to switch to a client orchestrated transaction strategy, by making this web service transactional. Suppose I set up the whole XTS thing on both the client side and the server side (so that the appropriate handlers for both WS-AT and the bridge are configured, the coordination service is running, etc.) and that I change the client so that it:

- starts a WS-AT transaction

- invokes my simple web service in that transaction context

- then commits the WS-AT transaction

My question is: do I have to change the code of MyService?

My concern is about the fact that MyService actually commits the JTA transaction after having started it (and after having made some changes in the DB). I understood the interposition and the parent-subordinate coordinator mechanism, but it's not clear to me if the fact that I issue a commit in a JTA transaction which is actually a subordinate transaction of a WS-AT parent one, automatically translates in the system to actually post-pone the "real" commit only when the "commit" command is issued on the parent WS-AT transaction.

If it is so, it's really great, because the changes needed to make our web services transactional is almost null.

If not, how do I have to change the code of MyService to accomplish the result?

The first thing to note here is that you will not get any immediate benefit out of using the XTS code to manage the scenario you describe because you only have one participant in the transaction. It will not make a lot of difference whether you commit the transaction from the web service by driving your own JTA TX or or from the client via the coordinator using bridging from a WS-AT TX to a JTA TX. If the transaction commits without a crash the DB will be updated. If a crash happens before the commit is processed by the DB then it will not be updated.

However, it is still highly beneficial to use XTS here because once you have made your web service transactional you can call it alongside another transactional web service and be sure that they will both commit their changes or both roll back together if one of them crashes. The hard problem is ensuring consistent outcomes when you make changes in two different places i.e. when you make requests of two separate web services. XTS solves this hard problem.

So, now to answer your second question. Yes, you will have to change your code. Your web service cannot be responsible for driving the JTA transaction. It cannot execute begin(), suspend(), resume(), commit() or rollback(). These methods get called automatically by the bridge code. In fact if your web service gets hold of the current JTA transaction instance (using UserTransactionFactory/UserTransaction) and tries to call commit() or rollback() an exception will be thrown. This is because the JTA transaction is subordinate to the WS-AT transaction. It has to do whatever the WS-AT coordinator tells it to do. The coordinator knows what outcome is appropriate when multiple services are called. If you were to drive the transaction from the web service you would not know what the outcome would be for other WS-AT services called in the transaction.

Here's a scenario which can be used to explain what happens. Imagine you have two clients, web service A (your web service) and web service B (a 3rd party service). Your client starts a WS-AT TX and then makes two requests, one to web service A and another to web service B. It then calls commit. Let's go through what happens on the service side in your web service.

You web service (A)  should have installed the inbound bridge handler to process incoming requests. This handler begins a JTA transaction when the 1st request comes in to web service A. It calls begin this because it knows it has not seen the WS-AT TX identifier before. This means that this 1st request executes inside a JTA transaction . So, you can safely access XA resources under the web service call without them being auto-committed. When the web service request finishes the handler automatically suspends the JTA transaction.

Ok, it's no tin the scenario above but imagine your client made another request to your web service (A) from the same WS-AT transaction. Well, the same JTA TX would be resumed because the handler knows that the two transactions are linked. So, your transactional web service can actually provide a set of service requests rather than just one request and they all execute in the same JTA TX i.e. teh changes to the XA resource made in each call will be visible across calls (even though they are not yet committed). The inbound bridge handler resumes and then suspends the JTA TX around the execution of the service method.

Ok, so now assume the request has been made to service B and the client commit. The coordinator whihc receiuves the commit request talks to the bridge code managing web service A tellking it to prepare the WS-AT TX. ow the bridge code knows that this WS-AT TX is associated with a JTA TX so it calls prepare() on the JTA TX (it uses a private API to do this, different to the one your code would see so it does not get an exception). Assuming the XA resource has no problem preparing its changes the JTA transaction returns PREPARED to the bridge code and the bridge code returns PREPARED to the coordinator.

At this point the coordinator will then go on to send PREPARE to web service B. If service returns PREPARED then both services get sent COMMIT and eventually return COMMITTED (this will happen even if one of them crashes so long as they both got as far as returning PREPARED). If service B returns ABORTED then the coordinator responds by sending ABORT to the bridge code managing web service A. The bridge code calls abort() on the JTA transaction undoing any changes to the XA Resource and returns ABORTED (this also is guaranteed to happen eventually even if service A or the coordinator crashes). So, whatever happens either both A and B commit or both A and B abort.

So, what do you need to do in your web service? Well, you need to configure the inbound bridge handler to process incoming requests and then jsut write it as if it is running inside a JTA TX i.e. use whatever XA resources are available in the JBOss container running the web service. Your service does not need to care about how this JTA TX gets started or terminated since any changes it makes will be guaranteed to be atomic, isolated, durable and  transactionally consistent.

And what about deployment? You need to install the XTS service in the client app server deploy directory and in the deploy directory of the app server which is running web service A. You also need to drop the bridge jar into the server deploy directory for web server A. That's it.

[mauromol]

Thank you Andrew for your detailed answer!

Then, I understand that I have to implement my web service so that it does not "touch" the transaction, so it neither commits nor rollback: someone else will do that for it, and that is the bridge (which works in conjuction with the WS-AT infrastructure).

We are not using JBoss Application server, but we are rather embedding JBossTS JTA in our web application, using Spring to provide a higher level interface to transaction management and the necessary glue code to coordinate the work done on three different databases, one of which managed through Hibernate and the other two in another custom way. So, this clarification on the pattern to apply to correctly write a web service whose transactional behavior is controlled by the WS-AT+JTA bridge is very important to me.

Then, I guess that if I want the global WS-AT transaction to rollback, my web service could simply throw an exception, which is in turn translated into a SOAP fault and recognized by XTS as a condition which must lead to a rollback, is it correct?

Thanks again,

Mauro.

[adinn]

Mauro Molinari wrote:

Then, I understand that I have to implement my web service so that it does not "touch" the transaction, so it neither commits nor rollback: someone else will do that for it, and that is the bridge (which works in conjuction with the WS-AT infrastructure).

Yes, that is right.

Mauro Molinari wrote:

We are not using JBoss Application server, but we are rather embedding JBossTS JTA in our web application, using Spring to provide a higher level interface to transaction management and the necessary glue code to coordinate the work done on three different databases, one of which managed through Hibernate and the other two in another custom way. So, this clarification on the pattern to apply to correctly write a web service whose transactional behavior is controlled by the WS-AT+JTA bridge is very important to me.

Hmm, then you have another problem. XTS only works inside JBoss AS. Why? Well, all those messages from the web service to the coordinator and from the coordinator to the web service need to be delivered somehow. XTS uses JBossWS to do this, specifically it uses JaxWS. This means your web service has to provide a JaxWS endpoint and the XTS code relies upon using JBossWS as the implementation -- i.e. it has to ruin inside a JBoss AS. container.

Similarly, the messages from the client to the coordinator (these are used to implement UserTransaction.begin(), UserTransaction.commit() and UserTransaction.rollback()) also rely on the JBossWS implementation of JaxWS. So your client also has to run inside a JBoss AS container.

You don't have to use the XTS coordinator service implementation-- you coudl rely on using a 3rd party implementation. However, if you want to use the XTS coordinator then you will also have to use a JBoss AS container. Normally you would use the coordnator service running in thre client AS or the web service AS but you can locate it in its own container.

Mauro Molinari wrote:

Then, I guess that if I want the global WS-AT transaction to rollback, my web service could simply throw an exception, which is in turn translated into a SOAP fault and recognized by XTS as a condition which must lead to a rollback, is it correct?

No, I am afraid that is not quite correct. If your service method throws a fault this does not tell the bridge code that the transaction should roll back. It is quite common for web services to throw faults and XTS does not attach any meaning to them because it cannot know what the fault is intended to mean. However, there are two simple ways you can ensure that the tarnsaction rolls back if your web service detects an error condition.

The first option is to let the server throw an exception and handle it at the client end. The exception should be propagated to the client using a soap fauilt. When the client catches the exception it can make sure that it calls  rolback() rather than commit(). Thsi is the most efficient way to do things as the clien tcan short-circuit any further work in the transaction and just do an immediate rollback().

The other alternative is for the web service to call setRollbackOnly on the current JTA transaction. If the client calls commit then the PREPARE message to your web service will be handled by calling prepare() for the JTA transaction and it will return ABORTED. All the other participants will then be told to roll back and the commit will fail.

[mauromol]

Andrew Dinn ha scritto:

Hmm, then you have another problem. XTS only works inside JBoss AS. Why? Well, all those messages from the web service to the coordinator and from the coordinator to the web service need to be delivered somehow. XTS uses JBossWS to do this, specifically it uses JaxWS. This means your web service has to provide a JaxWS endpoint and the XTS code relies upon using JBossWS as the implementation -- i.e. it has to ruin inside a JBoss AS. container

This is bad news :-(

We have our own SOAP engine (Axis2) and we may provide that to XTS in order to expose the coordinator web service and to do service calls. AFAIK, Axis2 provides support for JaxWS webservices, so is it possible to make XTS use it instead of the JBossWS implementation? Do you have any suggestion on where to start from if we want to try this kind of integration?

Andrew Dinn ha scritto:

The first option is to let the server throw an exception and handle it at the client end. The exception should be propagated to the client using a soap fauilt. When the client catches the exception it can make sure that it calls  rolback() rather than commit(). Thsi is the most efficient way to do things as the clien tcan short-circuit any further work in the transaction and just do an immediate rollback().

This is reasonable and, after thinking a while, this is actually what I meant in my original intention.

Mauro.

[adinn]

Mauro Molinari wrote:

This is bad news :-(

We have our own SOAP engine (Axis2) and we may provide that to XTS in order to expose the coordinator web service and to do service calls. AFAIK, Axis2 provides support for JaxWS webservices, so is it possible to make XTS use it instead of the JBossWS implementation? Do you have any suggestion on where to start from if we want to try this kind of integration?

Well, you might be able to get the code to work if you are willing to hack around inside the XTS implementation. In fact if you are interested in doing this I might be interested in helping port your patches back into our XTS release if that is possible. Of course, I cannot guaranntee that you will succeed nor that I will be able to provide all the help you need but I'l ldo my best to provide what assistance I can.

I have tried as far as possible to rely only on standard JaxWS features in the current implementation -- the code did at one point some years ago run with most features working on Glassfish/embedded JBossTS as well as on JBossWS/Native and JBossWS/CXF. However, relying on the standard was not always possible because different containers provide slightly different behaviours in their JaxWS implementations and the differences in the details caused quite a few headaches. The main problem areas are as follows:

The deployed sar includes an api jar, various jars which implement the XTS functionality (WSAS, WSCF, WS-C, WS-T and WSTX) plus some wars (WS-C, WS-T and WSTX) which supply the JaxWS endpoints and web listeners used to initialise the whole show. The endpoints and listeners are configured via web.xml but you may need to reconfigure things in order to get the end points published correctly.

The endpoints are derived from WSDL which you will find included with the release but they rely on annotations on the implementation bean to define the endpoint's behaviour as a web service. The interpretation of the annotations is (e.g. @Action("input="...", output="...")  vs @WebMethod(action="...")) is one area where you might find that the JaxWS implementation varies.

The thing you are nost likely to find problematic is the use of web servcies addressing. The JaxWS committee dropped the ball with WSA some years back and butchered the spec. So, there is no standard programming API for setting and accessing WSA properties associated with JaxWS messages -- things like To, From, ReplyTo, FaultTo, RelatesTo, MessageId etc. In order to be able to run on both JBossWS/Native and JBossWS/CXF we had to invent an MAP (message addressing properties) abstraction layer in JBossWS to allow XTS to manipulate WSA headers in a stack-neutral way. JBossWS implements this in two different flavours which rely on the different APIs provided by CXF and our own native SOAP stack. You wil have to grab this out of JBossWS and port it if you want XTS to work on Axis2

Also, even if you try to port the MAP library so that you are able to set and read WSA properties for JaxWS messages there is no guarantee that they will be handled properly by the JaxWS layer. We have had several problem specifying a FaultTo address in CXF using OneWay messaging. It worked then it was broken then it worked again and then it got broken again and is now (just) back to working. So, expect to have to struggle with this.

[mauromol]

Hi Andrew! This sounds as a lot of work... or, at least, as a lot of studying over the internals of XTS, JBossWS and Axis2... I don't know if we have the resources to do that, at least within the available time frame we have.

By the way, what is https://jira.jboss.org/browse/JBTM-267 about? I can't understand if any action has been taken to close it or not. Anyway, in that bug report you say that Axis2 has no API to manage WS-Addressing properties, although on the net I read it has (http://wso2.org/library/2561 for instance). Just to let you know, if you don't already...

I will let you know what we will do. Of course if we succeed to integrate XTS with Axis2 I will let you know to share our experience.

Mauro.

[adinn]

Hi Mauro,

Mauro Molinari wrote:

Hi Andrew! This sounds as a lot of work... or, at least, as a lot of studying over the internals of XTS, JBossWS and Axis2... I don't know if we have the resources to do that, at least within the available time frame we have.

Well, it may or may not be a lot of work depending upn how much the Axis2 WS stack differs in its details from JBossWS/CXF and JBossWS/Native. I suspect that only a tiny amount of the code will need many changes but the bits that do might possibly be tricky for you to idenitfy and fix. Have a look and ask questions here if you get stuck.

Mauro Molinari wrote:

By the way, what is https://jira.jboss.org/browse/JBTM-267 about? I can't understand if any action has been taken to close it or not. Anyway, in that bug report you say that Axis2 has no API to manage WS-Addressing properties, although on the net I read it has (http://wso2.org/library/2561 for instance). Just to let you know, if you don't already...

Hmm, that looks like it was closed and marked done by mistake. It should have been closed and marked rejected as not being something we were currently going to pursue. I can reopen it if you want.

Thank you for the link regarding the Axis2 WSA API. This seems to address our needs for setting and getting WSA proeprties and looks lik eit would enable porting of the MAP classes to Axis2. Of course, we would still need to see whether Axis2 WSA implementation correctly handles certain usages, for example whether it will deliver a reply/fault to ReplyTo/FaultTo endpoint rather than via the HTTP back channel. Anyway, this API looks promising.

Mauro Molinari wrote:

I will let you know what we will do. Of course if we succeed to integrate XTS with Axis2 I will let you know to share our experience.

Well, I hope you will also share the code :-). Also, do report on any progress made or problems found, especially the latter in case I can help resolve them quickly.

regards,

Andrew Dinn

[mauromol]

Andrew Dinn ha scritto:

Hmm, that looks like it was closed and marked done by mistake. It should have been closed and marked rejected as not being something we were currently going to pursue. I can reopen it if you want.

Well, for reference to other people, maybe the best solution is to reopen that bug and either keep it open (if you plan to work on it) or close as rejected (if you don't).

Anyway, in my case, we're seriously considering to migrate our infrastructure from Axis2 to Metro. This said, do you think that embedding XTS in this new scenario would be easier or not?

Correct me if I'm wrong, the steps necessary to set up the whole thing (XTS + bridge) is the following:

CLIENT SIDE

- configure the client side header handler: this should be easy, as with Metro we can use the standard JAX-WS handlers provided by XTS

- deploy the WS-AT service: this may be some work to "convert" the SAR provided by XTS to something deployable with Metro

- deploy the WS-C service if we plan to use local coordination: same as above

SERVER SIDE

- configure the service side header handler: this should be easy, as with Metro we can use the standard JAX-WS handlers provided by XTS

- deploy the WS-AT service: this may be some work to "convert" the SAR provided by XTS to something deployable with Metro

- deploy the WS-C service if we plan to use stand-alone coordination (this configuration seems the best for our purpose): same as above, although we also have to setup XTS client-side so that it uses the remote coordination service (is the use of system properties, like described in chapter 7, the only way to do that?)

- configura the bridge handler: again, this should be easy, because we should be able to use the one provided with the bridge

Other questions I would have:

- in XTS documentation it is said that XTS implements version 1.0 and 1.1 of the various protocols of WS-T; however, in the bridge documentation it distinguishes between version 1.0 and 1.2, saying it works only for 1.2; is this an error? Is the bridge supposed to work with the 1.1 protocol version?

- given the fact that XTS does not support subordinate transactions in stand-alone coordination configuration, if we use local coordination how is subordinate transactions supposed to be implemented using the bridge? Should it use nested transactions on JTA side? Anyway, throughout JBossTS JTA documentation, it is often said that JTA does not support nested transactions, although there's a JBossTS configuration option to enable JTA nested transactions; it is not clear to me if, by enabling this option, nested transaction will actually work on JTA side or not

Thanks again in advance for you precious help!

[adinn]

Mauro Molinari wrote:

Well, for reference to other people, maybe the best solution is to reopen that bug and either keep it open (if you plan to work on it) or close as rejected (if you don't).

I'll do the latter then.

Mauro Molinari wrote:

Anyway, in my case, we're seriously considering to migrate our infrastructure from Axis2 to Metro. This said, do you think that embedding XTS in this new scenario would be easier or not?

No, embedding it in Metro will ne harder for two reasons.

Firstly, the WS-T implementation (that's the implementation of the WS-AT and WS-BA protocols plus the completion protocols used by the client to terminate transactions/business activities) need to be able to receive an incoming message whose payload is a SOAP fault. This is required by the WS-T specifications and without it certain aspects of normal operation and crash recovery will not work.

If you check the service WSDL used by the JBoss implementation you can see that it includes these operations. For example, the WS-AT participant service (the service which runs in the same container as the transactional web service) uses the binding in file wsat-participant-binding.wsdl which contains the following lines of relevance:

  <wsdl:import
      namespace="http://docs.oasis-open.org/ws-tx/wsat/2006/06"
      location="wsat.wsdl" />



  <wsdl:binding name="Participant_SOAPBinding" type="wsat:ParticipantPortType">
    <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
    <wsdl:operation name="PrepareOperation">
      <soap:operation soapAction="http://docs.oasis-open.org/ws-tx/wsat/2006/06/Prepare" style="document"/>
      <wsdl:input message="wsat:Prepare">
        <soap:body use="literal"/>
      </wsdl:input>
    </wsdl:operation>

    . . .

      <wsdl:operation name="SoapFault">
        <soap:operation soapAction="http://docs.oasis-open.org/ws-tx/wsat/2006/06/fault"/>
        <wsdl:input message="wsat:SoapFault">
          <soap:body use="literal"/>
        </wsdl:input>
      </wsdl:operation>
  </wsdl:binding>

The imported wsdl contains the following lines of relevance:

  <wsdl:types>
        <xs:schema>
            <xs:import
                namespace="http://www.w3.org/2005/08/addressing"
                schemaLocation="ws-addr.xsd" />
            <xs:import
                namespace="http://docs.oasis-open.org/ws-tx/wsat/2006/06"
                schemaLocation="wsat.xsd" />
            <xs:import namespace="http://schemas.xmlsoap.org/soap/envelope/"
                      schemaLocation="envelope.xsd"/>
        </xs:schema>
    </wsdl:types>
    <!-- Messages -->
    <wsdl:message name="Prepare">
        <wsdl:part name="parameters" element="wsat:Prepare"/>
    </wsdl:message>

    . . .
    <wsdl:message name="SoapFault">
        <wsdl:part name="parameters" element="soapenv:Fault"/>
    </wsdl:message>
    . . .
    <!-- Port Types -->
    <wsdl:portType name="CoordinatorPortType">
        <wsdl:operation name="PreparedOperation">
            <wsdl:input message="wsat:Prepared"/>
        </wsdl:operation>
        . . .
        <wsdl:operation name="SoapFault">
            <wsdl:input message="wsat:SoapFault"/>
        </wsdl:operation>
    </wsdl:portType>
    . . .

Now, one of the problems with using Metro's JaxWS implementation is that it will not deliver an incoming message with a SOAP fault as payload. It assumes that it must be an error response associated with some prior outgoing request and then gets very confused and drops the message. You can try to get the Metro implementors to recognize that this is a problem and fix it. I have tried and got no response.

Metro is not unique in this regard. The current CXF implementation does currently deliver SOAP faults as payload but previous versions have failed to handle this case. It has actually been fixed then broken a couple of times so far. Luckily, JBoss has CXF conributors who have been able to fix if for us when it recently stopped working again (thanks Jim Ma :-). JBossWS Native has managed to retain the ability to deliver faults as payload in all the releases I have tested on,

Secondly, the WS-C and WS-T implementations require that the client coordinator and web service be able to explciitly configure WSA headers on outgoing messages and be abel to collect and process incoming WSA headers. The original JaxWS-WSA JSR-261 draft specification defined an API which allowed JaxWS clients and service implementation beans to have this access to WSA message headers. However, Sun killed this specification, leaving no standard API for a WS-C/T implementor to rely on. Furthermore, they provided no implementation in Metro, standard or non-standard.

So, in order to embed the JBoss code in Metro you will have to provide your own client and server side handlers to mange serilaization and deserialization of the relevant SOAP headers. You will also need to provide code which allows the relevant information to be installed to/read from the JaxWS message context so that the client/server can read or write the Java data which populates these SOAP headers.

Another issue is where to locate this functionality so that the JBoss XTS code can find it. CXF provides all its JaxWS-WSA implementation in package org.apache.cxf.ws.addressing. JBoss/Native provides its implementaton in package javax.xml.ws.addressing. Also, CXF has only provided access to a cut-down version of the WSA RelatesTo header -- only 1 Relationship can be provided in this header. JBossWS/Native has provided a full implementation of the draft API allowing a list of Relationships to be provided. So, JBossWS exports an abstraction class called MAP (plus several related classes such as MAPBuilder) which hide the details of which underlying JaxWS-WSA implementation is being used. If ytou want to embed the JBoss XTS code in Metro then you will need to implement this abstraction library and redirect it to sit over your Metro JaxWS-WSA library.

Mauro Molinari wrote:

Correct me if I'm wrong, the steps necessary to set up the whole thing (XTS + bridge) is the following:

CLIENT SIDE

- configure the client side header handler: this should be easy, as with Metro we can use the standard JAX-WS handlers provided by XTS

- deploy the WS-AT service: this may be some work to "convert" the SAR provided by XTS to something deployable with Metro

- deploy the WS-C service if we plan to use local coordination: same as above

SERVER SIDE

- configure the service side header handler: this should be easy, as with Metro we can use the standard JAX-WS handlers provided by XTS

- deploy the WS-AT service: this may be some work to "convert" the SAR provided by XTS to something deployable with Metro

- deploy the WS-C service if we plan to use stand-alone coordination (this configuration seems the best for our purpose): same as above, although we also have to setup XTS client-side so that it uses the remote coordination service (is the use of system properties, like described in chapter 7, the only way to do that?)

- configura the bridge handler: again, this should be easy, because we should be able to use the one provided with the bridge

Modulo the problems outlined above yes that is what you need to do.

Mauro Molinari wrote:

Other questions I would have:

- in XTS documentation it is said that XTS implements version 1.0 and 1.1 of the various protocols of WS-T; however, in the bridge documentation it distinguishes between version 1.0 and 1.2, saying it works only for 1.2; is this an error? Is the bridge supposed to work with the 1.1 protocol version?

1.2 is a maintenance version of the 1.1 spec which clarified some of the references and terminology but did not redefine any of the behaviour of conformant 1.1 implementations. So, a 1.2 implementation is a 1.1 implementation.

Mauro Molinari wrote:

- given the fact that XTS does not support subordinate transactions in stand-alone coordination configuration, if we use local coordination how is subordinate transactions supposed to be implemented using the bridge? Should it use nested transactions on JTA side? Anyway, throughout JBossTS JTA documentation, it is often said that JTA does not support nested transactions, although there's a JBossTS configuration option to enable JTA nested transactions; it is not clear to me if, by enabling this option, nested transaction will actually work on JTA side or not

Hmm, some terminological disambiguation is required here. "stand-alone" is being used here in a different sense to the one you understand, I think. In the XTS docs a "stand-alone coordinator" is a coordinator running in a different container to the client. When you deploy the XTS sar you need the client libraries and the client participant service but you automatically get all the coordinator services too (you also get the paticipant services but we'll ignore that for now). If you don't do anything then your client will talk to the coordinator in its container when it tries to start a transaction. However, you can point the client at a coordinator running elsewhere. Thsi is usually done by setting System property org.jboss.jbosts.xts.coordinatorURL on the JVM command line. The latter configuration is referred to as "stand-alone coordination" because the coordinator is in a different JVM to the client.

Now, a similar thing is possible with your web service container but there is an important difference. In order to make the web service transactional you need to deploy the participant libraries and the participant end points. However, as with the client you automatically end up deploying the coordinator services in the web service's JVM. Now the web service does not normally initiate a conversation with a coordinator service using its own URL. The SOAP handlers configured on the client and server side ensure that the web service receives a transaction context whenever a web service request is made. This transaction context includes a URL which the WS-T participant code uses to enlist the web service as part of the transaction. The registration response contains another URL whcih identifes the WS-AT coordinator or WS-BA coordinator service. This is stashed away for use when prepare/commit/close etc messages come in.

So, the web service normally talks to whatever service it is told to negotiate with. It does not normally have to provide its own URL. However, there is one case where it does need to do so -- when it wants to interpose a subordinate coordinator between itself and the one provided in the web service request. This is not 'nesting'. It is indirect coordination via an intermediary. If you use the XTS subordinate handler then when a request comes in the WS-T code creates a hiddent participant in the incoming WS-AT/BA transaction and ties it to a local 'subordinate' WS-AT/BA transaction which it creates by talking to its local coordinator service. It then registers the web service in the local transaction. If another web service gets called inside the same remote transaction it is also registered it in the local transaction but it does not need an extra hidden participant.

If, say, this is a WS-AT transaction then the hidden participant responds to an incoming prepare by calling prepare on the local subordinate. This may require the subordinate transaction to make several local prepare calls to the local web services. If they all work the subordinate transaction returns prepared and the hidden participant returns prepared. If it then receives a commit request it commits the lcoal transaction which commits each local participant. SImilarly it can handle an abort by rolling back the local subordinate transacton.

The benefit of using a subordinate transaction is that it only requires one non-local prepare/prepared and one non-local commit/committed even when multiple local web services are enlisted. So, this is just a performance optimization fo ruse when the coordinatro and web servcie are a long distance apart on the intrenet, The line which you are confused by refers to the fact that the subordinate coordinator has to be created by the coordinator service in the same container as the web service. If you set org.jboss.jbosts.xts.coordinatorURL in the web service container to point to a remote coordinator then the hidden participant will never find it and the subordinate transaction will never complete correctly. So, you cannot use stand-alone coordination in combination with subordinate coordinator interposition.

Now, that is not an issue with WS-AT ==> JTA bridging because you are not creating a local WS-AT  transaction inside the incoming remote WS-AT transaction. The JTA transaction which your WS-AT bridges to is created using the local JTA coordinator. But that is what happens whenever yo create a JTA transaction. The bridge code does create a hidden WS-AT participant to prepare/commit/rollback the JTA transaction and to return the results back to it. But your code does nto need to care about that.

Ok, I hope that clears things up for you and anyone else who has managed to read this far :-)

regards,

Andrew Dinn

[mauromol]

Hi Andrew,

thank you very much again for your detailed answer.

Unfortunately, once more this sounds as a too complex task for me: I would need a perfect knowledge of Metro and XTS internals to hope to get them working together in a reasonable amount of time... The whole web service world actually seems like a great jungle to me; even if I've been working on these topics for months now (although for a little part of my job time), many things still give me an impression of lack of reliability and of unpredictability. The web service specifications should have interoperability and compatibility as the primary focus, but in reality every one jumps into the web service arena in his own way. Also documentation is scarce: I think I've learnt more from this topic than from the reading of a lot of "docs" about web services, SOAP, WSDL, Axis2, JAX-WS, etc.. Unless you have to do a dumb "HelloWorld" service, what you find around is a lot of information of little value and very few really valuable documents.

For instance, if you read here:

http://wiki.apache.org/ws/StackComparison

you see that both Axis2 and Metro should support the WS-AT specification: after all our discussion, what does this sentence mean?

Moreover, if you look at:

https://metro.dev.java.net/discover/

and click on Transaction, you'll see that Metro implements WS-Coordination and WS-AtomicTransaction specifications. How this is related to our discussion? Maybe we could in theory avoid the use of XTS? If so, could the bridge work with another implementation of WS-C and WS-AT different from XTS?

Thanks again,

Mauro.

[mauromol]

Andrew Dinn ha scritto:

Metro is not unique in this regard. The current CXF implementation does currently deliver SOAP faults as payload but previous versions have failed to handle this case. It has actually been fixed then broken a couple of times so far. Luckily, JBoss has CXF conributors who have been able to fix if for us when it recently stopped working again (thanks Jim Ma :-). JBossWS Native has managed to retain the ability to deliver faults as payload in all the releases I have tested on,

Hi Andrew!

I'm here again now, because, after long investigations and tests, we are almost sure we'll switch from Axis2 to CXF, rather than Metro. Actually, CXF seems to deliver full JAX-WS compatibility, we can generate Java artifacts from WSDLs using the standard wsimport tool and it can be configured using Spring in a very clean way, even cleaner than that of JAX-WS Commons Spring extension. Moreover, using CXF as a SOAP engine we should have less problems whenever we need to upgrade or to switch from one application server to another (while with Metro care must be taken regarding the possible conflicts between the classes provided by the standard Java6 API and those of the newest versions of the library).

This said... I'm here again to ask for help. Since configuring the handlers seems to be just a configuration thing (using the jaxws:handlers attribute in the endpoint configuration),  which steps do you think I have to follow to try to convert the SARs to standard services deployable with CXF standalone?

Do you think this solution is viable or that there will still be some severe problems?

Thanks in advance,

Mauro.

[adinn]

Hi Mauro,

Mauro Molinari wrote:

This said... I'm here again to ask for help. Since configuring the handlers seems to be just a configuration thing (using the jaxws:handlers attribute in the endpoint configuration),  which steps do you think I have to follow to try to convert the SARs to standard services deployable with CXF standalone?

Do you think this solution is viable or that there will still be some severe problems?

Yes, this is probably viable as a solution but obviously I cannot really guaramtee that you will not run into any showstoppers.

The sar uses a few JBoss features which you will need to replace. Firstly, it provides class loader scoping which makes all classes in the jars in the sar availabel to all the wars in the sar and to all other deployed applications. You can probably arrange to deploy the contents of the sar and your app so as to provide the same visibility e.g. you might be able to bundle XTS as an ear. This might possibly require you to fiddle around with the deployment descriptor (application.xml) used in the sar.

You might also need to provide an alternative to the wars in order to deploy the JaxWS endpoint classes. I assume you will be using Spring to achieve this. Note that the current war config files (web.xml) specify the JaxWS endpoint classes using <servlet> entries, use <servlet-mapping> entries to map them to URL paths (located relative to a base path defined by the war name) and rely on >listener> declarations to perform initialisation associated wiht the listener.

Secondly, the sar uses a beans.xml file to declare a dependency on the JBossTS code and to arrange for JBoss AS to run the start and stop methods associated with class XTSServiceBean in order to initialise and unitialise variosu things in the sar at deployment time. So, you will need to explisitly start the XTS code after starting the TS code and stop it before stopping TS.

If you want to use XTS in a transactional client then you will have to start TS and XTS in the client JVM because the WS-AT CompletionParticipant protocol requires an end point to be running on the client side.

Similarly, if you want to use XTS in your web server to implement a transactional web service then you need to start TS and XTS in the web server JVM.

Othersie, good luck and let me klnow what happens.

[mauromol]

Hi Andrew,

I'm going to do some tests. My idea is the following:

- I have a client, which is a web application

- I have a server, which is another web application that exposes some webservices I want to make transactional

I deploy all the needed XTS services on the client and/or on the server, by doing the following:

- expose the endpoints for all the WS-T services; instead of using the servlet approach declared in the SAR, I use Spring to first call the initialization code defined in the SAR as a servlet listener and then again Spring/CXF to expose the webservices defined in the SAR as servlets

- make all the JARs in the SAR available to both webapps, in WEB-INF/lib; maybe some could be deployed only client-side or only server-side

- deploy the classes XTSService and XTSServiceMBean on both the client and the server and call start() and stop() on the first to start and stop the XTS service respectively (before and after JBossTS Core TxControl.enable/disable).

The first questions I have are the following:

- do I need to start JBossTS on the client using TxControl.enable() (or, better, by just causing the TxControl class to initialize) before initializing XTS or I need just to supply the JBossTS JTA/JTS JAR in the classpath? In my scenario I have a webservice client that needs to call some transactional webservices; these are deployed on a server where the WS-T transaction must be mapped to a JTA transaction. So, on the server side I surely have an active JBossTS JTA installation, but I would not expect to have one on the client too. Maybe this is because XTS just needs some services offered by JBossTS Core? In this case, I guess I can deploy either JBossTS JTA or JBossTS JTS on the client, can I?

- in the SAR I find the following WARs (I choose to deploy only the 1.1 version services):

- ws-c11.war: I suppose this is the Coordinator service, which must be deployed either on the client (for local coordination) or on the server (for stand-alone coordination); our preferred choice would be to deploy it on the server; I see that it has two WDSLs, one for registration and one for activation; I suppose I have to deploy both side-by-side

- wscf11.war: what is it? On the README I find: "The  WSCF  layers on  the  activity  service  (WSAS) by  providing  an appropriate HLS.  Currently this  layering is not transparent in terms of  types  and exceptions  used  from the  WSAS.  We  could hide  this completely."; however I can't understand it properly... In the WAR I find that it just defines a listener in web.xml that calls com.arjuna.mw.wsc11.deploy.WSCFInitialisation; do I need to do this initialization on the client or on the server? Do I have to do it before of after the XTS initialization (which I assume I do using the XTSService class)?

- ws-t11.war:  in this WAR I find four services for WS-AT (I don't care about WS-BA): Coordinator, Participant, CompletionCoordinator and CompletionInitiator; I suppose I have to deploy all of them; do I have to do that on the client or on the server (or on both?)

- wstx11.war: what is it? Its web.xml just defines a servlet listener that does some initialization code (com.arjuna.mw.wst11.deploy.WSTXInitialisation): do I have to call it on the client, on the server or on both? Do I have to call it before or after the initialization of the XTS service?

Sorry if some questions might sound dumb for you, but I'm trying to break all things down in order to re-assemble them piece by piece.

If I will succeed in integrating XTS in our application, I promise I'll write a tutorial (maybe with some source code, if needed) that you may provide together with JBossTS if you wish.

Mauro.

dd

[adinn]

Hi Mauro,

Your plan sounds good. Here are a few comments.

Mauro Molinari wrote:

- do I need to start JBossTS on the client

I don't think so. XTS is built over ArjunaCore and the client component should only need to rely on code which is self-initializing. So having the JBossTS jars in the path should be enough. Similarly, the components whcih ar eonly needed on the web server ought only to need the TS jars  in the path. However, if you want to use bridging in the web server then you need to start JBossTS there anyway.

Mauro Molinari wrote:

- ws-c11.war: I suppose this is the Coordinator service, which must be deployed either on the client (for local coordination) or on the server (for stand-alone coordination); our preferred choice would be to deploy it on the server; I see that it has two WDSLs, one for registration and one for activation; I suppose I have to deploy both side-by-side

Hmm, currently it's not the case that you can just pick and choose which endpoints you deploy. At present the initialization of XTS assumes they are all deployed at the samew time whether the JVM is used to run client code, web server code or WS coordinator code (or any combinaton of these). In particular a class called Seqencer ensures that all the init steps happen in order before the XTSService start method completes.

So, if you want to drop various services from your different deployments then you may have to slice up the initialisation code (invoked via the listeners) so that only certain things get initialized. That will not be hard but it will require making a few changes. I had better explain what needss to run where and you can see whether you can reorganise the init code to achieve what you want.

Let's assume that you have a client in one JVM, a web service in another JVM (or maybe several of these) and a coordinator in another JVM. I'll explain what endponts you need in each for AT or BA to work. Obviously, if for example you colocate a  web service with the coordinator you will need to include both sets of endpoints. You may need to make all the code jars available in all deployments though because there may be some  common types which are needed everywhere.

Here are the WS-C services

Service	Declared In	Deploy in	TS Start
Activation Coordinator	ws-c11.war	Coordinator	Yes
Registration Cordinator	ws-c11.war	Coordinator	Yes

the WS-AT services

Service	Declared In	Deploy in	TS Start
Coordinator	ws-t11.war	Coordinator	Yes
CompletionCordinator	ws-t11.war	Coordinator	Yes
Participant	ws-t11.war	Web Service	No
CompletionParticipant	ws-t11.war	Client	No

and the WS-BA services

	Declared In	Deploy in	TS Start
BAWithParticipantCompletionCoordinator	ws-t11.war	Coordinator	Yes
BAWithCoordinatorCompletionCoordinator	ws-t11.war	Coordinator	Yes
ArjunaTerminationCoordinator	ws-t11.war	Coordinator	No
BAWithParticipantCompletionParticipant	ws-t11.war	Web Service	No
BAWithCooridnatortCompletionParticipant	ws-t11.war	Web Service	No
ArjunaTerminationParticipant	ws-t11.war	Client	No

If you want to selectively deploy these services then you will need to understand the behaviour of class Sequencer. This class is collects callbacks registered by the listener code and then run them under XTSService.start. It enforces a specific startup order (this is cirtical to ensure things initialise correctly) and only proceeds when all the listeners have closed a latch for each of the modules WSCF, WS-C, WS-T and WSTX. So, if you drop a listener in any given JVM or if you drop some of the code it contains you will still need to close the latch.

Mauro Molinari wrote:

- wscf11.war: what is it? On the README I find: "The  WSCF  layers on  the  activity  service  (WSAS) by  providing  an appropriate HLS.  Currently this  layering is not transparent in terms of  types  and exceptions  used  from the  WSAS.  We  could hide  this completely."; however I can't understand it properly... In the WAR I find that it just defines a listener in web.xml that calls com.arjuna.mw.wsc11.deploy.WSCFInitialisation; do I need to do this initialization on the client or on the server? Do I have to do it before of after the XTS initialization (which I assume I do using the XTSService class)?

WSCF (Web Services Coordination Framework) is a generic coordination mechanism which maps coodination requests from in a variety of different coordination protocols to the coordinators which implement the relevant behaviour. It is there because XTS used to support a lot more protocols than WS-AT/BA and also supported pluggable implementations for a given protocol. WSCF relies on a related module WSAS (Web Servcies Activity Service) which provides a general purpose mechanism for managing transactional activities (including activity hierarchies whichi can be used to corodinate nested transactions). These two layers are used by the coordinator services so the WSCFInitialisation listener needs to run as part of XTS startup in the coordinator JVM. n.b.  it uses configuration properties defined in wscf11.xml to plug classes into coordination protocols so you need to deploy thsi config file with it.

Mauro Molinari wrote:

- wstx11.war: what is it? Its web.xml just defines a servlet listener that does some initialization code (com.arjuna.mw.wst11.deploy.WSTXInitialisation): do I have to call it on the client, on the server or on both? Do I have to call it before or after the initialization of the XTS service?

dd

This is the layer that defines and implements the cleint and web services APIs to XTS i.e. UserTransactionFactory, UserTransaction, TransactionManagerFactory, TransactionManager, UserBusinessActivityFactory etc The listener is needed because once again a config file, wstx11.xml, is used to plug classes in as implementations of these API classes. So, this listener needs to run in the web service and client JVMs.

Mauro Molinari wrote:

Sorry if some questions might sound dumb for you, but I'm trying to break all things down in order to re-assemble them piece by piece.

If I will succeed in integrating XTS in our application, I promise I'll write a tutorial (maybe with some source code, if needed) that you may provide together with JBossTS if you wish.

Your questions don't sound dumb. On the contrary you are on the right track. keep up the good work.