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] Last call on Discussion for WSDL Best Practice v1.08


John,

your assumption is right, I don't suggest any changes to the V1 BP.

To the second point:
the v1.08 of WSDL Best Practice also defines the mapping
between the WSDL and UDDI V3, where the bindingTemplate
structure is extended by having a categoryBag.
The find_binding takes the categoryBag as argument then.
And you can add the keyedReference to this categoryBag that
will  constitute the (qualified) reference to the particular
wsdl:binding. You are of course right this kind of search is not
possible in V1 & V2 of UDDI and here we have again
the backward compatibility issue.

To the third point:
You say that the tModel per binding policy avoids the duplication
of reference to the WSDL file in every bindingTemplate which
references given wsdl:binding. That's true. But what you do not
avoid is the ever growing number of tModels, which seems to me
a larger issue (not only considering their deletion policy).
The number of tModels representing wsdl:bindings will grow
linearly with the number of different bindings of given
portType. The more different bindings of one portType
the more tModels representing them instead of one simple
tModelInstanceInfo per bindingTemplate. (And even using
your practice you still have to create that tModelInstanceInfo in
the bindingTemplate to reference the binding tModel.)
So there's no real benefit in this case except the inverse situation
(where there are many different ports using one binding) is more
frequent, which I don't think so. (I doubt that your premise
about a binding  as a discrete reusable concept does hold.)

[I understand that it's necessary to create tModels for
TYPES of bindings (as SOAP/HTTP).]

I would greatly appreciate to map the 3-tier WSDL model
to the 3-tier UDDI model, but I don't see the perfect match.

On the other hand I can understand there's no other way of
doing things when the backward compatibility must be maintained.

Thank you for your prompt answer,

Jan Pridal
Senior Engineer, Systinet (formerly Idoox)
http://www.systinet.com



----- Original Message -----
From: "John Colgrave" <colgrave@hursley.ibm.com>
To: <uddi-spec@lists.oasis-open.org>
Sent: Thursday, October 31, 2002 11:23 AM
Subject: Re: [uddi-spec] Last call on Discussion for WSDL Best Practice
v1.08


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