OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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.

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

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

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

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

Best regards,

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC