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

[Anne Thomas Manes <anne@manes.net>]

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

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

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

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

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.

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

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