[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 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? 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)? Best regards, Claus
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC