I changed CompletionInitiatorPortTypeImpl so that it takes handlers.xml (I had to move it from the root of the classpath, to avoid conflicts with other handlers.xml I might need to add).

I also had to edit ws-addr.xsd (imported by one of the WSDLs of the CompletionInitiator) to remove the DOCTYPE declaration, otherwise CXF generates an NPE when it is asked for it (I filed a bug for this: https://issues.apache.org/jira/browse/CXF-2919).

So far it seems to work fine, although I've just realized that I forgot to invoke the com.arjuna.webservices11.wsat.server.CoordinatorInitialisation code (I'll do then).

Anyway, I put org.jboss.jbossts.XTSService and org.jboss.jbossts.XTSServiceMBean in the src of my project and tried to start the XTS service through org.jboss.jbossts.XTSService.start(). The first issue is that it needs a bindaddress: what is it used for on the client? I mean, can I use "localhost"? If it is published so that other services must reach the CompletionInitiator through that address, I can't use localhost there of course.

Another problem is that I had to replace org.jboss.logging.Logger with a Log4j (or JDK) logger, because I don't know where to find org.jboss.logging.Logger and I think I don't really need it.

Apart from this, I started to have some initialization problems because of what you explained about the start/Sequencer issue. I see that I have to tweak the XTSService code a bit to select just the initialization I need.

Tomorrow I'll leave for a couple of weeks of vacation. When I get back I'll carry on my tests.

So far it seems to work fine, although I've just realized that I forgot to invoke the com.arjuna.webservices11.wsat.server.CoordinatorInitialisation code (I'll do then).

Anyway, I put org.jboss.jbossts.XTSService and org.jboss.jbossts.XTSServiceMBean in the src of my project and tried to start the XTS service through org.jboss.jbossts.XTSService.start(). The first issue is that it needs a bindaddress: what is it used for on the client? I mean, can I use "localhost"? If it is published so that other services must reach the CompletionInitiator through that address, I can't use localhost there of course.

JBossWS requests injection of the App Server's bind address (i.e. the address it opens sockets on) and the http and https port numbers from JBoss Web (that's our patched tomcat) using dependency injection provided by the JBoss AS microcontroller. It uses them to generate URLs for, amongt other things, the XTS service endpoints.

So, XTSServiceBean also ontains these same values from JBoss Web and uses them to reconstruct the same URLs -- see the beans.xml which goes into the sar if you want to understand how the injection is wired. n.b. this needs to happen in all the JVMs (client/webservice/coordinator) since they all deploy endpoints and so they all need to install addresses in their local service registry.

XTSService.start() makes the injected address/port values available to the service implementation code by setting system properties. The various different listeners read these properties and install their (http and https) endpoint URLs into the service registry. If your endpoints are published using different paths you may need to tweak the code which constructs these URLs. Amongst other things Sequencer makes sure the listeners do not install their addresses before these system properties have been set by XTSService.

n.b. if the listeners don't detect any system propertiy settings for these values they default to localhost, 8080 and 8443.

Mauro Molinari wrote:

Another problem is that I had to replace org.jboss.logging.Logger with a Log4j (or JDK) logger, because I don't know where to find org.jboss.logging.Logger and I think I don't really need it.

If you can deploy JBossTS then you should have the necessary logging code available. It also uses org.jboss.logging.Logger.

Mauro Molinari wrote:

Apart from this, I started to have some initialization problems because of what you explained about the start/Sequencer issue. I see that I have to tweak the XTSService code a bit to select just the initialization I need.

You wil have to fork some of the listener code so that you always shut each module's Sequencer gate on all JVMs even if you don't need the initialization done on that JVM.

For example on the client you need to run the call to Sequencer.close() at the bottom of the WS-C listener's CoordinationInitialisation.contextInitialized() method even though you don't need to register the callback to set up the processors for the AC and RC services.

Anyway, looks like you are making good progress. I think it might be useful to refactor the code so as to make what you are doing easier to achieve so I'll keep watching over your shoudler if you don't mind :-)

JBossWS requests injection of the App Server's bind address (i.e. the address it opens sockets on) and the http and https port numbers from JBoss Web (that's our patched tomcat) using dependency injection provided by the JBoss AS microcontroller. It uses them to generate URLs for, amongt other things, the XTS service endpoints.

Ok, this is clear, thank you.

Andrew Dinn ha scritto:

If you can deploy JBossTS then you should have the necessary logging code available. It also uses org.jboss.logging.Logger.

Actually, I can't find Logger.java in the whole jbossts-full-4.11.0.Final-src.zip package. From a quick inspection, it seems to me that JBossTS is now using classes from common/classes/com/arjuna/common/util/logging and the corresponding internal ones.

I also searched in JBossWS sources but I couldn't find it. Nor I could find a project named "JBoss Logger" or something like that...

Andrew Dinn ha scritto:

You wil have to fork some of the listener code so that you always shut each module's Sequencer gate on all JVMs even if you don't need the initialization done on that JVM.

For example on the client you need to run the call to Sequencer.close() at the bottom of the WS-C listener's CoordinationInitialisation.contextInitialized() method even though you don't need to register the callback to set up the processors for the AC and RC services.

I still find hard to understand this part, maybe because I have to revise what a latch is :-)

Anyway, from my previous message these are the things that I did on the client side:

- added the listener test.CompletionInitiatorInitialisationEx which extends com.arjuna.webservices11.wsat.server.CompletionInitiatorInitialisation to my webapp web.xml in order to register the callback for the CompletionInitiator initialization; my extension simply adds Sequencer.close(Sequencer.SEQUENCE_WSCOOR11, Sequencer.WEBAPP_WST11) after the callback registration; this is done because I'm not deploying the com.arjuna.wst11.messaging.deploy.TransactionInitialisation which seems the one it is actually closing that sequence in the XTS original code; do I need to deploy this service? [*]

- added the listener com.arjuna.mw.wst11.deploy.WSTXInitialisation to my webapp web.xml, because you said it is needed on both client and server to initialize the XTS API

- added the following JARs in WEB-INF/lib, because they are needed by the recovery module: wscf.jar and ws-t.jar

For rows where I put "???", it means I don't know exactly where to deploy. Apart from that, is this table right?

Another (dumb) question: now there are different listeners of the SAME webapp that are registering callbacks and closing sequences using different int identifiers like there were more different webapps that participate in the initialisation sequence. Is this a problem? I would say it isn't... I hope :-)

Another question: I'm not going to use BA. Can I leave all that BA Recovery Module configuration stuff in XTSService or should I better remove it?

Actually, I can't find Logger.java in the whole jbossts-full-4.11.0.Final-src.zip package. From a quick inspection, it seems to me that JBossTS is now using classes from common/classes/com/arjuna/common/util/logging and the corresponding internal ones.

I also searched in JBossWS sources but I couldn't find it. Nor I could find a project named "JBoss Logger" or something like that...

Looking in my latest installed JBoss I found class org.jboss.logging.Logger in jboss-logging.jar. This is available from the JBoss maven repo.You won't be able to use teh TS or XTS code unless you deploy this with your app as both of them use it. It can be cofnigured to indirect to whatever logging framework you want to plug in

Andrew Dinn ha scritto:

You wil have to fork some of the listener code so that you always shut each module's Sequencer gate on all JVMs even if you don't need the initialization done on that JVM. . . .

I still find hard to understand this part, maybe because I have to revise what a latch is :-)

This is something I invented (a latch is a piece of metal on a door or gate which has to be lifted before it can be opened) The problem that I faced is that there is no guarantee that the XTS service start routine runs before (or after) the servlet listeners nor that the listeners run in a specifix order. JBoss actually defines an order but it does nto gaurantee that it will be followed in all releases. Other containers amy do things in diferent order. However, the way the initialisation is currenlty organised it is very important that thinghs get called in the correct order.

Class Sequencer resolves this by allowing the listeners for 1.0 and 1.1 to register callbacks into a sequence of lists on for each of the 1.0 and 1.1 modules. So, each sequence contains callback lists for WS-C, WSCF, WS-T and WSTX. None of the callabcks can be executed until all lists in the sequence has been closed. When a listener thread closes the final list in a sequence each list of callbacks is executed in the order given above. However, there is also a global latch used by the XTS Service start routine. If teh latch has been opened the callbacks are run by the listener thread. If it is still closed then the callbacks are delayed even when all the lists are clsoed. Instead they get run by the thread running the Service start routine at the point when it opens the latch. It's very simple and neat and no harder to follw than any other multi-threaded code :-]

By the way, I have been cleaning up the XTS code for some weeks now (in between other jobs). Last week I managed to sort out all the configuraton code and this also greatly simplified the startup code. If you are able to switch to using the latest XTS code this may help you enormously. It cretainly makes a lot of things clearer.

