[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [uddi-spec] WSDL TN: Issue 4 - tagging of bindingTemplate withprotocol/transport
The main reason for identifying the protocol and/or transport in the bindingTemplate instead of, perhaps as well as, the binding tModel is to allow efficient queries independent of a particular binding. If there are 10 different SOAP/HTTP bindings for a (popular) portType tModel then it is much more efficient to do a query for bindingTemplates that are tagged with SOAP and HTTP than to do a query for bindingTemplates that have one of 10 different tModel keys in their fingerprint. I must apologise for not spending enough time looking at V2 before criticising your example. I looked at the description of find_binding and it did not mention the orAllKeys find qualifier so I assumed that it did not apply to find_binding, but the appendix does describe it as applying so your modified example would work, but it would be much less efficient. It would also change the semantics of the matching of the other tModels, which may not be what was desired. For example, if you wanted to do a query for a bindingTemplate that implemented a particular portType and used SOAP/HTTP and ... you could not do that if you had to use orAllKeys so you would match many more bindingTemplates that you would have to sift through manually. I would be quite happy to add soapSpec to a SOAP binding tModel but I doubt it would ever be used. Another issue is that it would be much harder to add vendor-specific valid values to the types categorization whereas anyone can register a protocol or transport tModel. This tagging of the bindingTemplate is allowed for by UDDI, at least the V3 spec. (I haven't checked the V2 spec.). In section 11.3 of the V3 spec. it says: "tModels of the transport and protocol sort are referenced by service bindings to describe the type of protocol or transport used to invoke the service. This is often done...or when the provider of the Web service wants to explicitly call out the protocol or transport in the technical fingerprint, to enable proper discovery." and I would regard this usage of protocol and transport tModels very much as enabling proper discovery. John
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC