Jitendra Kotamraju's Blog

February 2007 Archives

Thread Scoped JAX-WS endpoint instances

This is similar to the other extension HttpSessionScope. Traditionally JAX-WS has never taken advantage of object state, just like servlet. That is, the container creates only one instance of your service class, and then have it serve all the requests concurrently. This makes it impossible to set values to instance fields, as you'll experience concurrency problem as soon as multiple threads hit your service.

Say you have a service, and its web methods try to access Database using Connection object. Connection object doesn't handle concurrent accesses, hence the access needs to be synchronized. For e.g.:

@WebService
public class DataService {
    Connection con;

    public synchronized void delete() {
        Statement stmt = con.createStatement();
        stmt.executeQuery();
    }

    public synchronized void add() {
        Statement stmt = con.createStatement();
        stmt.executeQuery();
    }
}

This will have performance issues since some of the requests need to wait until a current request is finished. To avoid synchronization, one could create Connection objects in each invocation and that is even more expensive! So we need exclusive access to Connection object and reuse them exclusively for other invocations. This can be achieved by creating more instances and using an instance exclusively for one invocation. To achive this, jax-ws runtime creates instances and stores and reuses them from ThreadLocal.

import org.jvnet.jax_ws_commons.thread_scope.ThreadScope;

@WebService
@ThreadScope
public class DataService {
    Connection con;

    public void delete() {
        Statement stmt = con.createStatement();
        stmt.executeQuery();
    }

    public void add() {
        Statement stmt = con.createStatement();
        stmt.executeQuery();
    }
}

The @ThreadScope annotation tells the JAX-WS RI to create one instance of DataService per each thread. No need to have synchronized keyword.

Tubes in JAX-WS 2.1

Advantages of Tubes

• Tubes work on Message abstraction and has the efficient access to the payload. On the other hand, SOAP handlers wouldn't perform that well since they operate on DOM/SOAPMessages.
• No thread need to be blocked any time and this result in high scalability. Asynchronous transport tubes can take full advantage of this aspect and scale better for asynchronous web service invocations(for e.g. Dispatch.invokeAsync()).
• AsyncProvider endpoints scale well with asynchronous transports.
• Request and response processing is decoupled and that means they could potentially be run by different threads.

Sample Tube to add SOAP headers

1. Write a Tube that adds custom header to response messages.
2. Write a TubelineAssembler to include and postion the custom Tube in the tubeline.
3. Write a TubelineAssemblerFactory that creates these TubelineAssembler instances.

Writing a Tube

public class CustomTube extends AbstractFilterTubeImpl {

    protected CustomTube(Tube next) {
        super(next);
    }

    protected CustomTube(AbstractFilterTubeImpl that, TubeCloner cloner) {
        super(that, cloner);
    }

    public CustomTube copy(TubeCloner cloner) {
        return new CustomTube(this, cloner);
    }

    public NextAction processResponse(Packet packet) {
        Message message = packet.getMessage();
        if (message == null) {          // oneway
            return super.processResponse(packet);
        }
        HeaderList headers = message.getHeaders();
        QName adQName = new QName("test", "test");
        headers.add(Headers.create(adQName, "Advertisement"));
        return super.processResponse(packet);
    }

}

• In the processResponse(), it gets the Message from Packet and adds a Header object.
• Need to implement the correct copy() method. Eventhough, our Tube doesn't have any state, it needs to give a new instance since "next" tube may not be stateless. When the tubeline is copied, the copied instance is an independent tubeline without any shared tube instances among the tubelines. Also in the copy constructor, copy other instance data.
• Need to return correct NextAction for processRequest() and processResponse() methods. The NextAction determines whether to proceed with the next Tube or processing needs to change direction etc. Use the base class AbstractTubeImpl's methods to create different NextAction return values. 

Writing a TubelineAssembler

public class CustomTubeAssembler implements TubelineAssembler {    
    
    public Tube createClient(ClientTubeAssemblerContext context) {
        Tube head = context.createTransportTube();
        head = context.createSecurityTube(head);
        head = context.createWsaTube(head);
        head = context.createClientMUTube(head);
        return context.createHandlerTube(head);
    }
    public Tube createServer(ServerTubeAssemblerContext context) {
        Tube head = context.getTerminalTube();
        head = new CustomTube(head);         // Add our custom tube
        head = context.createHandlerTube(head);
        head = context.createMonitoringTube(head);
        head = context.createServerMUTube(head);
        head = context.createWsaTube(head);
        head = context.createSecurityTube(head);
        return head;
    }
}

Writing a TubelineAssemblerFactory

public class CustomTubelineAssemblerFactory extends TubelineAssemblerFactory {
    public TubelineAssembler doCreate(BindingID bindingID) {
        return new CustomTubeAssembler();
    }
}

CustomTube in action

META-INF/services/com.sun.xml.ws.api.pipe.TubelineAssemblerFactory
com/jitu/CustomTube.class
com/jitu/CustomTubeAssembler.class
com/jitu/CustomTubelineAssemblerFactory.class

...
<S:Header><test xmlns="test">Advertisement</test> ...</S:Header>
...

This work is licensed under a Creative Commons License.