[mauromol]

Andrew Dinn ha scritto:

Hmm, I don't see the XTS code using the org.jboss.logging classes. For example, looking at class WSCLogger in 4.11 it is implemented using the LogNoI18n and LogI18n classes from package com.arjuna.common.util.logging. In trunk this class is  implemented using an org.jboss.logging.Logger. Can you point out where 4.11 XTS code is using the org.jboss.logging classes?

Here they are:

jbossts-full-4.11.0.Final-src.zip\JBOSSTS_4_11_0_Final\XTS\sar\src\org\jboss\jbossts\XTSService.java

jbossts-full-4.11.0.Final-src.zip\JBOSSTS_4_11_0_Final\XTS\sar\tests\src\org\jboss\jbossts\xts\servicetests\bean\XTSServiceTestRunnerBean.java

Andrew Dinn ha scritto:

Ok, it sounds to me like you have a lot of good reasons to want the change I proposed. Personally, for all the reasons you specify, I think this change is a 'must have' to enable wider deployment of transactional web service clients. The only option at present is to embed your transactional client in a middleman web service located on a public-facing app server and drive the client via that middleman. In reality, with this change the app client could just as easily run directly on the user's desktop machine, cutting out the middle man.

Yes, exactly!

Andrew Dinn ha scritto:

I intend to implement this protocol upgrade as an option first in a community release of XTS and then possibly in a product release. This will prove whether it is viable and allow us to gauge how valuable  it is. But I will also try to pursue this through the OASIS committee to see if we can get it standardised. I am just as opposed to lock-in as  you are. I'll raise a JIRA for this and also one for the refactoring the initialisation to allow the client, coordinator and participant subsets of the services to be configured independently.

Thanks, once again, for the feedback.

Well, thanks to you! I'm glad I can help in some way.

But now I have a curiosity. Given the fact that I do not consider myself a "cutting edge" software engineer, although with my team we are getting some satisfaction with our recent developments in the distributed transaction area for our web application (leveraging Spring to manage at least two different ORMs, one proprietary and Hibernate the other, with XA database resources then driven by JBossTS JTA, supporting PostgreSQL, Oracle and SQLServer DBMSes), I'm wondering whether I am the first one who is "exploring" this world of web services transactions. It would be surprising, because I find it a quite natural extension of the problem of invoking many operations within a transaction...

Said in other words: what the world out there is doing NOW? Are people relying only on atomic/autocommit web service calls? Or are they using different standards/technologies (CORBA?)?

Mauro.

[mauromol]

Andrew Dinn ha scritto:

Mauro Molinari wrote:

Another little question: as of now the provided wsat-completion-initiator-binding.wsdl has some validation errors because at lines 12 and 19 it defines two  elements, specifying a value for an attribute named "message". However, the schema for WSDL does not allow an attribute called "message", but just "name". Maybe "message" comes from a different namespace? But which?

Hmm,  Thanks for the tip. I'll take a look at that tomorrow.

I forgot to say that even if I configured CXF to expose your provided WSDL (instead of generating a new one), the exposed WSDL does not have the attribute "message" of <wsdl:input> elements: it seems like CXF is throwing it away, because it is not recognized. I don't know if this can lead to problems...

Mauro.

[adinn]

Mauro Molinari wrote:

Another little question: as of now the provided wsat-completion-initiator-binding.wsdl has some validation errors because at lines 12 and 19 it defines two  elements, specifying a value for an attribute named "message". However, the schema for WSDL does not allow an attribute called "message", but just "name". Maybe "message" comes from a different namespace? But which?

. . .

I forgot to say that even if I configured CXF to expose your provided WSDL (instead of generating a new one), the exposed WSDL does not have the attribute "message" of <wsdl:input> elements: it seems like CXF is throwing it away, because it is not recognized. I don't know if this can lead to problems...

Yes, you are right yet again. The port>operation>input/output elements allow for both name and message attributes while the binding>operation>input/output elements only allow name. It appears not  to cause  a problem, probably because it is being ignored and the value specified in the port is used in its place. I'll fix this in trunk.

[adinn]

Mauro Molinari wrote:

Here they are:

jbossts-full-4.11.0.Final-src.zip\JBOSSTS_4_11_0_Final\XTS\sar\src\org\jboss\jbossts\XTSService.java

jbossts-full-4.11.0.Final-src.zip\JBOSSTS_4_11_0_Final\XTS\sar\tests\src\org\jboss\jbossts\xts\servicetests\bean\XTSServiceTestRunnerBean.java

Ok, those look like they jumped the gun in switching to the jboss logger code before everything else did. The XTSService code seems to have done so from when it was created which is bizarre since it was  cloned off TS code by Jonathan and as you noted the TS code does nbot use this logging code.

I am afraid you will either have to modify this code to use the com.arjuna logging classes liek the erst of TS/XTS or else include the jboss logging jar with  your app to resolve these classes. Sorry for that. When you move to 4.12+ you will need ot include the jboss logger code anyway (it's a tiny jar which mostly just delegates ot other code so this is no big deal).

Well, thanks to you! I'm glad I can help in some way.

But now I have a curiosity. Given the fact that I do not consider myself a "cutting edge" software engineer, although with my team we are getting some satisfaction with our recent developments in the distributed transaction area for our web application (leveraging Spring to manage at least two different ORMs, one proprietary and Hibernate the other, with XA database resources then driven by JBossTS JTA, supporting PostgreSQL, Oracle and SQLServer DBMSes), I'm wondering whether I am the first one who is "exploring" this world of web services transactions. It would be surprising, because I find it a quite natural extension of the problem of invoking many operations within a transaction...

Said in other words: what the world out there is doing NOW? Are people relying only on atomic/autocommit web service calls? Or are they using different standards/technologies (CORBA?)?

I think the world of web services is largely split into those who do serious stuff (like Amazon or e-bay) and  use their own highly sophisticated protocols which deal with things way beyond what WS-AT can provide (although not so far beyond WS-BA) and those who use fairly simple  web services which don't employ transactions. We know of a few people who use XTS (including people who pay for support now that it is in our app EAP product) but not many. Obviously they have ot embed their client in JBoss AS.

The only other decent WS-TX implementation I know anything about is the one in IBM's Websphere and I don't know how many people use it. I can believe that there are people who have used it to implement proper transactional web services but this will almost certainly be either i) using an app server to deploy the client or possibly ii) using a proprietary extension like I have outlined to provide a lightweight client. I don't know whether IBM have already done the latter, but I know the IBM WSTX team are more than smart enough to be able to think it up for themselves.

One of the reasons why many web services applications do not use transactions is that WS-AT is really most appropriate for intra-domain transactions i.e. where your company owns all the web services. Transactions are only really useful when your app uses more than one web service. However, if you use WS-AT across company domains then you are a hostage to fortune as far as other guy's services are concerned. If the other guy goes down that can leave your participant wedged between PREPARE and COMMIT holding locks and blocking other transactions. In other words, your throughput is determined by how slow or fragile the other services rather than the quality of your web services.

