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

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

Claus,

See below.

John
----- Original Message -----
From: "Von Riegen, Claus" <claus.von.riegen@sap.com>
To: "'John Colgrave'" <colgrave@hursley.ibm.com>; "uddi-spec"
<uddi-spec@lists.oasis-open.org>
Sent: Wednesday, November 20, 2002 3:41 PM
Subject: RE: [uddi-spec] WSDL TN: Issue 2 - generation of wsdl:service


> John,
>
> Please find <CvR>my comments</CvR> below.
>
> Claus
>
> -----Original Message-----
> From: John Colgrave [mailto:colgrave@hursley.ibm.com]
> Sent: Mittwoch, 20. November 2002 12:11
> To: uddi-spec
> Subject: [uddi-spec] WSDL TN: Issue 2 - generation of wsdl:service
>
>
> 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.
>
> <CvR>I'm not arguing against the generation of WSDL deployment documents
in general. My issue is that I don't see a requirement so far to generate
the very same wsdl:service that was once described in the Web service
provider's WSDL deployment document previous to the registration of the WSDL
artifacts in UDDI.</CvR>

<JC>
I think I have already described that the wsdl:service is used with JAX-RPC
to generate a bunch of Java and the structure and operation of this Java
code depends on the namespace name and the port names, not to mention the
ports that are part of the service, so unless you generate the same
deployment WSDL from UDDI you will not get the same Java code generated so
two developers that happen to use two different tools will end up with
different Java interfaces to the same service, which is not good.

Given that you have to have the same service namespace, the same service
name, the same set of ports, each with the correct local name, I am not sure
you could do anything but generate an equivalent, if not identical,
deployment WSDL.
<JC>

> 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.
>
> <CvR>Assuming multiple people want to generate equivalent deployment WSDL
from the same UDDI metadata, this means that the Web service provider has to
separately publish the ports that are to be registered in UDDI. Each
resulting bindingTemplate can then be used by a Web service consumer to
generate corresponding deployment WSDL again. This is independent of the
fact whether or not the WSDL's namespaces and local names are captured in
the bindingTemplate. The Web service consumer can choose any naming
convention for the deployment WSDL's service and port elements in order to
generate proxies in the client infrastructure (this is the only reason I can
think of why the Web service consumer might have to generate the deployment
WSDL). What finally counts when the Web service is invoked at the Web
service provider's side is a valid message (specified by the WSDL portType)
that arrives over a suitable protocol (specified by the WSDL binding) at the
network address that was once spe!
> cified by the Web service provider (in the WSDL port extension).</CvR>

<JC>
You can't do the generation at the port level.  See comments above and in
another thread.

You have to have the right namespace name(s) and port names, and you have to
have the right set of ports if you want to be able to produce the same Java
code and have a single shared programming model for the service.

You are right that what finally counts at the web service provider's side is
what comes over the wire but you are adopting that limited WS-I viewpoint
again. :-)
</JC>

> 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.
>
> <CvR>This seems to be a reasonable approach but I don't see a reason yet
why we have to rely on the service's namespace and the port's local name
from the orginal deployment WSDL (see my comment above).</CvR>

<JC>
Partly because somebody may have already produced the "master" programming
language artefacts from it, which is just a special case of the fact that I
hope I have demonstrated that we can't leave it up to tools to just make up
these names therefore they have to be stored in UDDI.  Given that we have to
have them in UDDI they may as well be correct!
</JC>