JBoss.orgCommunity Documentation
The basic building blocks of a transactional Web Services application include the application itself, the Web services that the application consumes, the Transaction Manager, and the transaction participants which support those Web services. Although it is likely that different developers will be responsible for each piece, the concepts are presented here so that you can see the whole picture. Often, developers produce services, or applications that consume services, and system administrators run the transaction-management infrastructure.
The transaction manager is a Web service which coordinates JBossTS transactions. It is the only software component in JBossTS that is designed to be run directly as a network service, rather than to support end-user code. The transaction manager runs as a JAXM request/response Web service.
When starting up an application server instance that has JBossTS transaction manager deployed within it, you may see various “error” messages in the console or log. For example 16:53:38,850 ERROR [STDERR] Message Listener Service: started, message listener jndi name activationcoordinator". These are for information purposes only and are not actual errors.
You can configure the Transaction Manager and related infrastructure by using three properties files:
wscf.xml, wst.xml, and wstx.xml. Each file is
located in the conf/ directory. Both the demo application and the stand-alone module rely on
them for configuration.
For the most part the default values in these files are suitable. However, the
ObjectStoreEnvironmentBean.objectStoreDir property, which determines the location of the
persistent store used to record transaction state, should be modified to suit your environment. The default value
is C:/temp/ObjectStore. For production environments this directory should reside on
fault-tolerant media such as a RAID array.
When an application uses a standalone coordinator, you must enable and modify two additional
properties in wstx.xml. These properties are
com.arjuna.mw.wst.coordinatorURL and com.arjuna.mw.wst.terminatorURL. They specify the
URLs needed by client application to contact the standalone coordinator, and need to specify the correct hostname
and port for the stand-alone server.
JBossTS is extremely modular. To allow flexible deployment of individual components, the same property values sometimes need to appear in more than one configuration file. Except in special circumstances, maintain consistent values for properties that are defined in more than one file.
The JBossTS XTS component consists of a number of .jar files containing the application’s
class files, plus Web service (.war) files which expose the necessary services. These
components are typically included in an application's Enterprise Archive (.ear) file during
application development, as this simplifies deployment of the transaction infrastructure. For production, you can
install the Transaction Manager as an application in its own right, allowing for centralized configuration and
management at the server level, independent of specific applications. The demonstration application shipped with
JBossTS provides a sample deployment descriptor illustrating how the Transaction Manager components can be
included in an application.
JBossTS 4.x uses fixed endpoints for its underlying protocol communication. Therefore, problems may arise if you deploy multiple applications using JBossTS to the same server concurrently. If you need to deploy several transactional applications in the same server, you must deploy the Transaction Manger as a separate application, rather than embedding it within the development of individual applications.
The coordinator/ directory in the JBossTS installation can assist in the configuration and
deployment of a stand-alone transaction manager.
Procedure 11.1. Using the coordinator/ diretory to configure and deploy a stand-alone transaction manager
Install JBossTS 4.15.
Use a separate application server installation for the coordinator. This installation can be on a separate machine. To set this up on JBoss Application Server, see http://www.yorku.ca/dkha/jboss/docs/MultipleInstances.htm for more information.
Install Ant 1.4 or later.
A separate application server installation must be used, separate from the one that clients and services are deployed into, to prevent conflicts between the various JBossTS components.
Edit the build.xml included in the coordinator/ directory, to point
to the application server installation where the transaction coordinator will be deployed and the location of
the JBossTS installation. The files ws-c_jaxm_web-app.xml and
ws-t_jaxm_web-app.xml in the dd/ subdirectory of
coordinator/ are the deployment descriptors for the WS-C and WS-T
war files. These files contain templated URLs. During the build phase, ant will
substitute the hostname and port values you specify in the build.xml into these files.
Run ant, with one of targets deploy-weblogic, deploy-jboss,
or deploy-webmethods, to create and deploy a new coordinator into the correct
application server installation.
Finally, point your client at the required coordinator. To do this, generate the demo application. specifying the port and hostname of the coordinator.
In general, changing the contents of the various deployment descriptors used by JBossTS is not necessary. However, if you do need to modify them they are all included in the coordinator module.
Not all JBossTS components have ready access to the information in the deployment descriptors. Therefore, if you
modify the JNDI names used by any of the WS-C or WS-T deployment descriptors, you may need to inform other JBossTS
components at runtime, by setting an appropriate property in the wstx.xml configuration
file.
You need to prefix each property in this table with the string com.arjuna.mw.wst.. The
prefix has been removed for formatting reasons, and has been replaced by ....
Table 11.1. Deployment descriptor values and properties
| JNDI Name | Property |
|---|---|
| Activationrequester | ...at.activationrequester |
| Activationcoordinator | ...at.activationcoordinator |
| Completionparticipant | ...at.completionparticipant |
| Registrationrequester | ...at.registrationrequester |
| durable2pcdispatcher | ...at.durable2pcdispatcher |
| durable2pcparticipant | ...at.durable2pcparticipant |
| volatile2pcdispatcher | ...at.volatile2pcdispatcher |
| volatile2pcparticipant | ...at.volatile2pcparticipant |
| businessagreementwithparticipantcompletiondispatcher | ...ba.businessagreementwpcdispatcher |
| businessagreementwithparticipantcompletionparticipant | ...ba.businessagreementwpcparticipant |
| businessagreementwithcoordinatorcompletiondispatcher | ...ba.businessagreementwccdispatcher |
| Businessagreementwithcoordinatorcompletionparticipant | ...ba.businessagreementwccparticipant |