Re: [uddi-spec] Last call on Discussion for WSDL Best Practice v1.08

[John Colgrave <colgrave@hursley.ibm.com>]

Jan,

I assume your question concerns only the V2 TN and that you are not
suggesting a change to the V1 BP.

For the V2 TN, there is the issue of compatibility with the V1 BP, as you
mention, and that alone would be sufficient reason to keep a tModel for a
binding.

Leaving that aside, I think there are other good reasons to have a tModel
for a binding.

One is that a binding is (could be) a discrete reusable concept and is
therefore a good candidate for a tModel.

A second is that there may be more to a particular binding than just the
protocol and transport, so you may want to find implementations of a
specific named binding, rather than, for example, just any old SOAP/HTTP
binding, and there is no way, in UDDI V1/V2 at least, to find
implementations of a particular binding other than to have a tModel for that
binding.  In the V1/V2 API, find_binding only takes a tModelBag so if you
don't have a tModel for a particular binding you cannot find
bindingTemplates that have that particular binding in their technical
fingerprint.  You will have to give me an example of how you can allow the
4th type of query by adding keyedReferences.

A third is that it provides a convenient place to hold a reference to the
WSDL file containing the binding in case that is required.  This belongs
with the tModel that represents the binding rather than being duplicated in
every bindingTemplate that references the binding.

I think it is entirely reasonable that the three-tier WSDL model of
portType/binding/port is reflected in a three-tier UDDI model of
(portType)tModel/(binding)tModel/bindingTemplate.

John Colgrave
----- Original Message -----
From: "Jan Pridal" <pridal@systinet.com>
To: <uddi-spec@lists.oasis-open.org>
Sent: Wednesday, October 30, 2002 5:50 PM
Subject: Re: [uddi-spec] Last call on Discussion for WSDL Best Practice
v1.08


> Hi,
>
> I have a question concerning the modeling of  wsdl:binding as tModel.
> What is the ratio behind this approach? I understand that the binding
> information
> should be separated from the interface description (that's exactly what we
> have
> already proposed in our alternate best practice more than a year ago).
>
> I found some explanation in the new WSDL Technical Note (lines 246-250)
> which goes as follows:
>
> 'The rationale for this new mapping decision is allows for the modularity
of
> WSDL
> to be expressed through UDDI. By decomposing WSDL into multiple tModels,
> one can accurately model in UDDI exactly which portTypes and bindings
> a given Web service supports,as opposed to being constrained to asserting
> that a Web service always supports the entirely of the WSDL file,
> which may not be the case.'
>
> There are five types of queries defined in Goals and Requirements section
> (lines 144-153):
>
> 1) Given the namespace and/or local name of a wsdl:portType, find the
>     tModel that represents that portType.
> 2) Given a tModel representing a portType, find all tModels representing
>     bindings for that portType.
> 3) Given a tModel representing a portType, find all bindingTemplates that
>     represent implementations of that portType.
> 4) Given a tModel representing a binding, find all bindingTemplates that
>     represent implementations of that binding.
> 5) Find all bindingTemplates that represent implementations of an extended
>     binding, for example all SOAP/HTTP implementations, of a portType.
>
> Using Systinet's approach (wsdl:portType modeled by tModel, wsdl:binding
and
> wsdl:port
> modeled by the bindingTemplate) the queries 2, 3, 4 shrink actually to one
> query: 3
> without any loss of flexibility or modularity (we still can supply
> additional info
> on the wsdl:binding by adding keyedReferences containing the qualified
name
> of wsdl:binding to allow the 4th type of queries).
>
> Notice that there's no need in our approach to include a redundant
> tModelInstanceInfo
> referencing  the wsdl:portType tModel into the bindingTemplate to enable
> the 3rd type of queries [p. 10 footnote 4] and we do not double the number
> of tModels.
>
> While each wsdl:port always references (by its binding attribute) only one
> wsdl:binding
> there shouldn't arise any problems (complexity etc.) when modeling both in
> the bindingTemplate
> instead of declaring an additional tModel for wsdl:binding.
>
> Moreover the wsdl:binding contains the information on used protocol (SOAP,
> RPC etc.)
> and there's no place where to put it in tModel structure (modeling
> wsdl:binding)
> whereas the bindingTemplate's tModelInstanceInfos represent exactly the
> place
> where this kind of information belongs (and WSDL Technical Note creates
> in accordance with that the tModelInstanceInfo of TModel representing
> SOAP binding extensibility element for example).
>
> So, is there any reason why to create a tModel per wsdl:binding
> save the backward compatibility with the previous version of WSDL Best
> Practice
> (where the tModel represented the WSDL document up to wsdl:binding
> which is not true any more having only the tModel per wsdl:portType)?
>
> Many thanks,
>
> Jan Pridal
> Senior Engineer, Systinet (formerly Idoox)
> http://www.systinet.com
>
>
> ----- Original Message -----
> From: "Tom Bellwood" <bellwood@us.ibm.com>
> To: <uddi-spec@lists.oasis-open.org>
> Sent: Wednesday, October 30, 2002 12:57 AM
> Subject: [uddi-spec] Last call on Discussion for WSDL Best Practice v1.08
>
>
> >
> >
> >
> >
> >
> > Hi folks,
> >
> > During our last telecon, we agreed to see if any further discussion was
> > needed on the proposed WSDL Best Practice v1.08 which John Colgrave had
> > posted.  I've seen some explanatory discussion on it, but nothing of
late,
> > leading me to make a "last call" on any discussion we need to have
before
> > calling this item for vote.   Unless we hear requests to the contrary,
an
> > email vote will begin on Thursday 11/1.  Instructions for casting your
> vote
> > will be posted at that time.
> >
> >
> > Thanks,
> > Tom Bellwood
> > Co-Chair, OASIS UDDI Specification TC
> >
> >
> > ----------------------------------------------------------------
> > 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>