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

[Anne Thomas Manes <anne@manes.net>]

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>
>