Skip to content

Latest commit

 

History

History
642 lines (523 loc) · 32.8 KB

README.adoc

File metadata and controls

642 lines (523 loc) · 32.8 KB

wsat-simple: WS-AT (WS-AtomicTransaction) - Simple

The wsat-simple quickstart demonstrates a WS-AT (WS-AtomicTransaction) enabled JAX-WS Web service, bundled as a WAR, and deployed to WildFly.

What is it?

The wsat-simple quickstart demonstrates the deployment of a WS-AT (WS-AtomicTransaction) enabled JAX-WS Web service bundled in a WAR archive for deployment to WildFly Application Server.

The Web service is offered by a Restaurant for making bookings. The Service allows bookings to be made within an Atomic Transaction.

This example demonstrates the basics of implementing a WS-AT enabled Web service. It is beyond the scope of this quick start to demonstrate more advanced features. In particular:

  • The Service does not implement the required hooks to support recovery in the presence of failures.

  • It also does not utilize a transactional back-end resource.

  • Only one web service participates in the protocol. As WS-AT is a 2PC coordination protocol, it is best suited to multi-participant scenarios.

For a more complete example, please see the XTS demonstrator application that ships with the Narayana project: http://narayana.io/.

It is also assumed that you have an understanding of WS-AtomicTransaction. For more details, read the XTS documentation that ships with the Narayana project: http://narayana.io/docs/product.

The application consists of a single JAX-WS web service that is deployed within a WAR archive. It is tested with a JBoss Arquillian enabled JUnit test.

When running the org.jboss.as.quickstarts.wsat.simple.ClientTest#testCommit() method, the following steps occur:

  1. A new Atomic Transaction (AT) is created by the client.

  2. An operation on a WS-AT enabled Web service is invoked by the client.

  3. The JaxWSHeaderContextProcessor in the WS Client handler chain inserts the WS-AT context into the outgoing SOAP message

  4. When the service receives the SOAP request, the JaxWSHeaderContextProcessor in its handler chain inspects the WS-AT context and associates the request with this AT.

  5. The Web service operation is invoked…

  6. A participant is enlisted in this AT. This allows the Web Service logic to respond to protocol events, such as Commit and Rollback.

  7. The service invokes the business logic. In this case, a booking is made with the restaurant.

  8. The backend resource is prepared. This ensures that the Backend resource can undo or make permanent the change when told to do so by the coordinator.

  9. The client can then decide to commit or rollback the AT. If the client decides to commit, the coordinator will begin the 2PC protocol. If the participant decides to rollback, all participants will be told to rollback.

There is another test that shows what happens if the client decides to rollback the AT.

System Requirements

The application this project produces is designed to be run on WildFly Application Server 31 or later.

All you need to build this project is Java 11.0 (Java SDK 11) or later and Maven 3.6.0 or later. See Configure Maven to Build and Deploy the Quickstarts to make sure you are configured correctly for testing the quickstarts.

Use of the WILDFLY_HOME and QUICKSTART_HOME Variables

In the following instructions, replace WILDFLY_HOME with the actual path to your WildFly installation. The installation path is described in detail here: Use of WILDFLY_HOME and JBOSS_HOME Variables.

When you see the replaceable variable QUICKSTART_HOME, replace it with the path to the root directory of all of the quickstarts.

Start the WildFly Standalone Server

You must start WildFly with the XTS subsystem enabled.

  1. Edit the log level to reduce the amount of log output. This should make it easier to read the logs produced by this example. To do this add the following logger block to the WILDFLY_HOME/standalone/configuration/standalone.xml of your JBoss distribution. You should add it just below one of the other logger blocks.

    <logger category="org.apache.cxf.service.factory.ReflectionServiceFactoryBean">
    <level name="WARN"/>
</logger>

Configure the Server

You can configure the server by running JBoss CLI commands. For your convenience, this quickstart batches the commands into a configure-server.cli script provided in the root directory of this quickstart.

+ NOTE: Remember you will need to run the restore-configuration.cli script to restore the server original configuration.

  1. Before you begin, make sure you do the following:

  2. Review the configure-server.cli file in the root of this quickstart directory. This script adds xts domain

  3. Open a new terminal, navigate to the root directory of this quickstart, and run the following command, replacing WILDFLY_HOME with the path to your server:

    $ WILDFLY_HOME/bin/jboss-cli.sh --connect --file=configure-server.cli
    Note
    		 For Windows, use the WILDFLY_HOME\bin\jboss-cli.bat script.

    You should see the following result when you run the script:

    The batch executed successfully

  4. Stop the WildFly server.

