ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Ws Wiki] Update of "FrontPage/Axis2/JAX-WS/JSR-181" by NickGallardo
Date Mon, 27 Nov 2006 15:35:33 GMT
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: general-unsubscribe@ws.apache.org
For additional commands, e-mail: general-help@ws.apache.org


Mime
View raw message