The configuraton is now defined jsut as per JBossTS. So, inside the AS all configuration is performed by the JBoss micro-container injecting values defined in a jboss-beans.xml file. However, it is possible to use a single properties file to configure all the XTS code for use outside of JBoss AS.

I don't think I have yet cleaned up the code enough to allow all the client, web server and corodinator initialisation to be completely separated but I have got a lot closer to that. I'm continuing to work on this because it also makes it easier to ensure that the XTS code uses less resources and is easier to maintain.

Anyway, from my previous message these are the things that I did on the client side:

- added the listener test.CompletionInitiatorInitialisationEx which extends com.arjuna.webservices11.wsat.server.CompletionInitiatorInitialisation to my webapp web.xml in order to register the callback for the CompletionInitiator initialization; my extension simply adds Sequencer.close(Sequencer.SEQUENCE_WSCOOR11, Sequencer.WEBAPP_WST11) after the callback registration; this is done because I'm not deploying the com.arjuna.wst11.messaging.deploy.TransactionInitialisation which seems the one it is actually closing that sequence in the XTS original code; do I need to deploy this service? [*]

- added the listener com.arjuna.mw.wst11.deploy.WSTXInitialisation to my webapp web.xml, because you said it is needed on both client and server to initialize the XTS API

- added the following JARs in WEB-INF/lib, because they are needed by the recovery module: wscf.jar and ws-t.jar

Well, you obviously worked out what to do with the Sequencer code even without my explanation. You can drop TransactionInitialisation in a WSAT client-only container -- it configures up coordinator, participant and WSBA client services. Here's the table of which listener does what:

<removed because the format is so awful>

One of the changes I made last week was to add a separate listener to make the call to Sequencer.close(). So, for example, I took the call out of the wsc11 CoordinatroInitialisation listener and put it onto WSCCloseInitialisation. That way you can add or remove things specific to the container without removing the close. I shoudl also split up the code in TransactionInitialisation into 3 separate listeners.

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.

Another (dumb) question: now there are different listeners of the SAME webapp that are registering callbacks and closing sequences using different int identifiers like there were more different webapps that participate in the initialisation sequence. Is this a problem? I would say it isn't... I hope :-)

A dumb question is only dumb when you have already been told the answer. No, this is no problem. For each sequence (1.0/1.1) and each webapp (WS-C, WS-T etc) the listeners can register as many callbacks as they like. The last listener in each web.xml must close the list. The Sequencer code ensures that each list of callbacks gets processed in sequence order and that callbacks are executed in order of registraton (listeners in a specific web.xml are executed in the order they are declared so the callbacks in a specific list are called in web.xml order). You can delete listeners from the web.xml if you want but you shoudl not change the order they are declared in.

Isn't this needed on Participant (web service) side too? In one of your previous messages regarding the WSTX component you said:

Andrew Dinn ha scritto:

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.

Looking in my latest installed JBoss I found class org.jboss.logging.Logger in jboss-logging.jar. This is available from the JBoss maven repo.You won't be able to use teh TS or XTS code unless you deploy this with your app as both of them use it. It can be cofnigured to indirect to whatever logging framework you want to plug in

Hmmm... I can state for sure that JBossTS JTA is working properly without that JAR in our web application. Please note that our web application is configuring Commons Logging to use Log4j. Anyway, I can't find any reference to org.jboss.logging.Logger in any of the classes in the whole JBossTS Full 4.11 Final src bundle, except for org.jboss.jbossts.XTSService and org.jboss.jbossts.xts.servicetests.bean.XTSServiceTestRunnerBean...

Andrew Dinn ha scritto:

By the way, I have been cleaning up the XTS code for some weeks now (in between other jobs). Last week I managed to sort out all the configuraton code and this also greatly simplified the startup code. If you are able to switch to using the latest XTS code this may help you enormously. It cretainly makes a lot of things clearer.

This is good news, however at first this can be a problem for me. I mean, I would prefer to work with a released version of the full JBossTS JTA+XTS package. Now we're at 4.11, your enhancements will be useful when switching to 4.12 (if this is the target). By the way, do you have any candidate release date for 4.12?

Andrew Dinn ha scritto:

The configuraton is now defined jsut as per JBossTS. So, inside the AS all configuration is performed by the JBoss micro-container injecting values defined in a jboss-beans.xml file. However, it is possible to use a single properties file to configure all the XTS code for use outside of JBoss AS.

