beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eddie O'Neil <>
Subject Re: Annotation parsing framework for Axis2 (Re: [wsm] a plan)
Date Mon, 06 Feb 2006 00:54:48 GMT

  Hey; apologies for the delay.  That's basically right -- there is
actually one other step in the annotation processing pipeline which is
verifying the validity of any annotations on the class.  So, it would

  annotation checking (Jsr181AnnotationChecker) --> model building

which returns a WsmService object that can be wired up into axis2 stuff.

  I can certainly break the Axis 1.x stuff into a separate JAR; my
original plan was to just put the Axis 1.x and 2 bits in the same JAR
file, but if this is a problem, let me know and I can make three JARs
-- generic web service processing code, axis 1, axis 2, etc.

  There is one important part of this that isn't done yet, and that's
to provide something that can be used inside of a server runtime that
abstracts from Sun's Mirror types which are used inside of APT.  Not
exactly sure what this looks like yet -- could be reflection or
something else that abstracts from Sun's Mirror APIs (used inside of

  Do you want to run this from inside of the Axis2 runtime or at
build-time on the command line?  I'm assuming the former.


On 2/1/06, Davanum Srinivas <> wrote:
> 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 <> 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 :

View raw message