SCA Async/Conversational services Part 2: Non-SCA Web Service client
Following my previous post on the internals of asynchronous and conversational services in Tuscany SCA, which options are available for consuming these services when you cannot use a Tuscany SCA runtime on the client?.
Depending on the transport binding used you would expect to find a certain level of standarisation on conversational/asynchronous services implementation, allowing interoperable solutions. However, it is difficult, if not impossible, to find interoperable solutions for these types of services, even for highly standarised bindings such as SOAP Web Services. We have seen in the previous post how Tuscany SCA handles these services for WS and JMS bindings. We saw that at least for Web Services, some WS-* standards were used (i.e. WS-Addressing), but there are still solution-specific details that do not allow interoperability. This reflects how difficult it is for the standarisation community to define detailed standards and mechanisms to enable interoperable solutions for these kind of services.
In this post I present an option for this situation, using an standard JAX-WS client, attaching the appropriate WS-Addressing headers using JAXB. For that, I extend the pure Tuscany SCA client-server sample of the previous post with a non-SCA client.
You can find the extended source code of the maven projects here.
Overview
The two main pieces to setup on a JAX-WS client are:
- Proper WS-Addressing headers containing the Tuscany’s specific information (i.e callbackLocation, conversationID and optionally callbackID).
- A web service implementing the callback interface, listening in callbackLocation URI.
JAX-WS WS-Addressing headers setup
As for a normal WSDL-first client development, the first step is to generate the JAX-WS client classes from the Counter Service WSDL. This is done using the maven jaxws-maven-plugin on the wsdl file generated for the service (i.e. http://localhost:8086/CounterServiceComponent?wsdl).
To setup the SOAP WS-Addressing headers, I follow the recommendations from the JAX-WS guide and use WSBindingProvider interface, which offers a much better control on how headers can be added.
Therefore, in the constructor of CounterServiceClient.java, the WS-Addressing “TuscanyHeader” is added:
public CounterServiceClient() {
super();
// Initialise JAX-WS Web Service Client.
service = new CounterServiceService();
servicePort = service.getCounterServicePort();
// Set the WS-Addressing headers to use by the client.
WSBindingProvider bp = (WSBindingProvider) servicePort;
// Generate UUID for Tuscany headers
conversationId = UUID.randomUUID().toString();
callbackId = UUID.randomUUID().toString();
ReferenceParameters rp = new ReferenceParameters(conversationId);
rp.setCallbackId(callbackId);
TuscanyHeader header = new TuscanyHeader(CALLBACKURI, rp);
bp.setOutboundHeaders(Headers.create((JAXBRIContext) jaxbContext,
header));
...
}The ReferenceParameters and TuscanyHeader classes are JAXB classes with the required information to map the TuscanyHeader Java object to the WS-Addressing XML header. For instance, the ReferenceParameters class, which includes the Tuscany SCA parameters, has the following JAXB definitions:
public class ReferenceParameters {
private static final String TUSCANYSCA_NS = "http://tuscany.apache.org/xmlns/sca/1.0";
/** The conversation id. */
private String conversationId = "";
/** The callback id. */
private String callbackId = null;...
public void setCallbackId(String callbackId) {
this.callbackId = callbackId;
}public void setConversationId(String conversationId) {
this.conversationId = conversationId;
}@XmlElement(name = "CallbackID", namespace = TUSCANYSCA_NS, required = false)
public String getCallbackId() {
return callbackId;
}@XmlElement(name = "ConversationID", namespace = TUSCANYSCA_NS, required = true)
public String getConversationId() {
return conversationId;
}
}JAX-WS callback service setupThe callback service needs to be created on the client side. For that we define a simple web service (CounterServiceCallbackImpl.java) with the CounterServiceCallback as the contract./**
* The CounterServiceCallback implementation.
* The Web service namespace must be the same as the one defined in the Server Side.
*/
@WebService(targetNamespace = "http://server.demo.tuscany.sca.tsl.com/")
public class CounterServiceCallbackImpl implements CounterServiceCallback {
private int count;@Override
public void receiveCount(int count, int end) {
System.out.println("CounterServiceCallback --- Received Count: " + count + " out of " + end);
this.count = count;
}
...
}In this sample project, the web service is also started during the instantiation of the JAX-WS Client. We use the embedded Sun httpserver to publish the web service instead of relying in other web application servers as Jetty or Tomcat:public CounterServiceClient() {
super();
...
// Setup Receiver Callback Web Service
System.out.println("Starting Callback service in " + CALLBACKURI);
callback = new CounterServiceCallbackImpl();
callbackServiceEp = Endpoint.create(callback);
callbackServiceEp.publish(CALLBACKURI);
}Testing the clientAs in the previous post, in order to run the client tests you need to:
- Run the server side, executing the run-server.sh under the counter-callback-ws-service directory. The server component should start and wait for client requests.
- Go to the client project, counter-callback-ws-client-SCA and execute the tests with:
- mvn clean test
- This runs both the SCA and non-SCA client tests.
- In case you want to run two clients at the same time, you need to define two separate CallbackURIs. For that purpose the property sca.callbackuri has been defined to configure the URI to use. Therefore to run two clients in parallel execute
- mvn test -Dsca.callbackuri=”http://localhost:1999/callback" -Dtest=com.tsl.sca.tuscany.demo.client.WebServiceNonSCAClientTest
and another client with
mvn test -Dsca.callbackuri=”http://localhost:2999/callback" -Dtest=com.tsl.sca.tuscany.demo.client.WebServiceNonSCAClientTest - Once running you should see the different service calls and conversations IDs interleaved in the server side console:
- setCounterServiceCallback on thread Thread[Thread-2,5,main]
ConversationID = 81e257cd-af3b-4ea6-ae69–4b8e0d9db8a9. Starting count
Sleeping …
setCounterServiceCallback on thread Thread[Thread-5,5,main]
ConversationID = 70e86dcf-436c-4df1-ab6b-165b3f9070a4. Starting count
Sleeping …
Sleeping …
Sleeping …
Sleeping …
Sleeping …
Sleeping …
Sleeping …
Sleeping …
Sleeping …
ConversationID = 81e257cd-af3b-4ea6-ae69–4b8e0d9db8a9. Stopping count
Sleeping …
ConversationID = 70e86dcf-436c-4df1-ab6b-165b3f9070a4. Stopping count
Sleeping …
Sleeping …
Sleeping …
Sleeping …
Sleeping …
Sleeping …
Sleeping …
Sleeping …
Sleeping …
ConversationID = 81e257cd-af3b-4ea6-ae69–4b8e0d9db8a9. Restarting count
Sleeping …
ConversationID = 70e86dcf-436c-4df1-ab6b-165b3f9070a4. Restarting count
Sleeping …
Sleeping …
Sleeping …
Sleeping …
Sleeping …
Sleeping …
Sleeping …
Sleeping …
Sleeping …
Thread interrupted.
Thread interrupted.
ConclusionsI hope that these posts have shed some light on how SCA and conversational/async services are implemented taking Tuscany as SCA runtime reference. I also believe that it is important to know the available options for consuming a SCA service without an SCA runtime, and how we can do it in a simple manner.
