OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-dev message

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

Subject: Re: [uddi-dev] ebXML registry and UDDI comparisons

Paul Denning wrote:
Toward mutual understanding ...
Your first statement above is incomptable with the Beta / VHS analogy inyour last statement.
I have a m,ajor comment at the end which is forward referenced using [1] and [2] in inline comments below....

At 01:26 PM 2005-06-23, Farrukh Najmi wrote:

I 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 opinion.
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 categorization).

Taxonomy values are another story.

A very important story given the many use cases I cited (serving as a domain for guiding user input in GUIs, making sure user input uses valid taxonomy values etc.)

Implementations of UDDI will typically support a way to define the taxonomy values, but that part is not standardized.

If it is not standardized it is not interoperable and therfor not worth mentioning. Anything is possible in custoim software. I could say that implementation of ebXML Registry will typically provide full support for UDDI as an option but that is neither here nor there.

Taxonomies are flat in UDDI in the sense that the matching is done on a keyValue, which is just a string.
A major limitation since most taxonomies in real life are not flat.
In ebRIM, classificationNode is a full RegistryObject.
A major feature by design. This allows a classificationNode (read taxonomy value) to be access controlled, be itself categorized, independently versioned automatically by the registry when changed, related to other taxonomy values using any relationship type (e.g. EquivalentTo) even if the other taxonomy value is in another registry.

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 the hierarchy.
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.
Above only works if a taxonomy has its values encode the hierarchy structure (a rather rare occurance)

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 no API defined by UDDI for a user to add a new checked taxonomy. There is no spec defined for contract (SPI) between UDDI and and external validation service AFAIK. Correct me if I am wrong.

If it is not specified normatively then it is not interoperable and not worth mentioning.

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.
[1], [2]

UDDI has findQualifiers that alter the search behavior. 
[1], [2]
UDDI specifies a set of findQualifiers, but allows implementations to define additional findQualifiers. 
Does it give an API for adding new findQualifiers and their processors? I suspect not. How is this interoperable?
What exactly does UDDI do to "allow implementations to define additional findQualifiers"?  What was preventing
implementations to add impl specific findQulaifier before UDDI "allowed them  to do so?
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 mechanisms.
[1], [2]

If it is not specified normatively then it is not interoperable and not worth mentioning.

-Does it check that a categoryBag is using a valid taxonomy value from this user defined taxonomy?

This is optional.

    <keyedReference tModelKey="uddi:uddi.org:categorization:types" keyName="Categorization system" keyValue="categorization"/>
    <keyedReference tModelKey="uddi:uddi.org:categorization:types" keyName="ignored" keyValue="checked"/>

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 validation service.
How can a taxonomy be checked by registry (or external service) if there is no normative way defined by UDDI to
allow user to specify valid taxonomy values for their user defined taxonomy.

If it is not specified normatively then it is not interoperable and not worth mentioning.

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 "Production".
How can a taxonomy be checked by registry (or external service) if there is no normative way defined by UDDI to
allow user to specify valid taxonomy values for their user defined taxonomy.

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

If it is not specified normatively then it is not interoperable and not worth mentioning.

-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 keyValue.
If it is not specified normatively then it is not interoperable and not worth mentioning.

-Does it allow user defined taxonomies or taxonomy values to be accessed controlled based on Role and Identity?

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.
If it is not specified normatively then it is not interoperable and not worth mentioning.

-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.
I am talking about registry managed version control (like CVS) not user specified version info attached to regsitered

The above TN does not specify how a registry would automatically version a taxonomy value if it is changed.

[1], [2]

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.
The answer to all my questions above for ebXML Registry are a short, simple, unqualified YES.

ebXML Registry philosophy is "generic and extensible" and "reusing a few good primitives" over and over to solve diverse problems.
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. 

Too simple a model.
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 services.

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.
I do not get your point above. ebXML Regisry ad hoc queries can fetch anything using domain specific ad hoc queries with no roundtripping.
How is roundtripping a feature?