I don't think I have yet cleaned up the code enough to allow all the client, web server and corodinator initialisation to be completely separated but I have got a lot closer to that. I'm continuing to work on this because it also makes it easier to ensure that the XTS code uses less resources and is easier to maintain.

This is great. If I can add a suggestion, it would be great if the whole thing would be changed so that a deployment like mine (i.e.: outside JBossAS, on another application server and/or embedded into a web application) could be easily achieved without changing XTS code, because these kind of changes are hard to mantain when updating to a new JBossTS version.

As of now, these are the parts where I have (or will have) to change something:

- changes to the initialization phase in order to close sequences: as far as I understand, this is exactly what you are working on

- changes to XTSService for the recovery initialization part: it would be great to enable/disable the individual recovery modules via properties

- changes to XTSService to remove org.jboss.jbossts.XTSService: seriously, this is still a mysterious thing to me... the whole JBossTS JTA works without that class, why does XTSService import it? Shouldn't the XTSService use the Arjuna Common Logging Framework component for logging?

- changes to the endpoint implementation classes to edit the @HandlerChain annotation: as of now, all these annotations point to "/handlers.xml"; this causes problems when you deploy more than one endpoint in the same web application; something more specific for each service would help here (eg: "/CompletionInitiator-handlers.xml" for CompletionInitiatorPortTypeImpl, "/Participant-handlers.xml" for ParticipantPortTypeImpl, etc.). Unfortunately, when I deploy the SEI in my own way (i.e.: Spring+CXF), I can override the @WebService annotation parameter values, but I cannot override the @HandlerChain (although I can add more handlers), so right now I must change the source code.

Another great improvement would be to implement the whole initialization and configuration code so that it could be called programmatically or through Spring with a higher-level interface; then, the webapp listeners to be set in web.xml would be just one of many options to call that code to intitialize XTS properly. One may choose to use Spring to do that, instead: in this way I wouldn't have to change the web.xml of my web application, which is already crowded enough. Moreover, providing a higher level interface to configuration, XTS upgrades would be easier: as of now, if you remove a listener or change its name, I have to know that, so that I can update my webapp web.xml accordingly when upgrading. This can become hard to maintain over time.

Once this is done, the XTS binary bundle could provide a set of WARs to easily deploy the different services on JBossAS (like now), but also a set of JARs needed to run the whole thing; best of all would be to have a map of which JARs are needed on which side (client, participant, coordinator). These JARs should also contain the different handler chains XMLs (right now I find them only in the WARs), so that by deploying the JARs in WEB-INF/lib I could expose the different XTS endpoints outside JBossAS without even looking at the WARs. However, the binary bundle should also provide an organized tree containing the WSDLs, because these must be deployed somewhere else in WEB-INF (outside WEB-INF/classes, usually WEB-INF/wsdl or such). Right now, I find WSDLs only in the WARs, too.

Said in other words: it would be great if the WAR/SAR bundles became just a "bonus" of the binary bundle to easily deploy XTS on JBossAS, but the same result could be obtained without even looking at them.

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?

No, not the only one. But you shodl have seen it a few months ago -- it was much worse then.

By the way:

Andrew Dinn ha scritto:

wstx11.war

Clientcom.arjuna.mw.wst11.deploy.WSTXInitialisation

Isn't this needed on Participant (web service) side too? In one of your previous messages regarding the WSTX component you said:

Andrew Dinn ha scritto:

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.

Oops, yes, that's right. The WSTX initialisation is needed to ensure that when you call UserTransaction.getUserTransaction you get back an instance which implements UserTransaction rather than null (it's actually an instance of UserTransactionImple). Similarly, for TransactionManager. You normally only need UserTransaction on the client and TransactionManager on the web server but there are circumstances where you may need both on the client or the web server. Thanks for spotting that.

Hmmm... I can state for sure that JBossTS JTA is working properly without that JAR in our web application. Please note that our web application is configuring Commons Logging to use Log4j. Anyway, I can't find any reference to org.jboss.logging.Logger in any of the classes in the whole JBossTS Full 4.11 Final src bundle, except for org.jboss.jbossts.XTSService and org.jboss.jbossts.xts.servicetests.bean.XTSServiceTestRunnerBean...

Hmm, I think that's maybe because you are looking at JBossTS 4.11 -- the logging change may have happened later than that. Are you looking at a later version fo XTS?

