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

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

Why should users care for the complexity of a query? If at all, this would be a concern from the UDDI node operator's point of view.
As a (potential) Web service consumer, I'd really care for consistency of the published data - so that I found all entities that really fit to my requirements. If the WSDL TN requires bindingTemplates to be adorned with the same information that the binding tModels are adorned with, then consistency
is even harder to guarantee. The Web service provider may simply forget to adorn the registered Web services (aka bindingTemplates) with the protocol information that is specified by the referenced binding tModel (e.g. that it uses SOAP) - and the Web services will not be found with the proposed
query.

Claus

-----Original Message-----
From: Anne Thomas Manes [mailto:anne@manes.net]
Sent: Donnerstag, 21. November 2002 14:12
To: Von Riegen, Claus; 'John Colgrave'; uddi-spec
Subject: RE: [uddi-spec] WSDL TN: Issue 4 - tagging of bindingTemplate
wit h protocol/transport


I view the efficiency (and simplicity) in discovery as very important --
particularly in V2. This TN describes a mapping for V2, and I suspect that
users will continue to use V2 for a while. By tagging the bindingTemplates,
V2 users can find all SOAP/HTTP bindings for a particular portType in one
simple query rather than two complex queries. Even in V3, this query
approach is much simpler than the complex embedded query. I view this
capability as a high priority requirement.

Anne

> -----Original Message-----
> From: Von Riegen, Claus [mailto:claus.von.riegen@sap.com]
> Sent: Thursday, November 21, 2002 2:43 AM
> To: 'John Colgrave'; uddi-spec
> Subject: RE: [uddi-spec] WSDL TN: Issue 4 - tagging of bindingTemplate
> wit h protocol/transport
>
>
> 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>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>