[1], [2]

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.
Yes it is called an adhoc query like "SELECT * FROM .... WHERE ... AND ... OR ... NOT ... LIKE.. ORDER BY..." etc.
Another moot point, IMHO.
Not moot at all.

ebXML Registries single API never changes as user defines new types of objects. Imagine if we did things the UDDI way
if user defined an object of type BPEL then we would have to add method:


instead our existing method:


stays as constant as the Northern star.

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 managed/hidden from
the end user by storing them as "stored parameterized queries" within the registry. The client is exposed to a simple API (or GUI) which lets
them specify parameters. Parameter entry can be guided and validated by hierarchical taxonomies.

It is harder to support such ad hoc queries and optimize for performance. 
The freebXML Registry project has done little performance optimizations to date and seems to be performing quite adequately for
some fairly large deployments.
I think the UDDI philosphy was to restrict the query language so they could get to market quicker with implementations, and they did.

Its like jgovernor says " An awful lot of functionality that gets shipped is never used. "
Only if functionality is thrown in without an architecture. Not if you are based on the "few good primitives reused over and over again" principal
as ebXML Registry standard is.

Adhoc queries in ebXML Registry are the most frequently used feaure. This is based on data from experience of the 200+ user community of'
freebXML Registry project.

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. 
That is where profiles of ebXML Registry are making a huge difference. See for example, Open GIS (Geo spatial), IHE XDR (Healthcare - Electronic Patient Records)
For example, what is a "slot"?  Pretty generic, but what do I use it for?
Indeed very generic. It represents a user define attribute that meets the common need to add any type of attribute data on any object (can UDDI do that?).
The name and the concept BTW comes from the SELF Programming language. We built ebXML Registry standard based on a deep study of a welath of past
experience and standards.

BTW, what is a tModel? It sounds like the product Henry Ford used to say what "available in black or available in black" ;-)

UDDI started out with a specific problem as its target: "Publish/discovery of businesses and services"

May not be infinite, but its pretty diverse and big.
Then why did the UBR fail so miserably?

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.
ebXML Registry chose to be community driven and designed to solve real problems rather then be driven by some large behemoths in pursuit of
their own private agendas.

ebregreg = betamax
It is above statement that set my tone for this email.

How can you say ebregreg = betamax when I have cited
deployements by US Dept. of Defense, United Nations, Entire verticals?

BTW did you know that IBM is now building a helathcare product based upon ebXML Registry (nay freebXML Registry)?
This is after they quit ebXML Registry inprotest, 3 years ago, because we chose to support WS registry use case in version 2.


Do you know why? Because their hand was forced by IHE XDR defining a normative profile of ebXML Registry.

Do you really believe in your heart that the betamax analogy applies. I speculate not. I think this was uncalled for at best and pure FUD at worst.

While we are on teh sibject of analogies let me close with one. But before I do let me now resolve the forward reference:

[1] UDDI does too little

[2] UDDI does that too little with too much complexity

Apparently some well respected people agree with my assertions above:


You will also find in the blog thread above that the UDDI TC Chair Luc Clemente did his best to create FUD about ebXML Registry even though it was not even
the topic.

So here  is my analogy :

There is a common problem faced by many users: How to turn on a light switch

UDDI  = A Rube Goldberg machine ( http://www.rube-goldberg.com/html/contest.htm )
ebXML Registry = A solid state transitor   ( http://www.pbs.org/transistor/ )


Farrukh Najmi

Editor: ebXML Registry TC
Co-chair: Semantic Content Management SC of OASIS ebXML Registry TC
Co-chair: Registry SC of OASIS egov TC
Lead Architect: freebXML Registry open source project 		
	(http://ebxmlrr.sourceforge.net )
Spec Lead: JAXR API
Federated Information Management Architect: Sun Microsystems

Coming to Java ONE 2005? If so check out Sun's Service Registry at Booth #802 in the Java ONE Pavillion.

Sun's Service Registry Web Site:

Press Release:
fn:Farrukh Najmi

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