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