[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [uddi-spec] WSDL TN: Issue 3 - UDDI V2 equivalent of wsdlDeployment
John, Please find <CvR>my comments</CvR> below. Claus -----Original Message----- From: John Colgrave [mailto:colgrave@hursley.ibm.com] Sent: Mittwoch, 20. November 2002 15:00 To: uddi-spec Subject: [uddi-spec] WSDL TN: Issue 3 - UDDI V2 equivalent of wsdlDeployment I think it is reasonable to support an approach for UDDI V2 equivalent to the UDDI V3 wsdlDeployment support. I think it is a valid requirement to defer to the WSDL file for the address/endpoint information and I do not want to force people to have to wait for a UDDI V3 implementation before being able to do so. I am not sure it warrants changing the V2 specification however, but I do not think that is necessary with the modified proposal below. <CvR>V2 is done and your proposal doesn't seem to fix something that is currently broken. Thus, I agree to not change V2.</CvR> It has been pointed out that an empty accessPoint value is not valid, and Karsten has suggested using the URL as the value, which I think is a very good idea, not least because it is very close to the V3 wsdlDeployment approach. So, the remaining issues are how to model this correctly without changing the V2 specification. <CvR>Well, an empty accessPoint ("") is theoretically valid since the UDDI V2 schema allows it, but since the specification states that the "service entry point" has to be obtained from the accessPoint element, there is practically no way to a) leave it empty or b) to let it point to something else than the Web service endpoint.</CvR> In V2, the accessPoint has a URLType attribute and one of the values of that is "other" and when "other" is used, one of the tModelInstanceInfos must imply the meaning of the accessPoint value. My proposal is that we say that in the V2 equivalent of wsdlDeployment, we use a URLType of "other" and we put the URL of the deployment WSDL file in the value of the accessPoint. To disambiguate this case from any other use of "other", we have the tModelInstanceInfo for the WSDL URL Reference tModel that is currently used. The instanceParms can now be removed as the URL is the accessPoint value. <CvR>While this proposal is consistent by itself, it does not fit to the general idea of the accessPoint and the URLType's value "other". Even if this value is used, the accessPoint must still be the service entry point, but its format (that can not be specified by any other URLType value) is described in one of the tModelInstanceInfo elements. Also, in V3 we decided to remove the URLType attribute since it can be derived from the accessPoint's value already. I could think of tools that already do so in V2 - if the accessPoint's value starts with "http", then the service entry point is a URL. This would not work for your proposal since the WSDL document is also referenced by a URL.</CvR> This tModel also neatly provides an equivalent of the wsdlDeployment categorisation of a bindingTemplate that V3 suggests also. John ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC