[uddi-spec] WSDL TN: Issue 4 - tagging of bindingTemplate withprotocol/transport

[John Colgrave <colgrave@hursley.ibm.com>]

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