Mike Edwards wrote:
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.
Mike, +1 to everything you said. I think it's in line with what I was
trying to describe earlier in this thread [1].
I had missed the impact of policies in [1], rephrasing it here to add
the policy aspect:
- 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, the service
endpoint declaration ...
... and additional configuration determined by the policy sets applied
to the binding).
[1] http://marc.info/?l=tuscany-dev&m=120199391108418
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
