| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]
Subject: Re: [uddi-dev] ebXML registry and UDDI comparisons
- From: Paul Denning <email@example.com>
- To: Farrukh Najmi <Farrukh.Najmi@Sun.COM>
- Date: Thu, 23 Jun 2005 17:16:09 -0400
Toward mutual understanding ...
At 01:26 PM 2005-06-23, Farrukh Najmi wrote:
am not convinced that above is either simple or extensible but I will not
belabor that point.
On second thoughts my assertion above may seem to be just subjective
I will attempt to clarify my assertion based on my understanding of the
two standards (which may well be dated or flawed).
-Does UDDI taxonomy support, described above, allow for a registered user
of a UDDI registry to publish
publish a brand new taxonomy complete with its taxonomy values where the
values are hierarchical (not flat)
A qualified yes. Publishing a taxonomy in UDDI terms means creating
a taxonomy tModel (a tModel with a categoryBag that indicates it is a
Taxonomy values are another story.
Implementations of UDDI will typically support a way to define the
taxonomy values, but that part is not standardized.
Taxonomies are flat in UDDI in the sense that the matching is done on a
keyValue, which is just a string.
In ebRIM, classificationNode is a full RegistryObject.
UDDI v3 supports wildcards in keyValues when searching, so it depends on
the value set for the keyValues as to whether you can search exploiting
To use my NAICS example, Soybean Farming was NAICS code 111110. It
is part of a hierarchy:
If my search has keyValue="11%", then it will find entries
categorized as 111110, 11111, 1111, 111, or 11.
If my search has keyValue="111110", then it must match exactly
and will not return entries 11111, 1111, 111, or 11.
Some tools for publishing to UDDI support a feature to "add with
parents". So when I add 111110, it would also add 11111, 1111,
111, and 11; that is, 5 keyedReferences in the categoryBag that is
published. That is a tool specific feature, not something in the
UDDI specs; UDDI specs just tell you that categoryBags contain
keyedReference elements. It doesn't tell you what the
keyedReferences should be.
UDDI does support the notion of a "checked" taxonomy.
Usually the checking is done within the registry, but it also supports an
external validation service.
There is a notion of value-set caching
but this is a flat list of valid keyValues, and you cannot gleen a
hierarchy unless the values are like NAICS (11, 111, ...).
More info about value set caching is in section 5.2.3
-Does it allow the same user
to extend existing taxonomies with additional values?
Not really. For checked taxonomies, the set of values is expected
to be fixed. In my previous email I describe a way to effectively
extend the Soybean Farming category of NAICS, but it is a separate
taxonomy in UDDI terms. If I search under NAICS for
keyValue="11%", it would not find anything that used the
extension taxonomy, which further refines the NAICS category.
UDDI has findQualifiers that alter the search behavior. UDDI
specifies a set of findQualifiers, but allows implementations to define
additional findQualifiers. So, it is conceivable that a
findQualifer could be defined (and the associated implementation logic)
that could refine the query in certain ways. It could effectively
add additional keyedReferences to the requested set, then process the
query with the expanded set. In this example, if the initial
request wanted keyValue="11%", the registry could search for
taxonomy tModels that are categorized with NAICS
keyValue="11%", then add keyed references with those taxonomies
and keyValue="%" (not necessarily "11%" because the
extension taxonomy might not repeat the NAICS part of the code). I
have seen any of this type of enhanced query and custom findQualifiers,
but that is one way to do it and keep within the UDDI extension
-Does it check that a
categoryBag is using a valid taxonomy value from this user defined
This is optional.
If the tModel that defines the taxonomy with UDDI has
keyValue="checked" (send keyedReference above), the registry
must do a check whenever something published to UDDI using that
taxonomy. The check could be internal or done by an external
When done by the registry, the check is usually just whether the keyValue
is a valid value for that taxonomy. It can be more involved, but
UDDI does not specify it. Basically UDDI just wants to know is it
valid or not. An external validation service is given the
whole entity, not just the keyedReference. So the validation
service can factor in other things. Implementations of external
validation services are not too common, but they could play a role is SOA
governance. For example, an entry can be categorized as compliant
with WS-I Basic Profile. An external validation service could
verify that claim against a database of tested or approved
endpoints. A categoryBag can be used to mark a service as
"Production" or "Development". An external
validation service could be used to approve use of
-Can a UI tool use the user
defined taxonomy instantly after publish to guide and enforce the correct
use of taxonomy values
during data entry?
Qualified no. The overviewURL of the taxonomy tModel is supposed to
point to something that further describes the taxonomy. I had
proposed that the target for this URL be a RDDL document, and that the
RDDL document could have links to other things, and rddl:nature and
rddl:purpose attributes could indicate various formats that could be
downloaded to the tool. So, the tool would need to follow the
links, check for a suitable rddl:nature (e.g., perhaps OWL), then
retrieve the corresponding href.
But this goes beyond what is in the UDDI spec.
-Does it allow a UDDI client to
examine taxonomy values for this use defined taxonomy?
Not with minimum UDDI spec, but yes if using the RDDL approach suggested
above. There would need to be consistency between whatever the tool
downloads and whatever the registry uses for checking. For example,
the registry may use a proprietary XML format, but the tool may use
OWL. Both the proprietary XML and the OWL should be consistent at
least in terms of the keyValues allowed. The OWL version downloaded
to the tool may have additional descriptions and relationships that the
tool can use in the GUI, but (in general) all UDDI cares about is the
-Does it allow user defined
taxonomies or taxonomy values to be accessed controlled based on Role and
Not part of the UDDI spec, but can be layered on top in a way that is
consistent with UDDI. Publishers to UDDI do a getAuthToken, which
is opaque to the publisher, but the registry may use it to lookup role or
identity, then limit what taxonomies that publisher can use. The
categoryBag can be used to store access control information in a way that
the registry implementation understands. If you copy or replicate
that entity to a different UDDI implementation, it probably would not
know how to grok the ACL stuff in the categoryBag (breaking access
control). There are a bunch of issues when you start federating
(replicating) entries among registries.
-Can changes made to user
defined taxonomies be versioned?
There is a TN for versioning value-sets (aka taxonomies)
If a new version of a value set is upward compatible with the previous
version, the existing tModel
should be modified to indicate that it represents the new version, and
then be republished using
the same tModelKey.
If a new version of a value set is not upward compatible with the
previous version, a new tModel
should be published to represent the new version of the value set. The
existing tModel should
then be made the predecessor version by adding a keyedReference to
its identifierBag that
refers, using the uddi-org:isReplacedBy identifier system described
in section 11.1.6 in [UDDIV3],
to the tModel of the new version of the value set.
My understanding of UDDI 3.0 is
that the answer to *ALL* of above is that NO it cannot be done in a
manner supported by the standard.
ebXML Registry has supported all of above use cases in a standard,
interoperable, normative manner since version
1.0 several years ago. And it does all of above using the "few good
primitives" principal that we believe is very important
for a good extensible and robust architecture.
ebXML Registry philosophy is "generic and extensible" and
"reusing a few good primitives" over and over to solve diverse
As for simplicity we aim to be as simple as possible but not at teh
expense of limiting our core architecture.
I will illustrate above point with a concrete example.
In UDDI's philosophy of simplicity it avoided a generic architecture. For
example, there are multiple API calls for find and get
(one for each Business, Service, BindingTemplate, Tmodel).
UDDI is simple in its data model; these are the 4 main data
structures. They are generic in many respects. The service
entity applies to anything you might call a service, dial-in telephone,
SOAP, ftp, anything. It is not restricted to only web
In ebXML Registry first there is
no distinction between find and get.
In my opinion, this is moot.
Retrieving HTML is like a find. It includes links to some of the
page content (like images); UDDI returns keys. If you want to see
the jpeg images, you have to get them in a separate HTTP request.
Should we fix the web so that it returns the images along with the HTML
in one request? Even if it did, there would be an option expressed
somehow to say "don't return the images now (I'm on a slow link and
I have images cached locally)".
All the round-trips when browsing the web are under the covers, hidden
from the user (except if there is long latency). UDDI may involve a
number of round-trips, but tools will hide that from the GUI.
Its one and the same thing.
Next, there is only one API to find/get any type of object (even those
user defined types not defined by spec e.g.
If UDDI had lots of objects, it might have had a single get or
find. I am sure your single get/find includes something to tell the
registry what you are trying to find or get.
Another moot point, IMHO.
Further that query API allows
for a powerful ad hoc query capability that can be as simple or complex
as your use case desire
(e.g. Find All CookingRecipes that have ingredients "sugar" and
"salt"). The complexity of the more complex queries is
the end user by storing them as "stored parameterized queries"
within the registry. The client is exposed to a simple API (or GUI) which
them specify parameters. Parameter entry can be guided and validated by
It is harder to support such ad hoc queries and optimize for
performance. I think the UDDI philosphy was to restrict the query
language so they could get to market quicker with implementations, and
Its like jgovernor says
"An awful lot of
functionality that gets shipped is never used. "
All of above may not be
the simplest, but it is definitely very minimalistic, as simple as it can
be using "a few good primitives"
philosophy to deliver
a "generic and extensible" and robust architecture that can
meet many diverse needs as they become known.
It may be elegant, but somehow ebXML seems more complex than UDDI.
Perhaps because they are more abstract and harder to grasp how they
apply. For example, what is a "slot"? Pretty
generic, but what do I use it for?
UDDI started out with a specific
problem as its target: "Publish/discovery of businesses and
May not be infinite, but its pretty diverse and big.
ebXML Registry started out with
the assumption that the problem domain is infinite and that
we MUST design our architecture accordingly.
UDDI chose time-to-market over completeness.
UDDI = VHS
ebregreg = betamax
(Although I don't remember time-to-market for VHS and betamax, they
probably had other influences that made VHS more popular).
This difference in the genesis
of both specs shows over and over in every feature that both specs
provide and in a nutshell if the difference between
the two specs.
| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]