This is good news, however at first this can be a problem for me. I mean, I would prefer to work with a released version of the full JBossTS JTA+XTS package. Now we're at 4.11, your enhancements will be useful when switching to 4.12 (if this is the target). By the way, do you have any candidate release date for 4.12?

4.12 is tagged already. You can find it in the svn repo. Unfortunately, my updates to XTS will be going into 4.13 -- don't yet know when that will be released. Probably a couple of months from now.

This is great. If I can add a suggestion, it would be great if the whole thing would be changed so that a deployment like mine (i.e.: outside JBossAS, on another application server and/or embedded into a web application) could be easily achieved without changing XTS code, because these kind of changes are hard to mantain when updating to a new JBossTS version.

. . .

I hope I've given some useful ideas.

Yes, thank you bery much. This is just the sort of feedback I need and I will try to work the coe round to doing this for 4.13. I'm sorry you have had to be the gunea pig in this experiment to allow these requriements to be clarified. I hoep the payback will be that we can get to where you need to be and then stay there as XTS is upgraded.

I have one other idea for an improvement which will help on the client side. I would be interested to hear what you thnk.

At the moment a CXF only client needs to expose a CompletionParticpant endpoint because the completion protocol uses two one way messages to commit or rollback rather than an RPC. I would like to add an extra coordination protocol on the coordinator side which provides an alternative verison of CompletionCoordinator that expects an RPC MEP. I could then provide a config option so that the WSAT client can be switched to use this protocol.

The benefit of this is that the client app will not have to expose an endpoint. It only needs to use HTTPClient code. So, you get a simple, lightweight client. The downside is that this alternative Completion protocol will only run if you deploy teh JBoss XTS code to your coordinator. You will not be able to talk to e.g. a Microsoft coordinator. Of course, if this works and is useful we might be able to upgarade the WS-T protocols to include this alternative version of the Completion servcie but that's a long haul. For now I woudl just liek to know if this woudl be helpful to you

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?

Hmmm... I can state for sure that JBossTS JTA is working properly without that JAR in our web application. Please note that our web application is configuring Commons Logging to use Log4j. Anyway, I can't find any reference to org.jboss.logging.Logger in any of the classes in the whole JBossTS Full 4.11 Final src bundle, except for org.jboss.jbossts.XTSService and org.jboss.jbossts.xts.servicetests.bean.XTSServiceTestRunnerBean...

Hmm, I think that's maybe because you are looking at JBossTS 4.11 -- the logging change may have happened later than that. Are you looking at a later version fo XTS?

No, I'm using both JBossTS JTA and JBossTS XTS from the 4.11 Final bundle.

Andrew Dinn ha scritto:

I have one other idea for an improvement which will help on the client side. I would be interested to hear what you thnk.

At the moment a CXF only client needs to expose a CompletionParticpant endpoint because the completion protocol uses two one way messages to commit or rollback rather than an RPC. I would like to add an extra coordination protocol on the coordinator side which provides an alternative verison of CompletionCoordinator that expects an RPC MEP. I could then provide a config option so that the WSAT client can be switched to use this protocol.

The benefit of this is that the client app will not have to expose an endpoint. It only needs to use HTTPClient code. So, you get a simple, lightweight client. The downside is that this alternative Completion protocol will only run if you deploy teh JBoss XTS code to your coordinator. You will not be able to talk to e.g. a Microsoft coordinator. Of course, if this works and is useful we might be able to upgarade the WS-T protocols to include this alternative version of the Completion servcie but that's a long haul. For now I woudl just liek to know if this woudl be helpful to you

Are you (the JBossTS team) directly involved in defining the WS-T protocols? :-)

Anyway, my humble opinion is this: the web service world is a very cool and attractive one, because it emphasizes standards and interoperability, but in the real world I find it a real mess. The implementations are often incomplete or don't behave as expected, there are a lot of aspects not well covered by the standard specifications and making a web service (either client or server) is often a complex task and involves writing or generate meta-data (WDSLs), wiring configuration and generating artifacts that need to be manually updated every time something in the contract changes. This said, the good old RPC may be much more easy to work with, so your idea would surely help to make things a bit simpler. Moreover, as you point out, it's quite surprising (at a first thought, at least) to discover that you have to deploy a web service on the CLIENT in order to make it able to call other web services transactionally. This implies:

