Maybe others are taking this for granted, but I think it would help to get clear on why exactly we need a Tuscany SEI2WSDL/WSDL2SEI toolset, as opposed to, say, leveraging and extending something like the CXF toolset.
I can see these arguments: A) There are SCA-specific aspects of the artifacts to deal with and other tools are not extensible enough. Example: A SEI2WSDL tool should handle the SCA @OneWay in addition to the JAX-WS @Oneway B) The databinding extensibility/pluggability mechanims in other toolsets (CXF) are not flexible/robust enough. (We certainly know this is true of JAXWS RI). C) We care about more than just Java as the SEI, but others don't? D) We want to provide a tool-time mapping which matches our runtime mapping. ------------------------------------------------------------------------------ I'm not familiar enough w/ other tools to argue A) or B), but I'm assuming that D) is the most important reason for most people. While it does seem inefficient for every Apache WS-related project to have to implement all the JAX-WS rules from scratch, and while we might hope that any tool "following the spec (JAXWS)" (plus whatever databinding introspection rules Tuscany establishes) should work.... we want to have a single tool that we have control of as a project. If we take, for example, the time not too long ago where we debated an aspect of the rules for calculating that a WSDL was doc-lit-wrapped, it would help to have a single tool that for certain shared the same interpretation as the runtime. ----- Before we go writing code to support all the JAX-WS WSDL customizations, have we agreed that this is why we are doing this? Scott On Fri, May 23, 2008 at 5:23 AM, ant elder <[EMAIL PROTECTED]> wrote: > On Thu, May 22, 2008 at 6:02 PM, Raymond Feng <[EMAIL PROTECTED]> wrote: > > <snip> > > Anyway, so would we be committing to doing this in time for the next > >> release? If so I can stop looking at upgrading the exsiting tools to > work > >> with Axis2 1.4. Or is this just "something to look at in the furture" > and > >> I > >> still need to get the existing tools running with Axis2 1.4 in time for > >> our > >> next SCA release? > >> > > > > Effort wise, which approach requires more? We need to make a good balance > > here. If the migration to 1.4 is an one-day work, then I think it's worth > to > > migrate it 1st to have a working base. > > > > > Its not just about getting the old tool working again though - the current > tool code produces different wsdl than what the runtime does and it will > get > even more different as we switch to the new runtime wsdl generation code, > and AFAICT we have nothing that uses the current tool, no doc on how to use > it, and no testcases. Yes writing a new tool based on the new runtime wsdl > generation code is more effort but isn't that inevertably going to happen > so > spending any more time on the old tool code a bit redundant? > > ...ant >
