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

["Von Riegen, Claus" <claus.von.riegen@sap.com>]

Anne,

Thanks for your feedback.
Actually, most of my issues are related to the redundant nature of the requirements to capture WSDL details in UDDI.
I'd simply want to make registrations of Web service types and Web services as easy as possible for their provider. If parts of the registration information is redundant, it is more likely that changes to the registrations make the data either inconsistent or prevent the required queries we all want to see supported.

See my response inline.

Claus

-----Original Message-----
From: Anne Thomas Manes [mailto:anne@manes.net]
Sent: Donnerstag, 14. November 2002 22:12
To: Von Riegen, Claus; 'UDDI Spec TC'
Subject: RE: [uddi-spec] WSDL: Comments on WSDL Technical Note


Claus,

Thank you for your detailed comments. See responses/comments inline...

Anne

> -----Original Message-----
> From: Von Riegen, Claus [mailto:claus.von.riegen@sap.com]
> Sent: Thursday, November 14, 2002 10:28 AM
> To: 'UDDI Spec TC'
> 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).

The latest draft provides much more specific requirements and rationale.

> 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.

One of the requirements is to enable automatic registration of services in
UDDI from a WSDL file. If we do not provide mapping of wsdl:service to
uddi:businessService, then I don't see how we can make this registration
fully automatic. Ports belong to a service, and bindingTemplates must be
grouped within a businessService. I think the issue is that a logical
business service in UDDI doesn't always correspond to the physical
collection of ports described in a WSDL service.

<CvR>Exactly. That is why a one-to-one mapping of wsdl:service to uddi:businessService doesn't help but rather eventually contradicts to the UDDI architecture. If a Web service developer wants to publish a Web service as a uddi:bindingTemplate within a new uddi:businessService, then the wsdl:service name might help to name it, although the WSDL description doesn't help to categorize the businessService in more business-related terms. But to rely on the information that is registered with a uddi:businessService in order to find a corresponding wsdl:service doesn't work if wsdl:port elements from multiple wsdl:service elements are published within one uddi:businessService.</CvR>

I recommend that we
maintain the one-to-one mapping, specify a recommended practice for the
collection of ports within a service (currently in a footnote), and
recommend a practice of using projection to associate the WSDL-generated
businessServices with a more logical UDDI businessService.

<CvR>I support the idea to develop a recommendation how to model wsdl:port elements in wsdl:service elements, but still don't see a need to map wsdl:service to uddi:businessService. Even reconstructing wsdl:service FROM uddi:businessService is not a goal for the technical note, IMO. It doesn't help interoperability. How can a service projection help here? It does not contain any information apart from the projected service.</CvR>

There are still some issues with the current mappings, though, as I've
outlined in the comments in the latest draft.

> 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").

Interesting proposal. It doesn't provide a way for us to capture the
namespace and local name for a service or port, though.

<CvR>IMO, we don't need the namespace and local name for wsdl:service and wsdl:port elements when they are published as UDDI.artifacts.</CvR>

Note: in the latest
draft these tModels have been made more generic. They are general purpose
XML namespace and XML local name tModels, rather than WSDL-specific tModels.

> 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)

There is a requirement that a user should be able to find the WSDL
definition of the port. There is no other way to capture the local name.

<CvR>What do I need the wsdl:port for when the uddi:bindingTemplate already contains the Web service's network address? Regardless of the wsdl:port's binding extension mechanism, it MUST not specify more than one address and MUST NOT contain any information other than the address (as defined by WSDL 1.1, section 2.6).</CvR>

> *	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

There is a requirement that a user should be able to search for a service
that implements a portType without specifying a specific binding. e.g., I
want to find all services that implement the foo portType. Bindings are
usually specific to particular implementations (e.g., soapAction, header
messages, etc.), so users cannot search e.g., for all services that support
SOAP implementations of the foo portType by specifying a particular binding.
They must be able to search by portType.

<CvR>I understand the requirement, but I do not understand the solution, which is pretty redundant. The portType tModel is already captured in the referenced binding tModel. V3 was explicitely enhanced in order to allow more complex queries like these. Since the binding tModels reference the portType tModels by using the WSDL portType Reference tModel, the V3 example in section 3.5.3 (find implementations of portType)

	<find_binding xmlns="urn:uddi-org:api_v3">
	    <tModelBag>
	        <tModelKey>uddi:e8cf1163-8234-4b35-865f-94a7322e40c3</tModelKey>
	    </tModelBag>
	</find_binding>

