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


Toward mutual understanding ...

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.

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 the hierarchy.
To use my NAICS example, Soybean Farming was NAICS code 111110.  It is part of a hierarchy:
11
111
1111
11111
111110

http://www.census.gov/epcd/naics02/naicod02.htm

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
http://www.uddi.org/schema/uddi_v3valuesetcaching.xsd

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
http://uddi.org/pubs/uddi-v3.0.2-20041019.htm


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


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

This is optional.

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

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.

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



-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.
http://www.google.com/search?q=pauld+uddi+rddl

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


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


-Can changes made to user defined taxonomies be versioned?

There is a TN for versioning value-sets (aka taxonomies)
http://www.oasis-open.org/committees/uddi-spec/doc/tns.htm#vervalset
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 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.  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.

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.
"CookingRecipe").

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


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

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.


Paul



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