OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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


See below.

----- Original Message -----
From: "Von Riegen, Claus" <claus.von.riegen@sap.com>
To: "'John Colgrave'" <colgrave@hursley.ibm.com>; "uddi-spec"
Sent: Thursday, November 21, 2002 7:42 AM
Subject: RE: [uddi-spec] WSDL TN: Issue 4 - tagging of bindingTemplate with

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

Efficiency, both in terms of how much code has to be written to perform a
particular query and the run-time cost to execute it, in discovery is very
important to people that write tools that will use the TN.  The run-time
cost is also important to the people that use such tools.

The type of query I am looking for can be done with a single query in V2,
there is an example in section 3.3.5 of the TN.  It is the type of query
that you are looking to replace it with that cannot be performed in one step
in V2.

I am sure the embedded find_tModel is very useful in general, the real issue
here is that there could be multiple binding tModels that are all for
SOAP/HTTP but that differ in other minor ways and if you are not interested
in these minor differences and just want to find all SOAP/HTTP
implementations then it is much better to include SOAP/HTTP directly in the

What I would really like to see is more use of inheritance etc. so that all
of these different binding tModels can inherit from a generic SOAP tModel
and from an HTTP tModel and we could do the query in terms of these
"abstract" SOAP and HTTP tModels and ignore the minor differences that way,
but that is the subject of a different (V4) discussion!

> 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
> apply to find_binding, but the appendix does describe it as applying so
> modified example would work, but it would be much less efficient.  It
> 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
> 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>

The point is you might have more tModelKeys than just binding tModelKeys and
using orAllKeys may not be appropriate for those other keys.

> I would be quite happy to add soapSpec to a SOAP binding tModel but I
> it would ever be used.
> <CvR>This is what the UDDI specification describes and the WSDL TN maybe
should reiterate.</CvR>

I will add it.

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

Perhaps, but that will be a lot more work for a vendor to make a protocol
available, and for people to use it, than just registering a tModel.

> This tagging of the bindingTemplate is allowed for by UDDI, at least the
> spec. (I haven't checked the V2 spec.).  In section 11.3 of the V3 spec.
> 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
> 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
> 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>

I quoted the spec. and referred specifically to the phrase "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."

I think the TN proposes a use of protocol or transport tModels that is
perfectly valid.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC