[jbosstools-dev] Wizards for Java2WSDL and WSDL2Java

[Rob Cernich]

Hey Brian,

Thanks for the reply.  I will certainly keep that in mind and drill deeper into the subtleties between the code generation features in the various frameworks.

One of the nice things about SwitchYard is that it abstracts the user from the underlying WS invocation/handling framework.  A side-effect of this is that the user may be required to generate transformations for converting XML<->Java (unless their service is implemented using another technology, e.g. Camel route or business process).  That said, SwitchYard supports a number of transformation frameworks including JAXB and Smooks.

So, for SY, the WSDL is used mainly for defining interfaces, with the gateways (bindings) being configured externally.  Obviously, there are some requirements on the port bindings, but these adhere to standards (i.e. doc-lit).  The early stages will probably require some tweaking of the generated wsdl on the part of the user (but that's less than they need to do today).  (Baby steps.)

After a bit more thought, I'll probably stage this work as follows:
1. basic code generation
2. integrate code generation into service promotion
3. integrate endpoint/binding configuration with service promotion.

The end goal being something nice like, "promote service through soap gateway."  User selects the service interface, wsdl is generated, context and port are configured, binding is added to switchyard.xml.  This is a long way off, but is the end goal.  (Other variants might be: add soap gateway, with the user selecting an existing wsdl; generate wsdl using existing schema; etc.)

Thanks again,
Rob

----- Original Message -----
> Hey Rob,
> 
> As we briefly discussed yesterday, I think if we go this route it
> would be great to have an easily pluggable solution to work around
> the less-than-friendly WTP wizards that do the same thing. But if we
> achieve this, I'd definitely be happy to switch to a simpler, more
> self-contained (and sane) framework within the Web Services tooling.
> 
> So far as I know, all the existing WS tooling requires that the
> project be a Dynamic Web Project. The upside of this is that we know
> what runtimes are associated with that project (i.e. JBoss AS 7,
> SOA-P 5.2, EAP, etc) and thus know which command-line tools to run
> to do the code generation for a top-down or bottom-up WS
> implementation.
> 
> IMO, though you may only need Axis2 for SwitchYard, if this is going
> to become the defacto standard for java2wsdl or wsdl2java code
> generation, we have to keep other runtimes in mind. If we go with
> Axis2 by itself, my concern is that we aren't supporting JBossWS,
> which we need for our runtime products.
> 
> --Fitz
> _______________________________
> Brian Fitzpatrick (aka "Fitz")
> Senior Software Engineer, SOA-P
> JBoss by Red Hat
> 
> ----- Original Message -----
> From: "Rob Cernich" <rcernich at redhat.com>
> To: "jbosstools-dev jbosstools-dev" <jbosstools-dev at lists.jboss.org>
> Sent: Monday, March 5, 2012 4:56:57 PM
> Subject: [jbosstools-dev] Wizards for Java2WSDL and WSDL2Java
> 
> Hey all,
> 
> One of the things missing from our toolset that would really improve
> productivity when developing SwitchYard applications is a mechansim
> for generating WSDL from Java, and, to a lesser degree, Java from
> WSDL.  Currently, SY relies on wsconsume and wsprovide for this
> functionality.
> 
> >From a tooling perspective, it seems that all the translators
> >require a dyanmic web project to invoke them.  Is this a correct
> >assessment?  Have I missed something?
> 
> So far, the best tool I've found (that meets the needs of SY) is the
> Axis2 code gen plugin.  The functionality is a bit sparse, but it
> works rather well, requiring minimal cleanup.  I think if the
> interface were improved, it might easily produce results that don't
> require any cleanup.
> 
> In addition to the translators, SY would need transformers created
> (or stubbed out) so the runtime could manage conversion between the
> types (e.g. Java2XML).  This makes me lean toward a custom SY
> solution, but I think it would be nice if the core could be shared.
> 
> Any ideas, opinions, comments, concerns...
> 
> Thanks in advance,
> Rob
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>