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 wit hprotocol/transport


Anne,

Please find my response inline.

Claus

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


Comments within <atm> ... </atm>

> -----Original Message-----
> From: Von Riegen, Claus [mailto:claus.von.riegen@sap.com]
> Sent: Thursday, November 21, 2002 10:06 AM
> To: 'Anne Thomas Manes'; 'John Colgrave'; uddi-spec
> Subject: RE: [uddi-spec] WSDL TN: Issue 4 - tagging of bindingTemplate
> wit h protocol/transport
>
>
> 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.

<atm>
The user has to write the query.
</atm>

<CvR>Actually, I meant the potential performance issues. I assume that most queries of this type are only parameterized by the user and the actual SOAP request is rendered and sent to the UDDI node by a tool.</CvR>

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

<atm>
The Technical Note says that you MUST adorn the bindingTemplates with
protocol info, and TN-compliant tools would do so automatically. If the Web
service provider "forgets" to do so, he isn't conforming to the TN.

If we don't put the protocol information on the bindingTemplate, then we
ought to put it somewhere else. At the moment we don't adorn the binding
tModel with protocol info. In order to determine that a binding uses SOAP
over HTTP, you need to retrieve the WSDL file and examine it. So if we don't
put this information in the bindingTemplate, how would a user discover all
bindings of a portType that use SOAP over HTTP?

As an alternative to adorning the bindingTemplate, we could adorn the
binding tModel using a couple of keyedReferences: XML Protocol and Transport
Protocol, and specify "soap" and "http" in the keyValues. (or rather than
creating a new XML Protocol tModel, we could mandate that the tModel be
defined as UDDI type soapSpec).
</atm>

<CvR>This is exactly what I am looking for - to categorize the entities who actually belong to a category (a binding tModel may belong to the set of SOAP bindings) and not those who inherit it (a bindingTemplate represents a Web service that is accessible over SOAP since the referenced binding
tModel says so, not because of its own categories.</CvR>

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


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


Powered by eList eXpress LLC