The issue of supporting a JSR-181-based programming model for Axis2 endpoints was first addressed by Rajith under JIRA issue 883 (http://issues.apache.org/jira/browse/AXIS2-883). The goal is to provide support for annotating an existing Java bean and deploying it as an Axis2 Web service. JAX-WS 2.0 also includes support for JSR-181 annotations as a way to simplify web service development.

1. Targeting a Programming Model

One issue that is raised by the current approach is that, if Java beans can be annotated with just JSR-181 annotations, how do you determine whether the bean should be deployed as an Axis2 service vs. a JAX-WS service.

Let's say, for example, that a user provides the following annotated bean as their Web service implementation class.

package test;

@WebService(serviceName="MyService" targetNamespace="http://test")
public MyService {

    @WebMethod
    public String foo(String input) {
        return input;
    }
}

When processing this class, what marker can we use to determine whether or not this endpoint uses the native Axis2 programming model, or whether it should be using JAX-WS? One of the goals of providing an annotations-based programming model is the removal of the required deployment descriptor (services.xml in the Axis2 case and webservices.xml in the JAX-WS/JSR-109 case). The requirement is that the service can be configured using just the information that exists in the Java. In this case though, the class is generic enough that it appears too ambiguous to determine the target runtime just by looking at the Java information.

One of the proposed methods for solving this was to expose every JSR-181 annotated Java bean as an Axis2 endpoint as well as a JAX-WS endpoint. This just moves the problem from a deploy time issue to a runtime issue. Since both services would be configured based on the same endpoint information, the burden of determining which endpoint/operation should be invoked would be placed on one of the Dispatchers. Since the same operations exist on both endpoints, there is again a situation where it's ambiguous as to which one is correct.

So it seems like making the decision at deploy time is the correct one. But to achieve this, there will need to be some metadata beyond what exists today. One proposal was to allow a services.xml approach where the MessageReceiver could be specified explicitly. This is a simple way to solve the problem, but then negates one of the goals of not having a deployment descriptor in lieu of annotations data.

A third proposal that was suggested was to allow for an additional annotation to be included on the class that would denote what the target programming model is. Here's a definition of an annotation, @RuntimeBinding, that could be included on a class to trigger which runtime was to be used.

package org.apache.axis2.annotation;

@Target (ElementType.TYPE)
@Retention (RetentionPolicy.RUNTIME)
public @interface RuntimeBinding {
    
    public enum Runtime {AXIS2, JAXWS};

    public Runtime target();
}

A example usage of this annotation by a service to target Axis2 would look like this:

package test;

import org.apache.axis2.annotation.RuntimeBinding;
import org.apache.axis2.annotation.RuntimeBinding.Runtime;

@WebService(serviceName="MyService" targetNamespace="http://test")
@RuntimeBinding(target=Runtime.AXIS2)
public MyService {

    @WebMethod
    public String foo(String input) {
        return input;
    }
}

So with two import statements and one additional annotation, we're able to toggle between whether the endpoint should be Axis2 or whether it should be JAX-WS.

Of the three approaches provided, this seems like the one closest to the goal. If this approach were chosen though, there would need to be a default chosen for the cases in which this annotation was not specified on the endpoint. To pass the JAX-WS TCK, we cannot require the presence of an additional annotation, so the default runtime for an annotated class should be JAX-WS.

2. Deployment Model

TODO: Discuss the various deployment steps necessary to get an annotated endpoint up and running.

3. Configuration

In the absence of the services.xml, the user does not have a way to configure some of the QoS/module information that may have existed in the services.xml. There is also operation-level configuration information that can be specified like which MessageReceiver to use that can be included at the operation level. The current proposal for solving this is to introduce additional annotations that can provide this information.

TODO: Define annotations