- the client should be exposed: while the "server" is a "server" by definition, so it must be recheable, a typical client may not; often, a client may be operating behind a NAT and/or firewall

- the client should have a well-known address to be recheable: the problem is similar as above, because often a client may be a system which uses a dynamic IP address; if I have to specify a bind-address in the configuration in order to make the CompletionParticipant endpoint recheable by the coordinator, I can't use a configuration-fixed bind-address in this cases, so the WS-T implementation should be smart enough to gather this information dynamically by itself and this might not be so simple to implement, because the possible client system specific configuration might be unpredictable

- the client should be not only able to make SOAP calls (to invoke services), but also to serve them; this might cause the client to be equipped with even more libraries and this could be a problem if it is not a web/JEE application itself, but rather a lightweight client (an app on a mobile device, for instance)

This said, a solution that solves these problems may be desirable, but there are some things to consider.

First of all, if this solution only works if XTS is deployed on the coordinator, it misses one key aspect of web services, interoperability. So, making this solution a standard would be the best thing, however this could need a lot of time (while often people need to write applications TODAY).

For this reason, now this solution (if working properly) could be just a nice "plus" for whoever is going to use XTS as an implementation, but if the client also needs to invoke other transactional web services on other remote systems (some of which may not use XTS), then the client itself must also provide the standard CompletionParticipant support. This could lead to an even more complex client configuration and setup.

Maybe the very best solution would be to remove the need of the client to be reachable at all, but I think you already studied the problem in great depth and determined that it's not possible.

No, I'm using both JBossTS JTA and JBossTS XTS from the 4.11 Final bundle.

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?

Are you (the JBossTS team) directly involved in defining the WS-T protocols? :-)

Yes, I'm a member of the OASIS WS-TX committee. More importantly, our CTO and director of standards, Mark Little, (who usually sits about 15 feet from me) is the main JBoss representative on the OASIS WS-TX committee. Mark has been involved in defining transaction standards for about 20 years (yes, seriously) and he had a large part to play in getting the WS transaction standards to where they are now. So, if we can present a case that there is demand for this as an upgrade to the standard and show that it works in practice then it may well be possible to get it accepted. It's not exactly a contentious change. What I need from you or anyone else who might want this is evidence that there is demand for it.

Anyway, my humble opinion is this: the web service world is a very cool and attractive one, because it emphasizes standards and interoperability, but in the real world I find it a real mess. The implementations are often incomplete or don't behave as expected, there are a lot of aspects not well covered by the standard specifications and making a web service (either client or server) is often a complex task and involves writing or generate meta-data (WDSLs), wiring configuration and generating artifacts that need to be manually updated every time something in the contract changes. This said, the good old RPC may be much more easy to work with, so your idea would surely help to make things a bit simpler. Moreover, as you point out, it's quite surprising (at a first thought, at least) to discover that you have to deploy a web service on the CLIENT in order to make it able to call other web services transactionally. This implies:

- the client should be exposed: while the "server" is a "server" by definition, so it must be recheable, a typical client may not; often, a client may be operating behind a NAT and/or firewall

- the client should have a well-known address to be recheable: the problem is similar as above, because often a client may be a system which uses a dynamic IP address; if I have to specify a bind-address in the configuration in order to make the CompletionParticipant endpoint recheable by the coordinator, I can't use a configuration-fixed bind-address in this cases, so the WS-T implementation should be smart enough to gather this information dynamically by itself and this might not be so simple to implement, because the possible client system specific configuration might be unpredictable

- the client should be not only able to make SOAP calls (to invoke services), but also to serve them; this might cause the client to be equipped with even more libraries and this could be a problem if it is not a web/JEE application itself, but rather a lightweight client (an app on a mobile device, for instance)

This said, a solution that solves these problems may be desirable, but there are some things to consider.

First of all, if this solution only works if XTS is deployed on the coordinator, it misses one key aspect of web services, interoperability. So, making this solution a standard would be the best thing, however this could need a lot of time (while often people need to write applications TODAY).

For this reason, now this solution (if working properly) could be just a nice "plus" for whoever is going to use XTS as an implementation, but if the client also needs to invoke other transactional web services on other remote systems (some of which may not use XTS), then the client itself must also provide the standard CompletionParticipant support. This could lead to an even more complex client configuration and setup.

Maybe the very best solution would be to remove the need of the client to be reachable at all, but I think you already studied the problem in great depth and determined that it's not possible.

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.

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.