I'd like to restart the discussion on supporting JAX-WS annotations for the Java-to-WSDL mapping. This is needed to fix TUSCANY-2033, and has been the subject of various user requests from time to time.
The scenario that I want to fix is a service with a Java interface that was generated from WSDL by running the JAX-WS mapping (e.g., the wsimport tool from the JAX-WS RI). The generated service interface and associated classes (e.g., exceptions, data objects) will have JAX-WS and JAXB annotations that are equivalent to the information contained in the WSDL. The runtime processing for a Tuscany client talking to a Tuscany service is as follows: a. (client and service) Generate an equivalent WSDL interface from the Java service interface and associated classes. b. (client and service) Generate equivalent XSD types from the Java service interface and associated classes. c. (client and service) Use the Web Service stack to create a service definition from the output of a and b. This is done by the Web Service binding. d. (client) Transform the Java datatypes passed on the service invocation into an XML infoset (as defined by b) for marshalling by the reference binding's Web Service stack. This is done by the databinding framework. In Tuscany today, the XML infoset would be AXIOM for use by the Axis2 binding. e. (client) Pass the XML infoset created by d to the service definition created by c. This is done by the Web Service binding. f. (service) Receive the invocation data in XML infoset form from the service definition created by c. This is done by the Web Service binding. g. (service) Transform the XML infoset (as defined by b) passed on the service invocation into Java classes that can be passed to the service business logic. This is done by the databinding framework. h. (service) Invoke the service business logic. i. Any result or exception is returned to the client using the inverse of steps d to g. My understanding is that the current state of the Tuscany code for these steps is as follows. a. Broken, does not understand JAX-WS annotations. b. Most or all of the code needed is currently present in the JAXP transformer and the exception mapper, but some information that it needs (derived from JAX-WS annotations) is not being passed to it. c. Would probably work if the right outputs from a and b were passed in, but this is not certain as it depends on whether the Axis2 stack that we are using has any limitations here. d. Probably working if the correct output from b is available. e. Probably working. f. Probably working. g. Probably working if the correct output from b is available. h. Working. i. Probably working once the above steps have been made to work. Tuscany also has standalone tools to do Java-to-WSDL and WSDL-to-Java mapping. These currently use code that's completely separate from the above code in the runtime. Ideally as much code as possible should be shared between tools and runtime. Specifically, the code for steps a and b should also be invoked by the tools, to guarantee consistent processing. This means that we need a module structure that makes it easy for the tools to pull in this code without too many other dependencies. For databindings other than JAXB (let's use SDO as an example), steps b, d and g need to be pluggable. Currently only steps d and g are pluggable, so b needs to include a framework that allows other databinding transformations to be plugged in. For WSDL to Java processing, something similar is needed, but I won't make this post twice as long by spelling out all the steps here. In terms of making progress on TUSCANY-2033 and similar use cases, I think the the starting point is to work on steps a and b and at least get them into an 80% state so that we can start to run end-to-end scenarios through all the steps. We could then go back later and get them to a state of 100% perfection. I have been thinking of having the Tuscany runtime call code in CXF to do the 80% exercise for step a, perhaps only as a temporary prototype and learning exercise until we have all the necessary code in Tuscany. I think I understand how to do this, but I don't yet feel able to do a "from scratch" implementation of step a. I'd welcome other thoughts on this and any offers to help with steps a or b. Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