Review the Modified Server Configuration

After stopping the server, open the WILDFLY_HOME/standalone/configuration/standalone.xml file and review the changes.

  1. The following subsystem was added.

    <subsystem xmlns="urn:jboss:domain:xts:3.0">
            <host name="default-host"/>
            <xts-environment url="http://${jboss.bind.address:127.0.0.1}:8080/ws-c11/ActivationService"/>
            <default-context-propagation enabled="true"/>
</subsystem>

  2. The following extension was added.

            <extension module="org.jboss.as.xts"/>

  3. Open a terminal and navigate to the root of the WildFly directory.

  4. Start the WildFly server with XTS subsystem enabled by typing the following command.

    $ WILDFLY_HOME/bin/standalone.sh
    Note
    		 For Windows, use the WILDFLY_HOME\bin\standalone.bat script.

Run the Arquillian Tests

This quickstart provides Arquillian tests. By default, these tests are configured to be skipped since Arquillian tests require the use of a container.

Note
 The Arquillian tests deploy the application, so make sure you undeploy the quickstart before you begin.

Follow these steps to run the tests.

  1. Start the WildFly server as described above.

  2. Open a terminal and navigate to the root directory of this quickstart.

  3. Type the following command to run the verify goal with the arq-remote profile activated.

    $ mvn clean verify -Parq-remote
Note

You can also let Arquillian manage the WildFly server by using the arq-managed profile, meaning the tests will start the server for you. This profile requires that you provide Arquillian with the location of the WildFly server, either by setting the JBOSS_HOME environment variable, or by setting the jbossHome property in the arquillian.xml file. For more information, see Run the Arquillian Tests.

Investigate the Console Output

When you run the Arquillian tests, Maven prints summary of the performed tests to the console. You should see the following results.

Results :

Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
Note

You see the following warning when you run the Arquillian tests in remote mode.

WARN  [org.jboss.as.dependency.deprecated] (MSC service thread 1-4) WFLYSRV0221: Deployment "deployment.wsat-simple.war" is using a deprecated module ("org.jboss.xts") which may be removed in future versions without notice.

This is because, in remote mode, you are responsible for starting the server with the XTS subsystem enabled. When you run the Arquillian tests in managed mode, the container uses the serverConfig property defined in the arquillian.xml file to start the server with the XTS subsystem enabled (default is standalone.xml).

Investigate the Server Log

The following messages should appear in the server log. The messages trace the steps taken by the tests. Note there may be other informational log messages interlaced between these.

Test rollback:

INFO  [stdout] (http-localhost.localdomain/127.0.0.1:8080-4) Starting 'testRollback'. This test invokes a WS within an AT. The AT is later rolled back, which causes the back-end resource(s) to be rolled back.
INFO  [stdout] (http-localhost.localdomain/127.0.0.1:8080-4) [CLIENT] Creating a new WS-AT User Transaction
INFO  [stdout] (http-localhost.localdomain/127.0.0.1:8080-4) [CLIENT] Beginning Atomic Transaction (All calls to Web services that support WS-AT wil be included in this transaction)
INFO  [stdout] (http-localhost.localdomain/127.0.0.1:8080-4) [CLIENT] invoking makeBooking() on WS
INFO  [stdout] (http-localhost.localdomain/127.0.0.1:8080-25) [SERVICE] Restaurant service invoked to make a booking
INFO  [stdout] (http-localhost.localdomain/127.0.0.1:8080-25) [SERVICE] Enlisting a Durable2PC participant into the AT
INFO  [stdout] (http-localhost.localdomain/127.0.0.1:8080-25) [SERVICE] Invoking the back-end business logic
INFO  [stdout] (http-localhost.localdomain/127.0.0.1:8080-25) [SERVICE] makeBooking called on backend resource.
INFO  [stdout] (http-localhost.localdomain/127.0.0.1:8080-4) [CLIENT] rolling back Atomic Transaction (This will cause the AT and thus the enlisted back-end resources to rollback)
INFO  [stdout] (TaskWorker-2) [SERVICE] one or more participants voted 'aborted' or a failure occurred, so coordinator tells the participant to rollback
INFO  [stdout] (TaskWorker-2) [SERVICE] rollback called on backend resource.

Test commit:

INFO  [stdout] (http-localhost.localdomain/127.0.0.1:8080-54) Starting 'testCommit'. This test invokes a WS within an AT. The AT is later committed, which causes the back-end resource(s) to be committed.
INFO  [stdout] (http-localhost.localdomain/127.0.0.1:8080-54) [CLIENT] Creating a new WS-AT User Transaction
INFO  [stdout] (http-localhost.localdomain/127.0.0.1:8080-54) [CLIENT] Beginning Atomic Transaction (All calls to Web services that support WS-AT wil be included in this transaction)
INFO  [stdout] (http-localhost.localdomain/127.0.0.1:8080-54) [CLIENT] invoking makeBooking() on WS
INFO  [stdout] (http-localhost.localdomain/127.0.0.1:8080-66) [SERVICE] Restaurant service invoked to make a booking
INFO  [stdout] (http-localhost.localdomain/127.0.0.1:8080-66) [SERVICE] Enlisting a Durable2PC participant into the AT
INFO  [stdout] (http-localhost.localdomain/127.0.0.1:8080-66) [SERVICE] Invoking the back-end business logic
INFO  [stdout] (http-localhost.localdomain/127.0.0.1:8080-66) [SERVICE] makeBooking called on backend resource.
INFO  [stdout] (http-localhost.localdomain/127.0.0.1:8080-54) [CLIENT] committing Atomic Transaction (This will cause the AT to complete successfully)
INFO  [stdout] (TaskWorker-2) [SERVICE] Prepare called on participant, about to prepare the back-end resource
INFO  [stdout] (TaskWorker-2) [SERVICE] prepare called on backend resource.
INFO  [stdout] (TaskWorker-2) [SERVICE] back-end resource prepared, participant votes prepared
WARN  [com.arjuna.wst] (TaskWorker-2) ARJUNA043219: Could not save recovery state for non-serializable durable WS-AT participant restaurantServiceAT:ba222c73-00c3-4ecc-921c-80fd5dfdc11a
INFO  [stdout] (TaskWorker-2) [SERVICE] all participants voted 'prepared', so coordinator tells the participant to commit
INFO  [stdout] (TaskWorker-2) [SERVICE] commit called on backend resource.

Restore the WildFly Standalone Server Configuration

You can restore the original server configuration using either of the following methods.

Restore the WildFly Standalone Server Configuration by Running the JBoss CLI Script

  1. Start the WildFly server as described above.

  2. Open a new terminal, navigate to the root directory of this quickstart, and run the following command, replacing WILDFLY_HOME with the path to your server:

    $ WILDFLY_HOME/bin/jboss-cli.sh --connect --file=restore-configuration.cli
    Note
    		 For Windows, use the WILDFLY_HOME\bin\jboss-cli.bat script.

Run the Quickstart in Red Hat CodeReady Studio or Eclipse

You can also start the server and deploy the quickstarts or run the Arquillian tests in Red Hat CodeReady Studio or from Eclipse using JBoss tools. For general information about how to import a quickstart, add a WildFly server, and build and deploy a quickstart, see Use Red Hat CodeReady Studio or Eclipse to Run the Quickstarts.

This quickstart is more complex than the others. It requires that you configure the WildFly server using the configure-server.cli file.

  1. Import the quickstart into Red Hat CodeReady Studio.

    Note

    When you import this quickstart into Red Hat CodeReady Studio, you will see the following warning.

    WS-I: A problem occured while running the WS-I WSDL conformance check: org.eclipse.wst.wsi.internal.analyzer.WSIAnalyzerException: The WS-I Test Assertion Document (TAD)document was either not found or could not be processed.The WSDLAnalyzer was unable to validate the given WSDL File.

    This is a known Eclipse issue. For more information, see Eclipse Bugzilla - Bug 535813.

  2. If you have not already done so, you must configure a new WildFly server to use the XTS configuration.

    • In the Servers tab, right-click and choose New → Server.

    • Under Select the server type:, expand Red Hat JBoss Middleware and choose Red Hat JBoss Enterprise Application Platform 7.3.

    • For the Server name, enter WildFly XTS Configuration and click Next.

    • In the Create a new Server Adapter dialog, choose Create a new runtime (next page) from the drop-down menu and click Next.

    • In the JBoss Runtime dialog, enter the following information and then click Finish.

      Name: WildFly XTS Runtime
Home Directory: Browse to the WILDFLY_HOME directory and select it.
Runtime JRE: Choose an alternate JRE if not correct.
Server base directory: This should already point to your standalone server configuration directory,
Configuration file: standalone.xml

  3. Start the new WildFly XTS Configuration server.

  4. Right-click on the wsat-simple project, choose Run As → Maven build, enter clean verify -Parq-remote for the Goals, and click Run to run the Arquillian tests. The test results appear in the console.

Debug the Application

If you want to debug the source code of any library in the project, run the following command to pull the source into your local repository. The IDE should then detect it.

$ mvn dependency:sources