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
