I think for consistency and to avoid exposing project dependencies Woden should not be a flag or used in the Axis naming convention.
For example,
Java2WSDL -wsdlversion woden .....
should be
Java2WSDL -wsdlversion 2.0 .....
and
WSDL11TOAxisServieBuilder (just a mater of renaming)
WodenToAxisServiceBuilder
should be
WSDL11TOAxisServieBuilder (just a mater of renaming)
WSDL20ToAxisServiceBuilder
The following int WSDL version parameter also concerns me as, although I'm not aware of any plans, there's nothing stopping the WSDL working group from creating a WSDL 2.1:
public ServiceClient(ConfigurationContext configContext, URL wsdlURL,
QName wsdlServiceName, String portName, int
wsdlVersion)
Overall it's great to see that you've started thinking about these issues and have proposed some initial solutions.
Thanks!
Lawrence Mandel
| "Chathura Herath"
<[EMAIL PROTECTED]>
05/17/2006 12:11 PM
|
|
Hi,
I have been working on integrating woden to Axis2 and here is a summery
There are three areas that has dependencies on WSDLs. Namely,
WSDL2JAVA, ClientAPI, JAVA2WSDL.
WSDL2JAVA:
The proposal is to support both wsdl4j based and woden based code
generation. This way we can keep wdl4j for wsdl 1.1(which is already
inplace) and use woden for parsing WSDL 2.0 files. Idea is to put a
switch in the code generation so that one can opt for wsdl4j or woden.
Something like
Java2WSDL -wsdlversion woden .....
(Or may be later we can add a AXIOM based util that determines the
WSDL version. I wonder woden already have this kind of utility)
Code generation currently relies on the AxisService which eliminates
the direct dependency on a particular wsdl parser. So its well
decoupled already using a WSDL2AxisServiceBuilder. The proposal is to
interface this and introduce
WSDL11TOAxisServieBuilder (just a mater of renaming)
WodenToAxisServiceBuilder
I trust the emitters will work as anticipated and produce the proper
outputs given the AxisService is built correctly.
Client API:
1)Following constructor to be added to ServiceClient so that it will
have its woden counterpart for Creating ServiceClient
public ServiceClient(ConfigurationContext configContext,
DescriptionElement description,
QName wsdlServiceName, String portName)
2)The following mothod is now kind of ambigious form axis2 point of view.
public ServiceClient(ConfigurationContext configContext, URL wsdlURL,
QName wsdlServiceName, String portName)
We have three choises.
a) Add a unambiguating parameter live WSDLVersion
eg:
public ServiceClient(ConfigurationContext configContext, URL wsdlURL,
QName wsdlServiceName, String portName, int
wsdlVersion)
This would be easy to implement but would require changes in the API,
which i believe is bad.
b)Use a utility to determine the wsdl version and keep the API as it is.
This would require reading the file twice, may be not so cool if the
URL is a remote host.
c) Keep the current API s intact and add another overloaded constructor
public ServiceClient(ConfigurationContext configContext, URL wsdlURL,
QName wsdlServiceName, String portName, int
wsdlVersion)
JAVA2WSDL
Right now we use Axiom to build and serialise the WSDL. We could
either extend this for writing WSDL 2.0 document. The woden currently
has a WSDL 1.1 to WSDL 2.0 converter. I havent tested it but i think
we could use that for immediate usage.
I have done some work on the wsdl2java module and the builders and
could commit it in if this sounds ok.
Hope to produce a deliverable before the 6th June woden Interop.
Thanks
--
Chathura Herath
http://people.apache.org/~chathura/
http://chathurah.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
