Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ws Wiki" for change notification.
The following page has been changed by NickGallardo: http://wiki.apache.org/ws/FrontPage/Axis2/JAX-WS/JSR-181 ------------------------------------------------------------------------------ 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. + 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. @@ -72, +72 @@ TODO: Discuss the various deployment steps necessary to get an annotated endpoint up and running. - * Where should the endpoints be deployed? (Sanjiva's "beans" directory or the normal "services" directory?) + * Where should the endpoints be deployed? (Sanjiva's "beans" directory or the normal "services" directory?) - ** packaging + ** packaging - ** scope + ** scope * What are the minimum requirements for deploying the bean? Just the @WebService annotation? No services.xml? @@ -84, +84 @@ 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 - * @MessageReceiver + * @MessageReceiver - * @Module + * @Module --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
