RE: [uddi-spec] WSDL TN: Issue 4 - tagging of bindingTemplate wit hprotocol/transport

["Von Riegen, Claus" <claus.von.riegen@sap.com>]

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:23
To: uddi-spec
Subject: [uddi-spec] WSDL TN: Issue 4 - tagging of bindingTemplate with
protocol/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.

<CvR>IMO, efficiency in discovery is of minor importance than consistency in publication. Even in V3, bindingTemplates were never meant to be adorned with information about the Web service type's binding, which we now want to describe in the binding tModel. bindingTemplates rather contain implementation-specific information, additionally to the binding tModel. Since some queries, like the one you are looking for, can't be performed in one step in V2, we explicitely added the embedded find_tModel query in find_business, find_service and find_binding. Are you now questioning the relevance of this feature?</CvR>

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.

<CvR>I would still use no find qualifier in the find_tModel query for the binding tModel that has a reference to a particular portType and uses SOAP/HTTP etc. (equivalent to andAllKeys) and orAllKeys in the find_binding query with all found binding tModel tModelKeys. Neither V2 nor V3 allow more complex logical expressions like (tModel A and tModel B) or (tModel C and tModel D). I think this is part of what Matthew Dovey is looking for with his idea for V4.</CvR>

I would be quite happy to add soapSpec to a SOAP binding tModel but I doubt
it would ever be used.

<CvR>This is what the UDDI specification describes and the WSDL TN maybe should reiterate.</CvR>

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.

<CvR>Good point. We should look closely once more at the UDDI Types category system in V3 in order to make sure that it contains all needed standard values. Vendor-specific values can be specified in a vendor-specific categorization system, if needed.</CvR>

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.

<CvR>Tagging of bindingTemplates with tModels of the transport and protocol sort is meant to be done when there is either no other tModel that describes the service type or the service type tModel does not contain implementation-specific details. This can be seen by the list of tModels specified in section 11.3 (several of these tModels were already introduced in V2). The HTTP GET Transport, SMTP Transport, FTP Transport, Fax Transport and Telephone Transport are used to specify the transport protocol for services that aren't Web services, that is, they are not described in WSDL and are not accessible over SOAP. And the SSL 3.0 Server Authentication and SSL 3.0 Mutual Authentication tModels are used to specify a Web service's authentication mechanism - since the service type tModel usually specifies the use of SSL only but lets the implementation choose the actual authentication mechanism.
I question the introduction of additional transport and protocol tModels that do not fall in one of these categories but rather represent a general Web service type category such as the usage of SOAP. This should be described in the binding tModel.</CvR>

John


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>