WS-BA provides a  better model for inter-domain service use because it allows you to commit changes (complete), releasing locks, then clean up later if another service fails (compensate). This deliberatley weakens isolation to improve throughput which is a godo trade-off in the (potentially very) slow world of web services. But WS-BA is much harder to use than WS-AT because bridging to use XA resources is not so simple to do (I'll come back to that in a minute).

Now the flip  side of that ownership issue is that If you are deploying within your own domain you can always organise things so that your web services run together and crash together. You can avoid inconsistency by writing changes for both services in one go at the back end. For example you can delegate all  the updates to a back end JTA transaction. So, WS-AT is not actually solving a real problem when you use multiple intra-domain web services. I think that's one of the main reasons why take-up of WS-TX has been slow.

Now, to return to WS-BA, very near the top of my to do list is to extend the bridging code so that a WSBA transaction can execute web service requests inside a JTA transacion using XA resources and then use another JTA transaction to access XA resources if it has to compensate. This will make WS-BA much easier to use and hence make  it possible to tackle the currentlly neglected case where a client which wants to use web services which span multiple domains. We already have a prototype tool to help resolve this. So, watch this space to see what I come up with in the next few months to do this job properly.

[adinn]

y the way, here are the JIRAs for the changes we discussed:

https://jira.jboss.org/browse/JBTM-776

https://jira.jboss.org/browse/JBTM-777

https://jira.jboss.org/browse/JBTM-778

[mauromol]

Andrew Dinn ha scritto:

One of the reasons why many web services applications do not use transactions is that WS-AT is really most appropriate for intra-domain transactions i.e. where your company owns all the web services. Transactions are only really useful when your app uses more than one web service. However, if you use WS-AT across company domains then you are a hostage to fortune as far as other guy's services are concerned. If the other guy goes down that can leave your participant wedged between PREPARE and COMMIT holding locks and blocking other transactions. In other words, your throughput is determined by how slow or fragile the other services rather than the quality of your web services.

Isn't there a timeout or something else to prevent and recovery these situations? I mean, are the locks held forever / do the different parts (client, coordinator, server) freeze at that time?

The reason for which WS-AT looks so attractive to us (against WS-BA), apart from the possibility to connect it to the JTA transaction through the bridge, is that it doesn't force us to change our business logic/persistence architecture and/or to implement some more or less complex workflows in order to make our web services work/behave correctly. In other words, the web service stack becomes just a mean to call our API code directly from another (remote) application, with just some wrapper code to provide an interface to expose publicly only some things and keep internal some others.

Mauro.

[adinn]

Mauro Molinari wrote:

Isn't there a timeout or something else to prevent and recovery these situations? I mean, are the locks held forever / do the different parts (client, coordinator, server) freeze at that time?

Yes, the coordinator can time out the transaction. However, this usually means waiting some 10s of seconds beyond the normal time for the transaction to complete. The trade-off in setting a timeout is that you want to time out when a host really is down but not when it is suffering a slow connection. Across internet domains this usually requires settings resends at about 5 seconds (that's the default for the initial message resend period in XTS) and timeouts at somwhere upwards of a minute. That's a long time to hold locks if you want to be able to scale to something as small as even a hundred transactions per second.

The reason for which WS-AT looks so attractive to us (against WS-BA), apart from the possibility to connect it to the JTA transaction through the bridge, is that it doesn't force us to change our business logic/persistence architecture and/or to implement some more or less complex workflows in order to make our web services work/behave correctly. In other words, the web service stack becomes just a mean to call our API code directly from another (remote) application, with just some wrapper code to provide an interface to expose publicly only some things and keep internal some others.

Yes, WS-AT is essentially the same protocol as JTA, so you can hide the WS-AT element by bridging from JTA to WS-AT in the client interceptor and then bridging from WS-AT back to JTA in the web service interceptor. Voila, your distributed transaction can be built using components which would also work (almost) identically as a simple JTA transaction if you replaced the web service calls with local calls. But that sort of simple distribution comes at a priice.

WS-BA lowers that price by improving throughput but presents a more complex management model which adds coding and maintenance costs. Even if you bridge the WS-BA transaction to an XA transaction you still you have to i) work out how to compensate actions committed by the participants when something goes wrong and ii) implement code to do that compensation. Our BA Framework prototype targetted these remaining issues to make BA much more attractive. However, it is never going to make the code look almost identical to the original JTA-only version in the way that JTA-WSAT bridging does. You can'thave the performance improvement provided WS-BA gives by relaxing isolation without having to pay the price of coding patch-ups for when things fail. All we can do is reduce that price as far as possible. Two important design goals for our reworking of this framework are i)  to minimise the amount of code which needs ot be added to your app when it is converted to a web service and ii) to decouple the code which manages transacional logic like compensation from the rest of app code so that the use of BA vs AT is as transparent as possible.

[mauromol]

Hi Andrew,

meanwhile I'm going on testing. I'm setting up the participant webapp now. I have a doubt: in our previous discussion (see table) we said that CoordinatorCompletionParticipantInitialisation was needed on the Participant side. However, that "Coordinator" prefix makes me wonder if it shouldn't rather be needed on the Coordinator side.

Moreover, ParticipantCompletionParticipantInitialisation is in a package that suggests it's to be using only in WS-BA, isn't it?

So, I suspect there are some errors in my table...

[mauromol]

Hi again Andrew, I updated my latest table at page 2 adding:

- the webapp for each listener (although it can be derived from the WAR name)

- the sequence for each listener (seems to be the same for all 1.1 protocol listeners)

- the indication whether it's needed for WS-AT or WS-BA; this is specified for each of the side where the listener must be deployed.

Could you please check the correctness of this table?

Thanks in advance!

Mauro.

[mauromol]

Andrew Dinn ha scritto:

The recovery steup in XTSServcie.satr also probably needs splitting up and runnign via listeners so it only gets executed where it is needed. You only need to run recovery code in a container which is executing coordinator services or web service participant services. If your  container only contains client services then you can skip the code in  XTSService.start which registers the recovery listeners.

Do you mean that the recovery code must run either on the coordinator or on the participant exclusively? Or can it run on both sides? What does it happen if this occurs? Will the recovery code of the coordinator or that of the participant be used?

Mauro.

[adinn]

Mauro Molinari wrote:

meanwhile I'm going on testing. I'm setting up the participant webapp now. I have a doubt: in our previous discussion (see table) we said that CoordinatorCompletionParticipantInitialisation was needed on the Participant side. However, that "Coordinator" prefix makes me wonder if it shouldn't rather be needed on the Coordinator side.

No. It's a BA participant service for one of the two type sof BA participant. One of them completes (i.e. commits its changes) when it decides it has done enough work and then waits for a message from the coordinator saying either close or compensate. This is the most optimised for throughput because the client can release locks while other web services may still be serving the client. Hoewever, it implies that the web service request sequence includes a request whcih identifies that this is the last one which will be made.

The other type of participant does nto make its own decision to complete. Instead it waits for the client to decide to close the activity. The coordinator goes round each clien tof this type telling it to complete.. Then the coordinator goes round all clients telling them to clsoe (if everyone completed ok) or to compensate (if somebody failed to complete). This is not quite so good for throughput but it does allow slightly earlier release of locks.

So, the first type of participant is called a participant completion participant because it decides when to complete. The second type of participant is called a coordinator completion participant because it waits for the coordinator to tell it when to complete. Horrible  names but they do do what they say.

Moreover, ParticipantCompletionParticipantInitialisation is in a package that suggests it's to be using only in WS-BA, isn't it?

So, I suspect there are some errors in my table...

Yes, it is a BA participant init routine.

[adinn]

Mauro Molinari wrote:

Could you please check the correctness of this table?

TerminationParticipantInitialisation and TerminationCoordinatorInitialisation are only needed when you deploy WSBA

[adinn]

Mauro Molinari wrote:

Do you mean that the recovery code must run either on the coordinator or on the participant exclusively? Or can it run on both sides? What does it happen if this occurs? Will the recovery code of the coordinator or that of the participant be used?

Some of the redcovery modules need to be run on the coordinator side others on the participant side. It does no harm if  you run both except to slow down recovery a little. The clue as to which are needed where is in the names.

Obviously if you are using interposition in your web service then you also need to deploy the coordinator services inthe web service container. This is the situation where you also need the subordinate recovery modules to be registered. With no interposition you can forget the subordinate modules.

That's in theory.  Just for now I think in practice there may be a synchronization issue if you don't deploy all the modules. I'll check this and get back to you.

[mauromol]

Andrew Dinn ha scritto:

TerminationParticipantInitialisation and TerminationCoordinatorInitialisation are only needed when you deploy WSBA

I've fixed the table, thank you!

[adinn]

Hi Mauro,

I have completed the refactoring of the trunk XTS 1.1. code into client, participant and coordinator deployments and also made it possible to configure initialisation and operation of each of the 3  sets fo component services independently. If you take a look at trunk you will now see that the build script generates 4 web archives

• ws-c11.war
  exposes ActivationCoordinator and RegistrationCoordinator (WS-C) service endpoints for a coordinator container
• ws-t11-coordinator.war
  exposes Coordinator, CompletionCoordinator (WS-AT), ParticipantCompletionCoordinator, CoordinatorCompletionCoordinator, TerminationCoordinator (WS-BA) service endpoints for a coordinator container
• ws-t11-participant.war
  exposes Participant (WS-AT), ParticipantCompletionCoordinator, CoordinatorCompletionCoordinator (WS-BA) service endpoints for a participant container
• ws-t11-client.war
  exposes CompletionInitiator (WS-AT), TerminationParticipant (WS-BA) service endpoints for a client container

Obviously, since you only want AT and not BA your app  will only need to configure the AT service endpoints.

The web.xml for these wars no longer employs listeners to perform initialisation. Instead all initialisation is performed via XTSService.start. In JBoss this initialisation is configured using a jboss-beans.xml file which injects the necessary settings into the configuration objects referred to by the XTS runtime. However, it is also possible to deploy a properties file or set system properties to drive the configuration process. Since you want to deploy outside of JBoss I'll explain here how to modify the properties file. Obviously the process is very similar for the beans file.

n.b. the jboss beans file gets added to the sar automatically by the build  process. If you want to configure using the xts properties file then you need to deploy the properties file with your app. XTS tries to load the properties file using ClassLoader.getResourceAsStream(String). The classloader it uses is the loader for a class in ws-c11.jar and the supplied argument is "xts-properties.xml". So, if you are using the 1.1 file mentioned above you will need to store it in the classpath under this name so that the XTS code can find it.

The primary configuration property defines a list of initialisation classes which, by default, contains 3 entries, one for each component. Actually, since this is a list value we collect all properties with a common prefix to idenitfy the sequence of list values. You can edit this property set to remove any unwanted components for one of your deployments. Here are the default settings

<entry  key="org.jboss.jbossts.xts.initialisation.xtsInitialisation_1">org.jboss.jbossts.xts.initialisation.CoordinatorSideInitialisation</entry>
     <entry  key="org.jboss.jbossts.xts.initialisation.xtsInitialisation_2">org.jboss.jbossts.xts.initialisation.ParticipantSideInitialisation</entry>
     <entry  key="org.jboss.jbossts.xts.initialisation.xtsInitialisation_3">org.jboss.jbossts.xts.initialisation.ClientSideInitialisation</entry>

Each entry specifies an initiialisation class which must implement interface XTSInitialisation. This interface declares a startup and shutdown method. XTSService.start creates an instance of each class during startup and calls the startup method. It also calls the shutdown methods in reverse order when XTSServiice.shutdown is called. Note that the ASCII sort order for the key determines the list order

Further configuration allows you to select which elements of a deployed component are initialised eg. you can avoid loading the BA services in the coordinator container or the BA client API classes in the client container. Here are the details:

    <entry key="org.jboss.jbossts.xts11.wsat.UserTransaction">com.arjuna.mwlabs.wst11.at.remote.UserTransactionImple</entry>
    <entry key="org.jboss.jbossts.xts11.wsba.UserBusinessActivity">com.arjuna.mwlabs.wst11.ba.remote.UserBusinessActivityImple</entry>

The client side initialisation code uses these properties to determine which classes to load to implement the UserTransaction and UserBusinessActivity API classes. If you don't need BA then you can drop the 2nd property and the BA code will not be loaded. Any attempt to use the BA  API will fail with an exception.

    <entry key="org.jboss.jbossts.xts11.wsat.TransactionManager">com.arjuna.mwlabs.wst11.at.remote.TransactionManagerImple</entry>
    <entry key="org.jboss.jbossts.xts11.wsba.BusinessActivityManager">com.arjuna.mwlabs.wst11.ba.remote.BusinessActivityManagerImple</entry>

The participant side initialisation code uses these properties to determine which classes to  load to implement the TransactionManager and BusinessActivityManager API  classes. If you don't need BA then you can drop the 2nd property and the  BA code will not be loaded. Any attempt to use the BA API will fail with an exception.

Actually, the client side init will also load the Manager classes if they are configured because it is possible that a client may want to suspend and then later resume a transaction and that function is only available via the Manager API (bridge code will want  to do this).

