Java Reference
In-Depth Information
tion. In general, you should not need to return the result, but rather work with it directly in the
handler.
Example 6-25
shows the client code that uses this handler to produce the callback.
Example6-25.Asynchronous Callback Client
public void doLongJobCallback(String jobName) throws Exception {
LOGGER.debug("Executing.");
SoaCookbookService svc = new SoaCookbookService();
SoaCookbook port = svc.getSoaCookbookPort();
MyHandler handler = new MyHandler();
Future<?> task = port.doLongJobAsync(jobName, handler);
LOGGER.debug("Invoked service.");
while(!task.isDone()){
LOGGER.debug("Waiting...");
Thread.sleep(1000); //do something
}
}
This code gets the SEI, and then invokes its overloaded
doLongJobAsync
method. You create
an instance of your custom handler and remember that no such method is actually defined in
the WSDL, but is generated due to your binding customizations on the client side. This meth-
od returns a
Future
, which will eventually receive and wrap the result of the operation, mak-
ing it available to operate on within your handler.
The output of running this code is as follows:
AsynchClient.doLongJobCallback - Executing.
AsynchClient.doLongJobCallback - Invoked service.
AsynchClient.doLongJobCallback - Waiting...
AsynchClient.doLongJobCallback - Waiting...
AsynchClient.doLongJobCallback - Waiting...
AsynchClient.doLongJobCallback - Waiting...
MyHandler.handleResponse - Executing callback handler.
MyHandler.handleResponse - Got response! Job is done running: Some Batch
In the event that a web operation call fails when using one of the asynchronous invocation
methods, the spec requires that a
java.util.concurrent.ExecutionException
is thrown
from the
Response.get
method. The cause is the original exception that was thrown, which
is always a
WebServiceException
or a subclass.
