The wsba-participant-completion-simple
quickstart deploys a WS-BA (WS Business Activity) enabled JAX-WS Web service WAR (ParticipantCompletion Protocol).
The wsba-participant-completion-simple
quickstart demonstrates the deployment of a WS-BA (WS Business Activity) enabled JAX-WS Web service bundled in a WAR archive (ParticipantCompletion Protocol) for deployment to {productNameFull}.
The Web service exposes a simple 'set' collection as a service. The Service allows items to be added to the set within a Business Activity.
The example demonstrates the basics of implementing a WS-BA enabled Web service. It is beyond the scope of this quickstart 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-BA is a 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 tht you have an understanding of WS-BusinessActivity. 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.wsba.participantcompletion.simple.ClientTest#testSuccess() method, the following steps occur:
-
A new Business Activity is created by the client.
-
An operation on a WS-BA enabled Web service is invoked by the client.
-
The
JaxWSHeaderContextProcessor
in the WS Client handler chain inserts the BA context into the outgoing SOAP message. -
When the service receives the SOAP request, the
JaxWSHeaderContextProcessor
in its handler chain inspects the BA context and associates the request with this BA. -
The Web service operation is invoked.
-
A participant is enlisted in this BA. This allows the Web Service logic to respond to protocol events, such as compensate and close.
-
The service invokes the business logic. In this case, a String value is added to the set.
-
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.
-
Providing the above steps where successful, the service notifies the coordinator that it has completed. The service has now made its changes visible and is not holding any locks. Allowing the service to notify completion is an optimisation that prevents the holding of locks, whilst waiting for other participants to complete. This notification is required as the Service participates in the
ParticipantCompletion
protocol. -
The client can then decide to complete or cancel the BA. If the client decides to complete, all participants will be told to close. If the participant decides to cancel, all participants will be told to compensate.
There are additional tests that show:
-
What happens when an application exception is thrown by the service.
-
How the client can cancel a BA.
You must start {productName} with the XTS subsystem enabled.
-
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
{jbossHomeName}/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>
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.
-
Before you begin, make sure you do the following:
-
Back up the {productName} standalone server configuration as described above.
-
Start the {productName} server with the standalone default profile :
$ {jbossHomeName}/bin/standalone.sh
-
-
Review the
configure-server.cli
file in the root of this quickstart directory. This script adds xts domain -
Open a new terminal, navigate to the root directory of this quickstart, and run the following command, replacing
{jbossHomeName}
with the path to your server:$ {jbossHomeName}/bin/jboss-cli.sh --connect --file=configure-server.cli
NoteFor Windows, use the {jbossHomeName}\bin\jboss-cli.bat
script.You should see the following result when you run the script:
The batch executed successfully
-
Stop the {productName} server.
After stopping the server, open the {jbossHomeName}/standalone/configuration/standalone.xml
file and review the changes.
-
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>
-
The following
extension
was added.<extension module="org.jboss.as.xts"/>
-
Open a terminal and navigate to the root of the {productName} directory.
-
Start the {productName} server with XTS subsystem enabled by typing the following command.
$ {jbossHomeName}/bin/standalone.sh
NoteFor Windows, use the {jbossHomeName}\bin\standalone.bat
script.
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.
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 |
The following messages should appear in the server log. Note there may be other log messages interlaced between these. The messages trace the steps taken by the tests.
Test success:
INFO [stdout] (management-handler-threads - 6) Starting 'testSuccess'. This test invokes a WS within a BA. The BA is later closed, which causes the WS call to complete successfully.
INFO [stdout] (management-handler-threads - 6) [CLIENT] Creating a new Business Activity
INFO [stdout] (management-handler-threads - 6) [CLIENT] Beginning Business Activity (All calls to Web services that support WS-BA wil be included in this activity)
INFO [stdout] (management-handler-threads - 6) [CLIENT] invoking addValueToSet(1) on WS
INFO [stdout] (http-localhost-127.0.0.1-8080-1) [SERVICE] invoked addValueToSet('1')
INFO [stdout] (http-localhost-127.0.0.1-8080-1) [SERVICE] Enlisting a participant into the BA
INFO [stdout] (http-localhost-127.0.0.1-8080-1) [SERVICE] Invoking the back-end business logic
INFO [stdout] (http-localhost-127.0.0.1-8080-1) [SERVICE] Prepare the backend resource and if successful notify the coordinator that we have completed our work
INFO [stdout] (http-localhost-127.0.0.1-8080-1) [SERVICE] Prepare successful, notifying coordinator of completion
INFO [stdout] (http-localhost-127.0.0.1-8080-1) [SERVICE] Participant.confirmCompleted('true') (This tells the participant that compensation information has been logged and that it is safe to commit any changes.)
INFO [stdout] (http-localhost-127.0.0.1-8080-1) [SERVICE] Commit the backend resource (e.g. commit any changes to databases so that they are visible to others)
INFO [stdout] (management-handler-threads - 6) [CLIENT] Closing Business Activity (This will cause the BA to complete successfully)
INFO [stdout] (TaskWorker-2) [SERVICE] Participant.close (The participant knows that this BA is now finished and can throw away any temporary state)
Test cancel:
INFO [stdout] (management-handler-threads - 5) Starting 'testCancel'. This test invokes a WS within a BA. The BA is later cancelled, which causes these WS call to be compensated.
INFO [stdout] (management-handler-threads - 5) [CLIENT] Creating a new Business Activity
INFO [stdout] (management-handler-threads - 5) [CLIENT] Beginning Business Activity (All calls to Web services that support WS-BA will be included in this activity)
INFO [stdout] (management-handler-threads - 5) [CLIENT] invoking addValueToSet(1) on WS
INFO [stdout] (http-localhost-127.0.0.1-8080-1) [SERVICE] invoked addValueToSet('1')
INFO [stdout] (http-localhost-127.0.0.1-8080-1) [SERVICE] Enlisting a participant into the BA
INFO [stdout] (http-localhost-127.0.0.1-8080-1) [SERVICE] Invoking the back-end business logic
INFO [stdout] (http-localhost-127.0.0.1-8080-1) [SERVICE] Prepare the backend resource and if successful notify the coordinator that we have completed our work
INFO [stdout] (http-localhost-127.0.0.1-8080-1) [SERVICE] Prepare successful, notifying coordinator of completion
INFO [stdout] (http-localhost-127.0.0.1-8080-1) [SERVICE] Participant.confirmCompleted('true') (This tells the participant that compensation information has been logged and that it is safe to commit any changes.)
This quickstart is more complex than the others. It requires that you configure the {productName} server using the configure-server.cli file.
-
Import the quickstart into {JBDSProductName}.
-
If you have not already done so, you must configure a new {productName} 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 {jbdsEapServerName}.
-
For the Server name, enter
{productName} XTS Configuration
and clickNext
. -
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:
{productName} XTS Runtime
Home Directory: Browse to the {jbossHomeName} 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
-
-
Start the new {productName} XTS Configuration server.
-
Right-click on the {artifactId} 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.