Simon Laws wrote:
On Jan 31, 2008 5:04 PM, Lou Amodeo <[EMAIL PROTECTED]> wrote:
Hi, I have a question about the implementation of the "wsdlless"
deployment
function.
The issues I see are occurring in a couple of places within the
life-cycle.
Namely, deployment, binding start, and service definition. It occurs to me
that if the generation of the wsdl occurred early in the process, rather
than during the startup of the component, Tuscany could maintain a common
code path for contributions with wsdl and contributions w/o wsdl. Today
for
instance WSDL is processed in the WSBindingProcessor when its present and
the Axis2ServiceBinding when its not. I am curious why this is so? Why
wouldn't the WSBindingProcessor detect wsdlLess, generate a wsdl
definition
at that point and the subsuquent flow from there on would be the same?
Alternatively, when a contribution is deployed, why not detect a wsdl is
missing, generate one, and place it in the contribution. At this point a
wsdlElement could also be added and the subsequent startup process would
not
know the difference? I am not sure if other bindings will adopt a wsdlless
approach but I would think a common non-binding specific process would be
beneficial.
Thanks for your help.
Hi Lou,
Anything we can do to simplify our code path is a good thing IMO.
More specifically I'm attracted by your idea of having the wsdl processing
happen in one place and I think this could work well for the model generated
in memory when a composite is processed. The WSDL interface contract could
be built in the earlier phases of composite processing and the code at the
top of Axis2ServiceBindingProvider
InterfaceContract contract = wsBinding.getBindingInterfaceContract
();
if (contract == null) {
contract = service.getInterfaceContract
().makeUnidirectional(false);
if ((contract instanceof JavaInterfaceContract)) {
contract =
Java2WSDLHelper.createWSDLInterfaceContract((JavaInterfaceContract)contract,
requiresSOAP12(wsBinding));
}
wsBinding.setBindingInterfaceContract(contract);
}
Could be reworked or removed..
Could you say a little more about the alternative you propose,
"Alternatively, when a contribution is deployed, why not detect a wsdl is
missing, generate one, and place it in the contribution. ". What you you
mean by "deployed" here. I'm asking in relation to two other threads that
are ongoing.
In the discussion [1] about reference targets I've been floating the idea of
having a contribution processing phase in the domain that fixes up
contributions before they are deployed to nodes. I had been thinking about
URIs but this WSDL point could be another one of the things that could be
done ahead of time. In that way the Node would always be presented with a
WSDL file in the deployed contribution.
In the discussion [2] about the runtime Java2WSDL processing you suggest
that you want to write the generated WSDL out as a file as an alternative to
providing access to it via ?wsdl. Moving this processing forward would make
this related fix easier. My question here is where should the WSDL file be
written to? I'll ask that back over on the other thread.
Regards
Simon
[1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27294.html
[2] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg27532.html
I agree with Lou and Simon on the overall approach.
I've expressed concerns with the current WSDL-less support design before
[3] and I think it's broken as it's not considering the SCA interface
and data binding metadata to generate the WSDL+XSD.
Here's what I think should happen:
- A clean interface-model-to-WSDL4J generator should be developed in the
interface-wsdl module.
- The generator should use the databinding metadata (including any
knowledge of handwritten XSD representing the business data and
generation capabilities like the SDO XSDGenerator) to generate proper
XSD in the WSDL.
- The WSDL4J model should be produced earlier in the composite
processing cycle and passed to the binding that will need it, allowing
it to add binding specific info (e.g SOAP binding and the service
endpoint declaration).
- The complete WSDL should be used to configure the underlying WS stack
(Axis2 or other), leading to a single and simpler binding code path.
I don't think it's wise to store the WSDL in the SCA contribution at
deployment time as it can be calculated and storing it is the best way
to get it out of sync with the other artifacts and cause confusion.
[3] https://issues.apache.org/jira/browse/TUSCANY-1556
Here are a few other related JIRAs. I think it's about time to redesign
that WSDL-less support and make it right.
https://issues.apache.org/jira/browse/TUSCANY-1713
https://issues.apache.org/jira/browse/TUSCANY-1648
https://issues.apache.org/jira/browse/TUSCANY-1544
https://issues.apache.org/jira/browse/TUSCANY-1557
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
