OSOA->OASIS spec change: wsdlgen not required in component/service name in TNS

[Scott Kurz <sc...@gmail.com>]

Just looking at the OASIS web services binding spec and noticing that the
OSOA requirement to generate a WSDL def in targetNamespace of
"HTTP Base URI/componentName/serviceName" has been dropped.

I wonder if we'd want to avoid that extra complexity, then?    Or maybe only
use it in the "bottom-up" case without an existing WSDL (I think there's
some value in the case where the user supplies a service/port definition on
a service-side binding.ws to simply use it without further mangling).

This is sounding like I should open a JIRA, but curious to hear any thoughts
in the meantime.   I think Simon Nash worked on some of this...

Thanks
Scott

Re: OSOA->OASIS spec change: wsdlgen not required in component/service name in TNS

[Simon Nash <na...@apache.org>]

Scott Kurz wrote:
> Just looking at the OASIS web services binding spec and noticing that 
> the OSOA requirement to generate a WSDL def in targetNamespace of
> "HTTP Base URI/componentName/serviceName" has been dropped.
> 
> I wonder if we'd want to avoid that extra complexity, then?    Or maybe 
> only use it in the "bottom-up" case without an existing WSDL (I think 
> there's some value in the case where the user supplies a service/port 
> definition on a service-side binding.ws <http://binding.ws> to simply 
> use it without further mangling).
> 
> This is sounding like I should open a JIRA, but curious to hear any 
> thoughts in the meantime.   I think Simon Nash worked on some of this...
> 
> Thanks
> Scott
> 
There's no problem with changing the namespace to something else if
we want to.  However, I presume this isn't just about changing the
namespace, but also about eliminating the generated "wrapper" WSDL
if the user has provided a WSDL file already.

The generated wrapper WSDL isn't just used to put definitions in a
particular namespace.  It ensures that extraneous information in a
user-provided WSDL isn't used by Tuscany or exposed by ?wsdl, and it
enables Tuscany to insert the correct service and port definitions
in the ?wsdl result based on the runtime deployment configuration.

For example, if a WSDL file is specified by interface.wsdl, only the
portType is relevant and any other information in the WSDL file must be
ignored and must not be exposed by ?wsdl.  Similarly, if a WSDL file
is specified by binding.ws with #wsdl.binding, any service and port
information in the WSDL file (as well as other bindings) must be ignored
and must not be exposed by ?wsdl.  The wrapper WSDL approach takes care
of these situations.

The generated wrapper WSDL also allows Tuscany to insert the correct
service and port definitions in the ?wsdl result.  It's unlikely that
a user-provided WSDL file would contain the correct values.

So, although eliminating the wrapper WSDL seems like a simplification,
I'm not sure if there are many (any?) cases where it would be possible
without causing problems.

   Simon