|
Hi John, Please see my comments
inline. > Thanks for your
comments so far. I'll post some tips on using the > existing Woden SVN
code. Where can I see your most recent WSDL2 > code....in the > Axis2 > CVS? The current Axis2 Code is in
the Apache SVN. https://svn.apache.org/repos/asf/webservices/axis/trunk/java/modules/wsdl/ > > From our initial call
with Dims, I was thinking that Axis would retain > it's WOM because of
dependencies in the code parser, code generator, > etc and that Woden
would have to somehow map it's WSDL model (2.0 and > 1.1) into the WOM via
the Axis WSDLOM Builder or from the WOM via the > Axis WSDL Writer. And
that it would have to do this with the Axis > efficiency goals in
mind (deferred pull parsing, etc). Your proposal > seems to mean moving
the WSDLOM Builder, the WSDL Writer and the WOM > into Woden, which seems
good because it eliminates duplication and > conversion, but it does
mean your internal Axis components become > directly dependent on
Woden. Woden will have various users whose > requirements will
influence the API, so I wonder if keeping your > existing WOM inside
Axis might help you manage the dependencies of the > Axis components that
use it. I guess it depends on the suitability > and stability of the
Woden WSDL API versus the complexity and > performance of some
Woden-to-Axis WOM conversion. > About the dependency of
Axis2 on Woden... We have a the package org.apache.wsdl which includes all the
interfaces for all the WSDL 2.0 components. Which I believe is similar to that
of the interfaces in org.apache.woden.wsdl20 package. Axis2 is properly interfaced
with WOM such that replacing the WOM will not be that difficult. You are absolutely right
about the API changes due to requests from other users, which might keep us
busy on this side, but think we are ready to go that extra mile for performance
and eliminate duplicate tree walking. WOM is in good shape(Other than the
duplicate tree walking) and we can continue with it until such time Woden API
stabilizes and takes its own shape. Btw, deferred building was
not a goal in the Axis2 WSDL parsing module. But usage of a single parser(ie
StAx) is a goal. > The Woden API under
development currently has some general framework > infrastructure in
org.apache.woden, like the factory and reader, and > then the actual WSDL
2.0 model API under org.apache.woden.wsdl20. > > We have been working on
a WSDL 2.0 model API that has 2 'levels': > > 1) a pure WSDL 2.0
'component' model as per the Component Model in > Part 1 of the 2.0 spec
(in package org.apache.woden.wsdl20). This is > an abstract or
'flattened' view of the WSDL that hides XML details and > the import/include
modularization. This model will be useful for > read-only scenarios
where the service information is important, but > not the underlying XML
or document composition (e.g. validating WSDL > 2.0 semantic rules). > > 2) a WSDL 2.0 'element'
model that supports the XML Infoset > representation of the
component model (in package >
org.apache.woden.wsdl20.xml). This model would be more useful for > read-write applications
where the XML details and structure are > important. I think this
is more like the WOM in Axis2. > Well my idea is that Axis2
will work on the option1 above. For most part in the Axis Engine level or Code
gen tool level we are not interested in the infoset representation of the
Component model. Will there be a mechanism to switch back and fourth from the
above two APIs? Are we going to extend the Element model from the component
model API ? > The Axis WSDL
Architecture wiki describes a WOM that is based on WSDL > 2.0 but generic enough
to accomodate wsdl 1.1 and I seem to remember > seeing some 1.1 features
in the WOM code (can't remember specific > examples). In your
comments below to > based component model
to handle both 1.1 and 2.0 wsdl. Do you mean a > 'pure' 2.0 model that
faithfully reflects the 2.0 spec or were you > considering a more
generic model that is 2.0 compliant but with 1.1 > additions.... something
like the WOM? > > It would be great if we
can parse any 1.1 wsdl document into a pure > 2.0 object model, but
even with a generic model we should probably > still consider various
use cases that may require different types of WSDL model: > > 1) WSDL4J/JWSDL users
wanting to move to Woden but with gradual > migration of their WSDL
may prefer to work with the JWSDL API > initially (i.e. Woden
readWSDL returns a javax.wsdl.Definition). > 2) new applications
based on WSDL 2.0 only may prefer a pure WSDL 2.0 > API (i.e. Woden
readWSDL returns a >
org.apache.woden.wsdl20.Description) > 3) Applications like
Axis that must support both 1.1 and 2.0 from > common tooling and
deployment code will require a model (pure or > generic 2.0) that can
accomodate both versions of wsdl. > > We could try to merge 2
and 3 into a single model and support 1 as the > migration case to bring
in the WSDL4J community. Yah you are right there are
wsdl 1.1 specific stuff in the WOM but they are obsolete and at this point I
believe we can live with WSDl 2.0 specific stuff alone. Note in our WOM there
is no construct that represent the WSDL 1.1 Message which is one of the main
issues in the WSDL 1.1 to 2.0 conversion. So we ll be happy with a 'pure' 2.0
model w.r.t. Axis2. But think we need to do a bit more engineering than that
for woden if we are to claim that we parse the WSDL 1.1 as well. So I am very
much +1 to try what you have suggested i.e. try to merge the requirements 2
and 3 into one model. >The key point is that > they > all share the same high
level API (factory, readWSDL methods, etc) >provided by the
framework. The framework could determine the version >of the WSDL document
its parsing, then return a wsdl model appropriate >to some user-specified
property or API call (perhaps a Woden WSDL 2.0 >model by default, or a
JWSDL model if requested). +1 > > Different strategies
can be used for instantiating these WSDL models > and avoiding
unnecessary conversions. For runtime efficiency, deferred > pull parsing (e.g. StAX
in Axis). For development time flexibility, > DOM-to-WSDL model
conversion (e.g. Xerces in Eclipse). Hence the > support for different
XML parsers within the Woden framework. > > What about
reversability? The wiki describes 1.1 and 2.0 > reversability being
preserved within the WOM so that a WOM created > from a 1.1 document
will be serialized back to a 1.1 document (likewise for 2.0 documents). > In > your comments to > from the original 1.1
document to a 2.0 wsdl document. Does this mean > we need to support both
requirements - preserving reversability where > needed and converting
from 1.1 to 2.0 documents where appropriate? > At the time of the original
architecture serialization of the WOM to different 1.1 and 2.0 versions was a
requirement due to the Java2WSDL architecture. Its not the a major requirement
now because we will most probably consider reusing java2WSDL tool in Axis 1.x.
It would be in the wish list (may be by writing different serialiser to Woden.)
Not a key requirement w.r.t. Axis2. All in all if we can come up
with a framework that make the migration of WSDL 1.1 --> 2.0 easy, more
successful this project will be and there will be wide acceptance for 2.0. Thanks Chathura |
- RE: Axis2 and wooden Lawrence Mandel
- RE: Axis2 and wooden Chathura Herath
- Re: Axis2 and wooden Arthur Ryman