can easily be changed to

	<find_binding xmlns="urn:uddi-org:api_v3">
	    <find_tModel xmlns="urn:uddi-org:api_v3">
	        <categoryBag>
	            <keyedReference
	                tModelKey="uddi:uddi.org:wsdl:portTypeReference"
	                keyValue="uddi:e8cf1163-8234-4b35-865f-94a7322e40c3" />
	        </categoryBag>
	    </find_tModel>
	</find_binding>

and makes the portType tModel reference in the bindingTemplate dispensable.
V2 does not allow this direct query but the requirement can still be met by performing two subsequent queries - one for all binding tModels that reference the portType tModel

	<find_tModel generic="2.0" xmlns="urn:uddi-org:api_v2">
	    <categoryBag>
	        <keyedReference 
	          tModelKey="uuid:d3e8ef29-877e-3486-b9e2-46af338d6c85"
	          keyName="portType reference"
	          keyValue="uuid:e8cf1163-8234-4b35-865f-94a7322e40c3"/>
	    </categoryBag>
	</find_tModel>

and another to find all bindingTemplates that implement one of the found bindings

	<find_binding generic="2.0" xmlns="urn:uddi-org:api_v2">
	    <tModelBag>
	        ... all tModelKeys that were found in the previous query ...
	    </tModelBag>
	</find_binding>

I'd rather see this as a missing feature in V2 and do not want to make Web service registrations more and more complex and redundant.</CvR>

> *	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

There is a requirement that a user should be able to find the WSDL
definition of the port -- perhaps to find other extensibility elements that
have not been captured in the bindingTemplate.

<CvR>Can you give an example of a port extensibility element that has not been captured in the bindingTemplate?</CvR>

I don't see how this is incompatible with the V1 BP. The bindingTemplate
still specifies the accessPoint and still provides a tModelInstanceInfo for
the binding tModel.

<CvR>Appendix 5 WSDL URL Reference tModel states that "A service provider may not want to specify the address of a service port in the uddi:accessPoint element and instead require the user to retrieve a WSDL file to obtain the service address." This is either inconsistent with the UDDI specification (the accessPoint is required, unless the hostingRedirector is used) or redundant (if the accessPoint is specified).</CvR>
 
> *	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

I agree. I see no reason why the type information is required.

> 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?

This is similar to your second point in question 5. There is a requirement
that a user should be able to search for a service that implements a
portType supporting a specific protocols without specifying a specific
binding. e.g., I want to find all services that implement the foo portType
using SOAP over HTTP. (Bindings are usually specific to particular
implementations: e.g., soapAction, header messages, etc.)

<CvR>If the binding tModels are categorized accordingly, which is the "natural" UDDI philosophy, the very same query can be performed by

	<find_binding xmlns="urn:uddi-org:api_v3">
	    <tModelBag>
	        <tModelKey>uddi:uddi.org:protocol:soap</tModelKey>
	    </tModelBag>
	    <find_tModel xmlns="urn:uddi-org:api_v3">
	        <categoryBag>
	            <keyedReference
	                tModelKey="uddi:uddi.org:wsdl:portTypeReference"
	                keyValue="uddi:e8cf1163-8234-4b35-865f-94a7322e40c3" />
	        </categoryBag>
	    </find_tModel>
	</find_binding>

and makes the "protocol" reference in ALL bindingTemplates dispensable. However, the tModels that represent protocols would have to be categorized as being category systems rather than protocols - we could also consider to extend the UDDI Types category system or define a separate one that contains all protocol types we need.</CvR>

>
> 7. Other addresses
> How can an address be described in WSDL but not be mapped to the
> uddi:accessPoint (sections 2.6.4.6 and 2.7.4.6)?

The information might be in the WSDL, but the published may elect to have
the consumer retrieve the address from the WSDL at runtime (i.e.,
wsdlDeployment). Perhaps the wording should be clarified to indicate that
it's the publisher's choice (rather than the information is unavailable).

<CvR>Again, the uddi:accessPoint is required and the WSDL Best Practice V1 doesn't work if it is left blank (""). All in all, I would disallow the use of URLs of type "wsdlDeployment" in the WSDL Technical Note since all necessary information is given by the referenced binding tModel. Using deployment WSDLs makes sense to me only if the service provider doesn't want to provide reusable artifacts (tModels).</CvR>

>
> Best regards,
>  Claus
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>