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(a)redhat.com>
To: "jbosstools-dev jbosstools-dev" <jbosstools-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev