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

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

John,

Here are some more comments.

Claus

-----Original Message-----
From: John Colgrave [mailto:colgrave@hursley.ibm.com]
Sent: Freitag, 22. November 2002 10:47
To: uddi-spec
Subject: Re: [uddi-spec] WSDL TN: Issue 4 - tagging of bindingTemplate
with protocol/transport


Claus,

See below.

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

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

<CvR>I REALLY fear information mismatch if you multiply the binding tModel categories in all referencing bindingTemplates. What happens if the Web service type developer slightly changes the binding tModel? ALL Web service providers who have implemented the Web service type have to check their registration whether they are still consistent with the binding tModel - assuming they get notified at all.</CvR>
 
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
bindingTemplate.

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!
</JC>

<CvR>Rather than waiting for V4, we should check whether the UDDI Types category system can appropriately be used for these scenarios and whether additional category systems have to be specified by the WSDL TN in order to categorize binding tModels in terms of their supported protocol/transport. These would replace the SOAP and HTTP tModels that are currently proposed by the WSDL TN in order to type bindingTemplates.</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>

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

<CvR>If there are compelling use cases that require more complexity than the existing andAllKeys/orAllKeys find qualifiers, we should revisit the UDDI Inquiry API in general - rather than multiplying the registry data.</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>

<JC>
I will add it.
</JC>

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

<JC>
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.
</JC>

<CvR>I don't understand. If I want to specify 4 protocols in terms of protocol tModels, I publish 4 protocol tModels. If I want to specify 4 protocol tModels in terms of category systems, I publish 1 category system tModel that provides 4 categories. A user has either to know the 4 protocol tModel keys or the 4 protocol values of the category system tModel.
Why is the second alternative "a lot more work"?</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>

<JC>
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.
</JC>

<CvR>You are right in terms of UDDI's information model. But I disagree in terms of the meaning of the UDDI specification. Generally tagging bindingTemplates (that represent Web services) with protocol/transport tModels was never intended by the authors. I'd be willing to write a change request if that helps clarifying matters.</CvR>

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