<entry key="org.jboss.jbossts.xts.protocolImplementation1">com.arjuna.mwlabs.wscf11.model.twophase.arjunacore.TwoPhaseHLSImple</entry>
    <entry key="org.jboss.jbossts.xts.protocolImplementation2">com.arjuna.mwlabs.wscf11.model.sagas.arjunacore.SagasHLSImple</entry>
    <entry key="org.jboss.jbossts.xts.protocolImplementation3">com.arjuna.mwlabs.wst11.at.ContextFactoryImple</entry>
    <entry key="org.jboss.jbossts.xts.protocolImplementation4">com.arjuna.mwlabs.wst11.ba.ContextFactoryImple</entry>

The coordinator side initialisation code uses these properties to determine which WS-T coordination protocol services to load. The two with at in the name are for WS-AT. The other two are for BA (teh BA model is also known as a SAGA model). You can drop the BA entries and no attempt will be made to initialise the BA coordinator service implementation.

<entry key="org.jboss.jbossts.xts.recovery.coordinatorRecoveryModule1">org.jboss.jbossts.xts.recovery.coordinator.at.ATCoordinatorRecoveryModule</entry>
    <entry key="org.jboss.jbossts.xts.recovery.coordinatorRecoveryModule2">org.jboss.jbossts.xts.recovery.coordinator.at.SubordinateATCoordinatorRecoveryModule</entry>
    <entry key="org.jboss.jbossts.xts.recovery.coordinatorRecoveryModule3">org.jboss.jbossts.xts.recovery.coordinator.ba.BACoordinatorRecoveryModule</entry>
    <entry key="org.jboss.jbossts.xts.recovery.coordinatorRecoveryModule4">org.jboss.jbossts.xts.recovery.coordinator.ba.SubordinateBACoordinatorRecoveryModule</entry>

    <entry key="org.jboss.jbossts.xts.recovery.participantRecoveryModule1">org.jboss.jbossts.xts.recovery.participant.at.ATParticipantRecoveryModule</entry>
    <entry key="org.jboss.jbossts.xts.recovery.participantRecoveryModule2">org.jboss.jbossts.xts.recovery.participant.ba.BAParticipantRecoveryModule</entry>

These entries configure loading and regisration of recovery modules. They should be left undefined in a client only deployment. Obviously, you can drop the BA ones. You can also drop the participant ones on the coordinator side and the coordinator ones on the participant side.

The subordinate modules are needed to manage interposition in a web service participant container but that implies that you also need the coordinator services deployed.They are also needed if you use JTA to AT bridging on the client side which would also require deployment of the coordinator services. They are not needed if you are using WSAT to JTA bridging on the participant side which is what you want.

    <entry key="org.jboss.jbossts.xts11.bind.address">localhost</entry>
     <entry key="org.jboss.jbossts.xts11.bind.port">8080</entry>
     <entry key="org.jboss.jbossts.xts11.bind.port.secure">8443</entry>

These properties apply to all 3 deployments telling the services what hostname and port to use. So, you need to specify the address your CXF bus is listening on and the port being used for http and https conections.

    <entry key="org.jboss.jbossts.xts11.coordinatorURL">http://localhost:8080/ws-c11/ActivationService</entry>
    <entry key="org.jboss.jbossts.xts11.coordinator.scheme">http</entry>
    <entry key="org.jboss.jbossts.xts11.coordinator.address">localhost</entry>
    <entry key="org.jboss.jbossts.xts11.coordinator.port">8080</entry>
    <entry key="org.jboss.jbossts.xts11.coordinator.path">ws-c11/ActivationService</entry>

These properties are only relevant in the client container. The coordinatorURL property can be set to point the client at a coordinator in a remote container. If it is set the others are ignored. If it is left unset then the remaining proeprties ar eused to construct a URL defaulting any unset values using the values listed above. So, if you are using a JBoss coordinator on a remote host with address coordinator.my.org you can just set the org.jboss.xts11.coordinator.address property to "coordinator.my.org" and your client will talk to that host using the full URL "http://coordinator.my.org:8080/ws-c11/ActivationService".

I have only tested this with one config so far -- client and web server in one container (running the xts demo) and coordinator in another. It worked fine. I am working on reorganising the demo code to allow deployment of separate webapps for the client and web service code so I can try the other configurations. I will also try to check that WSAT to XA bridging works ok in the participant container.