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] | [List Home]


Subject: RE: [uddi-spec] WSDL TN Review: feedback on the current TN


Sam,

Thank you, as always, for your comments.  I have not distinguished between
Content and Editorial in my responses.

UDDI V3 Optional Extensions

We decided they should be optional because we felt it was more important to
have a single mapping that could be used via either the UDDI V2 API or the
UDDI V3 API.  What people can rely on is that the same queries will be
available via either V2 or V3.  To address both requirements would require
the port name to appear twice, and we have tried to avoid duplicate
information wherever possible.  We rejected having just the categoryBag way
of storing the name as this would be invisible to applications using the V2
API.  This area is certainly something we can consider again in the light of
implementation experience.

Mapping of Local Names

This was discussed several times.  A name is a name and the obvious mapping
is to map the WSDL entity name to the corresponding UDDI entity name.  The
only places where this is not done is where either the UDDI entity concerned
does not have a name or it may already exist with a name that we do not want
to change.  The current mapping represents the best we thought we could do
given the constraints of the UDDI V2 structures.  I don't think the name is
a suitable categorization but if we did use the categoryBag wherever we
could we would still have to come up with a name for the various tModels,
and it is not clear that there is any better name than the name of the
corresponding WSDL entity, in which case we simply have a more complex
mapping with duplicated information, which again we wanted to avoid.

V2 find_binding Examples

This is a good catch.  I had already spotted it and made the necessary
changes, which were more than editorial as they affect the queries that you
have to do.

V3 Examples

I think that in light of the previous point, it is worth considering this.
I am not sure if we can make much use of embedded queries but I will look at
the V3 version of each of the sample V2 queries that we have and if there is
a significant benefit in doing the V3 query differently then I will add a
"Sample V3 Queries" section with those example queries where it makes sense.

John Colgrave
IBM


-----Original Message-----
From: Wai-Kwong Sam LEE [mailto:Sam.Lee@oracle.com] 
Sent: 08 April 2003 01:57
To: John Colgrave
Cc: uddi-spec@lists.oasis-open.org
Subject: Re: [uddi-spec] WSDL TN Review: feedback on the current TN

John and others,

Thanks for great work of the well-polished TN! I've got a few comments:

Content
--------
- UDDIv3 optional extensions (Section 2.5.2): should they remain 
optional? Leaving them optional makes the users (of a v3 registry) hard 
to decide whether to rely on them or not. For example, if a user wants 
to find binding with a particular port name, he does not know whether he 
  can rely on doing a find_binding by categoryBag or not.


- Mapping of various wsdl: local names: I believe it had been discussed 
for a while in the past and I do not intend to reopen a rat hole. 
Anyhow, in brief, in the current mapping:
wsdl:portType - tModel name
wsdl:binding - tModel name
wsdl:port - bindingTemplate instanceParms; optionally bindingTemplate 
categoryBag (in UDDIv3)
wsdl:service - businessService categoryBag; optionally businessService name

It seems that we can also choose to more uniformly (i.e., easier to 
understand) map all wsdl: local names to categoryBag (with the exception 
of wsdl:port in UDDIv2 case).  The similar constructs (wsdl namespace) 
are also uniformly mapped to categoryBag.
I believe there must be some reason that the sub-committee chose not to 
do so. It'd be great if someone could explain the motivation of the 
current mapping.



Editorial
----------

- In find_binding examples (section 3.3.3 and 3.3.4), there is no 
serviceKey attribute. However, in UDDIv2 serviceKey attribute is required.

- It'd be great if some examples can be given demonstrate the capability 
added in the UDDIv3 mapping. For example, an example "Find bindings for 
port name" can be given to demonstrate the use of categoryBag in 
bindingTemplate.
Furthermore, some examples can also take advantage of basic UDDIv3 
enhancements. For example, section 3.3.3 can demonstrate the use of 
find_binding without serviceKey; section 3.3.5 can demonstrate embedded 
queries.


- sam



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