Please see my comments inline. Thanks, Raymond
[[snip]]
The question then is, what do we want these tools to do? Some thoughts from my point of view. This is just my view and others may disagree... - The runtime J2WSDL should be able to generate WSDL for Java interfaces for the Java interface styles that Tuscany SCA supports. Specifically I mean that our runtime tooling should be able to handle the various databindings that we support for java interfaces, e.g. SDO, JAXB, etc. It's not necessary that they are all supported straight away but we should have an approach that means we see how they could be supported.
+1. To be precise, we should have J2WSDL and J2XSD. J2WSDL maps a java interface to a WSDL portType following the JAXWS rules as required by the SCA spec. The J2XSD maps parameter/return/exception types to XML schema definitions. The J2XSD should be made extensible on databinding bases. For example, both SDO and JAXB have the capability to generate XSD out of its typing metadata.
- We should try and adopt existing technology for doing this generation where possible, Axis2, CxF etc. rather than writing our own
I would argue based the following reasons: 1) Interface types are extensible in SCA. So far we support WSDL 1.1 portTypes and Java interfaces. We might add more such as WSDL 2.0 or even CORBA IDL. The nice thing is that we have a neutral Interface/Operation model. We map native interface definitions to our Interface/Operation model and we just don't have the generation from our Interface/Operation to a native interface definitions yet. 2) Regardless of the generation, we need to implement the mapping rules anyway to validate the compatibility of SCA service/reference interfaces defined in different IDLs. 3) We should try to implement Interface/Operation to WSDL/XSD (instead of Java to WSDL/XSD). The 2WSDL part should be fairly straightforward (I can prototype). We could reuse some code from Axis2/CXF by copying. The 2XSD part can be handled by databindings. AFAIK, both SDO and JAXB provide such APIs to handle that. Existing tools often don't have the flexibility we need, for example, support different databindings, honoring SCA annotations.
- We may need to make changes over and above the basic generation provided by tools, such as Axis, to fix faults and add extra function, e.g. [1] and I know Raymond has been working on making sure we adopt a JAXWS mapping for java2wsdl generation. Also there are extra annotations that we may want to introduce in the WSDL based on service configuration.
This is the part I don't favor calling existing tools as-is, patching the generated code is not fun :-(.
- We shouldn't have two sets of tooling implemented in different ways to do this stuff
In some cases, we could even use the JAXWS wsgen/wsimport tools as-is if the preferred databinding is JAXB.
There has been previous discussion of this in [2] but I don't know where Simon got to. It sounds like we need a tool into which we can plug WSDL and XSD generators and also plug in post generation processors. As Scott points out the runtime Java2WSDL currently has different capability compared with the developer tooling. I'm with Alex on this, If we can further develop the runtime tool then does anyone have any good reason why we can't use the same code for the developer tool? Simon [1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg28531.html [2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg27855.html
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
