Folks,
ant elder 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.
I think the issue may be at what point the information required to generate
the wsdl becomes available. When <binding.ws> is used without the
wsdlElement attribute then the wsdl comes from the service or reference
interface and if thats not <interface.wsdl> then this is when a wsdl needs
to be generated. I'm not sure if the service or reference interface is going
to be available anywhere when the WebServiceBindingProcessor resolve method
is called.
...ant
It is important to remember that when an interface is specified EITHER
as some non-WSDL interface type (eg Java interface) OR where it is
specified as WSDL, the FINAL WSDL that is necessary for a deployed (web)
service may need generating from the original interface definition.
The SCA metadata can include Policy information that is likely missing
from the original interface definition (eg need for encryption of the
messages). This extra SCA metadata needs to be processed before the
final WSDL can be generated and may involve things like reading policy
sets to determine the correct layout and content of the final WSDL.
The final processed version of the WSDL should not be placed back into
the contribution in case of any updates to the Domain as a whole (eg
someone decides on a change of policy set for the domain as a whole),
since that would require recalculation of the generated WSDL (not
something we do now, but useful to think ahead).
Yours, Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
