[uddi-spec] WSDL TN: Issue 2 - generation of wsdl:service

[John Colgrave <colgrave@hursley.ibm.com>]

This requirement was raised by Karsten, and I believe the current IBM
tooling generates the deployment WSDL so it would seem to be a requirement
of at least Microsoft and IBM.  In general I can readily envision
application development/deployment tools that will generate the deployment
information as a service is deployed.  If these tools work with UDDI, the
obvious thing for them to do would be to generate the UDDI metadata
dynamically and add it to the registry.  To work with programming languages
such as Java however, they would need to produce the deployment WSDL so that
the correct service class etc. could be generated.

If a different person wanted to use the deployment WSDL, I would think it
would be useful for them also to be able to generate it from the same UDDI
registry using a tool.  This is the kind of thing that the current IBM tools
do.

The namespace name and local name are required for the generation of the
deployment WSDL for two reasons:

1) The proposal on the table in the W3C WSDL group for equivalence is for
QName-based equivalence, so two WSDL services would be regarded as
equivalent if they had the same namespace name and the same local name.
Similarly for ports etc.  Assuming multiple people want to generate
equivalent deployment WSDL from the same UDDI metadata, this means that we
have to capture the namespace name and the local name of each WSDL element
that might be compared.

2) The namespace name and local name are used, for example, in the
generation of Java from WSDL, where the namespace name is mapped to a Java
package and the local name is mapped to a class name, or just used with the
namespace name to identify something, a port for example, via a
javax.xml.namespace.QName, so the QName is surfaced as part of the
programming model.

John