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

[Jan Pridal <pridal@systinet.com>]

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>