On Mon, Aug 2, 2010 at 6:04 PM, Raymond Feng <[email protected]> wrote: > Hi, > From what's quoted below from JSR-181, I think we can reuse some of the > code. My understanding is: > * if the Service Implementation Bean doesn't reference a Service Endpoint > Interface, we will use the bean class as the SCA service interface > * if the Service Implementation Bean references a Service Endpoint Interface > (SEI), we will use the SEI as the SCA service interface > * We'll use the same introspection code to parse the JSR181 and JAX-WS > annotations > * We could even derive the "binding.ws" in the componentType service from > the Service Implementation Bean as it really represents a WS endpoint. > Thanks, > Raymond > 3.1 Service Implementation Bean > A developer who implements Web Services with JSR-181 is responsible for > implementing the service implementation bean containing the Web Service’s > business > logic. A JSR-181 service implementation bean MUST meet the following > requirements: > · The implementation bean MUST be an outer public class, MUST NOT be final, > and MUST NOT be abstract. > · The implementation bean MUST have a default public constructor. > · The implementation MUST NOT define a finalize() method. > · The implementation bean MUST include a @WebService class-level annotation, > indicating that it implements a Web Service. More information on the > @WebService annotation may be found in 4.1Annotation: javax.jws.WebService. > · The implementation bean MAY reference a service endpoint interface by > using > the @WebService.endpointInterface annotation. If the implementation bean > references a service endpoint interface, it MUST implement all the methods > on > the service endpoint interface. If the implementation bean references a > service > endpoint interface, that service endpoint interface is used to determine the > abstract > WSDL contract (portType and bindings). In this case, the service > implementation > bean MUST NOT include any JSR-181 annotations other than @WebService > and @HandlerChain. In addition, the @WebService annotation MUST NOT > include the name annotation element. More information on the > @WebService.endpointInterface annotation element may be found in 4.1 > Annotation: javax.jws.WebService. > · If the implementation bean does not implement a service endpoint interface > and > there are no @WebMethod annotations in the implementation bean (excluding > @WebMethod annotations used to exclude inherited @WebMethods), all public > methods other than those inherited from java.lang.Object will be exposed as > Web > Service operations, subject to the inheritance rules specified in Common > Annotations for the Java Platform [12], section 2.1. > 3.2 Service Endpoint Interface > A JSR-181 service implementation bean MAY reference a service endpoint > interface, > thus separating the contract definition from the implementation. A JSR-181 > service > endpoint interface MUST meet the requirements specified in JAX-WS 2.0 [5], > section > 3.4, with the following exceptions: > · The service endpoint interface MUST be an outer public interface. > · The service endpoint interface MUST include a @WebService annotation, > indicating that it is defining the contract for a Web Service. > 14 > · The service endpoint interface MAY extend java.rmi.Remote either directly > or > indirectly, but is not REQUIRED to do so. > · All methods on the service endpoint interface, including methods inherited > from > super-interfaces, are mapped to WSDL operations regardless of whether they > include a @WebMethod annotation. A method MAY include a @WebMethod > annotation to customize the mapping to WSDL, but is not REQUIRED to do so. > · The service endpoint interface MAY include other JSR-181 annotations to > control > the mapping from Java to WSDL. > · The service endpoint interface MUST NOT include the JSR-181 annotation > elements portName, serviceName and endpointInterface of the annotation > @WebService. > ________________________________________________________________ > Raymond Feng > [email protected] > Apache Tuscany PMC member and committer: tuscany.apache.org > Co-author of Tuscany SCA In Action book: www.tuscanyinaction.com > Personal Web Site: www.enjoyjava.com > ________________________________________________________________ > On Aug 2, 2010, at 9:32 AM, Simon Laws wrote: > > re. TUSCANY-3641 > > There are new POJO (JCI) otests that exercise the runtime's ability to > process JAXWS annotations in Java implementation classes. We don't at > the moment which I'm a little surprised about. There is quite a bit of > code in the Java interface processor that deals with JAXWS > annotations. I added some code at r981585 as an indication of intent. > If anyone else thinks this is already done or that the JAXWS interface > code is re-used in some clever way that I'm not yet aware of I'd be > interested to know. > > Simon > > -- > Apache Tuscany committer: tuscany.apache.org > Co-author of a book about Tuscany and SCA: tuscanyinaction.com > >
Hi Raymond Section "8.2 Impact of JAX-WS Annotations on ComponentType" describes how the JAXWS/181 annotations affect the SCA component type. I agree that we should aim to reuse the JAXWS introspection code where we can. I'll look into that. My main concern in the first instance was whether this had been done already in ways that were not clear. You're not suggesting that that's the case. There are some tricky things in this mapping, for example, the use of @WebService with an endpointInterface property implies that we have to load another Java class as the service interface. This will have to happen earlier than the instrospection code as there is currently no access to the wider resolvers from there. So we'll need some pre-processing to happen. There are a few issues like this. Anyhow I'll keep in plugging on and post progress here. Thanks Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
