Re: [uddi-spec] WSDL: Comments on WSDL Technical Note

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

Claus,

Thanks for sending your comments.  I have responded inline below, <JC>like
this</JC>.

John Colgrave
----- Original Message -----
From: "Von Riegen, Claus" <claus.von.riegen@sap.com>
To: "'UDDI Spec TC'" <uddi-spec@lists.oasis-open.org>
Sent: Thursday, November 14, 2002 3:27 PM
Subject: [uddi-spec] WSDL: Comments on WSDL Technical Note


> As requested, here are my outstanding comments/issues/questions w.r.t. the
"Using WSDL in a UDDI Registry" Technical Note.
> Since I have not received an updated version so far, the comments are
based on the paper version that was distributed this Monday at the FTF.
>
> 1. General
> First of all, I'd like to thank John and Karsten for their tremendous
amount of work they have done in order to set this up.
> Also, I'd like to see the TC's formal review period for this Technical
Note to be started as soon as possible so that it can be publicly posted in
order to get early feedback from the general public. However, I still have
several issues that I'd like to be seen addressed or clarified.
>
> 2. Goals and Requirements
> I support the goal to allow deployment WSDL to be generated from UDDI
(which is not new in general), but the document is missing reasoning for
several of the detailed requirements in the later sections (see below).
>
> 3. Mapping wsdl:service to uddi:businessService
> There is no real need to map wsdl:service elements to uddi:businessService
elements. A service in WSDL is a logical grouping of ports and does not
contain any information that is relevant to Web service interoperability.
The information that is really required in order to invoke a Web service is
> obtained from the port and the artifacts it references (binding, portType,
operation, message). Since the requirements for grouping
uddi:bindingTemplate elements in uddi:businessService elements (for example,
a purchase order service that can be invoked by using different protocols)
can differ from
> the ones for grouping wsdl:port elements in wsdl:service elements (for
example, a purchase order Web service that is offered to different public
and private communities), I'd like to see the requirement for the one-to-one
mapping relaxed.
> This would mean to remove the sections for mapping wsdl:service to
uddi:businessService (section 2.6.3 in V2 and section 2.7.3 in V3)
completely.

<JC>
Even if we did relax the one-to-one mapping to one-to-many I think we would
still need to capture the namespace etc., we would simply be duplicating it
to each of the many businessServices.  I think we would still need the
equivalent of 2.6.3 and 2.7.3.  In the context of a UDDI TN/BP, I think it
is valid to describe what is the best case for UDDI, namely when the ports
represent alternate endpoints for the same portType.  I hope the WS-I Basic
Profile ends up saying something about this.  I will certainly give it some
more thought during the review period.
</JC>

> 4. Identifying wsdl:portType and wsdl:binding elements in uddi:tModel
registrations
> Rather than splitting the targetnamespace and the local name of portType
and binding elements when registering them as tModels, the tModel name could
also be built by concatenating them (sections 2.6.1, 2.6.2, 2.7.1, 2.7.2).
For example, the tModel that represents the UDDI V3 Inquiry API portType
> tModel would be named
"urn:uddi-org:api_v3_portType:UDDI_Inquiry_PortType". As a consequence, the
WSDL Namespace category system would be dispensable. Also, by using the URN
logic, one could easily search (even in V2) for
> * all tModels published by UDDI.org ("urn:uddi.org")
> * all tModels that represent a known UDDI API portType or binding (e.g.
"urn:uddi.org:api_v3_portType" or "urn:uddi.org:api_v3_binding")
> Searching for tModels based on the portType and binding name,
independently of their namespace, seems to me to be of minor importance.
However, this would be available in V3 by using the extended wildcard
mechanisms (e.g. "%UDDI_Inquiry_PortType").

<JC>
If I recall correctly, Karsten's original draft did this.  We felt that this
was not sufficiently flexible and I thought it would be useful for people to
be able to do a very simple query for a tModel corresponding to a portType
local name, especially when they wanted to see what the tModel looked like
rather than using WSDL tools to work with these things automatically.  As
you point out, the extended wildcard mechanism is only available in UDDI V3
and we wanted to support the same functionality in V2.

In general, I think this approach offers (slightly) less functionality, at
least in V2, and makes life more difficult for people and tools as they need
to spend time parsing the names and gluing the different pieces together.
</JC>

> 5. Registration of wsdl:port elements
> Sections 2.6.4 and 2.7.4 are missing reasoning why
> * to put the wsdl:port local name in the bindingTemplate's instanceParms
element (2.6.4) or in one of its keyedReference elements (2.7.4)
<JC>
This is being addressed.
</JC>
> * to reference the portType tModel while the binding tModel is already
referenced and thus allows the needed query - also, V3 (2.7.4) already
allows a one-step query by using a find_service with an embedded find_tModel
<JC>
There is a description of why this is done, it is to optimise queries for
implementations of a portType, which are likely to be the most common type
of query supported.  Yes, you can do an embedded query in V3 but we wanted,
in general, to be able to support the same queries as in V2 where possible
to aid migration for tool vendors etc.  If people do know the tModelKey then
it seems unnatural to force them to back up a step and find it again based
on its name, or other criteria.
</JC>
> * to reference the WSDL file that describes the wsdl:port (2.6.4) since
this is quite redundant to the mandatory accessPoint (if the
hostingRedirector is not used) - also, it would not be compatible to Version
1 of the WSDL Best Practice
<JC>
It is not redundant.  See my comments to your point 7. below.
</JC>
> * to categorize the bindingTemplate as being of type "port" (no other UDDI
artifacts can be of this type and the "WSDLness" can be discovered by the
referenced tModel
<JC>
By which referenced tModel?  There is no other way to be able to search for
any bindingTemplate that corresponds to a WSDL port.  This may also be
related to your point 7 below in that if you require extra address
information it is better to limit your search to WSDL-related
bindingTemplates as you can then have more confidence that they will have
the extra information.
</JC>
> 6. Registration of WSDL binding information in uddi:bindingTemplate
elements
> The registration of WSDL binding information, whether it is SOAP, HTTP or
another binding, in uddi:bindingTemplate elements (sections 2.6.4.1 - 3 and
2.7.4.1 - 3) seems to be at too low a level. The binding tModel should
already by typed strongly enough in order to provide all necessary binding
> information that is used in ALL Web service implementations that are
represented by corresponding bindingTemplate elements. Why should every
implementation be mandated to provide this information?
<JC>
It is so that you can limit your query to bindingTemplates that support
SOAP/HTTP for example rather than having to find all the SOAP/HTTP binding
tModels and then search for all bindingTemplates that have any or all of
those binding tModels.
</JC>
> 7. Other addresses
> How can an address be described in WSDL but not be mapped to the
uddi:accessPoint (sections .6.4.6 and 2.7.4.6)?
<JC>
We had a requirement that was reiterated several times and that, I believe
was related to WS-I work, to support address extensions in WSDL by being
able to defer address information to the WSDL file rather than mapping it
directly to the accessPoint.  The accessPoint is just a string, with a
maximum length of only 255 in V2 and 4096 in V3, so any type of address
information that does not correspond to this will require the use of the
WSDL file.
</JC>