Eddie, i was looking at the current codebase and spotted the MirrorWsmBuilder. Is this what we can use in Axis2 to inspect a given java class? and one the WsmService object is built, then translate that to Axis2 thingies? Can we split out the processing framework into a separate jar (w/o things like Axis1 stuff)? Am i on the right track with this thinking?
thanks, dims On 1/3/06, Eddie O'Neil <[EMAIL PROTECTED]> wrote: > All-- > > Happy New Year! And, as a way to start the year off on a good foot, > let's get WSM to 1.0. Below is a proposal for how we get from here to > there with some details about where we are and what needs to happen. > > Today, there are two core WSM parts, both of which are tailored to > the Axis web service stack: > > build-time: This is a generic annotation processing layer that has > the ability to work against Mirror, reflection, and WSDL to produce a > WSM JavaBean model that represents a web service. The build-time > layer has a plug-point for generating source artifacts to support > various web service runtimes. For example, the Axis implementation > produces a serialized version of the WSM JavaBean model. This could > also produce JAX-RPC source / deployment descriptor artifacts, etc. > > runtime: The runtime side of WSM is specifically built to support > the Axis 1.x runtime. It loads the serialized JavaBean model > generated at build time and uses an Axis Handler to configure a > SOAPService given this information. > > There is another large bunch of code in WSM related to tools: > > wsdl2ajava -- this tool supports the top-down web service development > model and starts with a WSDL to produce an annotated Java source file. > This tool requires significant knowledge of WSDL and type mapping for > a specific web service stack. For example, the mapping for an XSD > year is mapped to org.apache.axis.types.Year and something different > on other web service stacks. wsdl2java is a non-trivial bunch of code > to write, but is also a very useful tool. > > In order to finish WSM, one more re-architecting step needs to be > completed; I'd like to remove the use of a serialized Java object as > the way to communicate from the build-time to runtime parts of the > implementation. This would be replaced with a WSDD like, but WSM > specific, XML descriptor of the service. AFAICT, WSDD can't be used > for this because too closely matches the shape of a Java class (Dims > and others, feel free to correct me if I'm wrong). So, we need a > simple XML file that describes the information captured in a > WsmService. > > Once this is done, we can start work on passing the JSR-181 TCK. > This will be done atop Apache Axis 1.x. > > In order to expedite the process of getting from here to TCK > compliance, I'd like to suggest that we stop stop work on the > wsdl2ajava tool in order to focus on finishing 1.0 and restart this > tool immediately post-1.0. > > Post 1.0, there are lots of other things that we could do including: > > - JDK 1.4 support > - drop-in support for WSM in Axis to support iteratively developing an > annotated web service > - JAX-RPC support (Ias, still have any interest in working on this?) > - custom annotations to support container-specific features like type mapping > - and so on... > > Personally, I'm chomping at the bit to get WSM's 1.0 done and would > like to narrow scope in order to do that. I think we're almost ready > for the TCK; I'll start on the XML file to describe an annotated Axis > web service shortly. > > Thoughts, comments, and flames welcome. > > Eddie > -- Davanum Srinivas : http://wso2.com/blogs/
