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


We are all collectively going through a learning experience about both 
UDDI and ebXML Registry standard and this thread
has been very valuable in exploring their design centers and use cases. 
More inline below...

Farrukh Najmi wrote:

> Paul Denning wrote:
>
>> At 10:54 AM 2005-06-22, Farrukh Najmi wrote:
>>
>>> As far as I know, adding new taxonomies (complete with taxonomy 
>>> values) is quite vendor specific in UDDI 3. Also there is no 
>>> standard way to extend values for standard/checked taxonomies for 
>>> domain specific profiles.
>>
>>
>>
>> Adding a taxonomy (without its taxons or value-set) is very common in 
>> UDDI.  Simply create a tModel and put the following in its categoryBag
>
>
> ebXML Registry supports both taxonomies that have values defined and 
> checked and those that do not.
>
> My exprience in working with many registry deployments is that in most 
> cases one wants taxonomy values to be defined.
> These values serve as domain for controlling data entry in UIs (e.g. A 
> Gender taxonomy with values Male, Female and Other).
> These values also enable the user of the UI to not have to know the 
> allowed values.
>
> Taxonomies without values make sense typically as a namespace where 
> the choices are unlimited (e.g. National ID #).
>
>>
>> <categoryBag>
>>     <keyedReference tModelKey="uddi:uddi.org:categorization:types" 
>> keyName="Categorization system" keyValue="categorization"/>
>> </categoryBag>
>>
>> Having this in the categoryBag makes the a "taxonomy tModel".
>>
>> (This is UDDI v3, but there is also a v2 tModelKey.)
>>
>> As far as extending the values, this would be something that would be 
>> done as a technical note or best practice, similar to the profiles 
>> for ebXML Registry.
>
>
> User defined taxonomies complete with valuesets is a standard part of 
> ebXML Registry and has been seen version 1.0. No tech note is needed 
> for that.
>
>>
>> Although it is often stated that taxonomies lack semantics, it only 
>> lacks them in terms of a syntax for expressing the semantics.  
>> Certainly there is a meaning for each taxon of a taxonomy.  For 
>> example, NAICS code 111110 is understood to mean Soybean Farming.
>
>
> ebXML Registry taxonomies support OO inheritence semantic.
> For example, you MAY have a geography taxonomy with hierarchical 
> values like:
>
> Asia
>    Japan
>       Tokyo
>    Korea
>
> If an object is classified (catgeorized in UDDI speak) by Japan or 
> Tokyo geography it will be matched
> by a search for objects classified by Asia Geography.
>
>>
>> Maybe you want to extend the Soybean Farming branch of NAICS with 
>> your own taxonomy; perhaps there are different types of soybeans (go 
>> with me here ;-)
>> Perhaps "American Soybean Farming" and "Asian Soybean Farming".
>>
>> You could create a tModel for this new taxonomy.  Its categoryBag 
>> would look like this
>>
>> <categoryBag>
>>     <keyedReference tModelKey="uddi:uddi.org:categorization:types" 
>> keyName="Categorization system" keyValue="categorization"/>
>>     <keyedReference tModeKey="uddi:uddi.org:ubr:taxonomy:naics" 
>> keyName="Soybean Farming" keyValue="111110"/>
>> </categoryBag>
>>
>> If you have a business that you want to categorize as "American 
>> Soybean Farming", you would use the new taxonomy in its categoryBag.  
>> You could also use the NAICS 111110 in it categoryBag.  There is an 
>> implied "is a" relationship between the business and its 
>> categoryBag.  This business is an American Soybean Farming business.  
>> It is also a Soybean Farming business.
>>
>> This would be one way to extend NAICS in UDDI.  There may be other ways.
>>
>> The people using the taxonomies would understand the semantics, even 
>> though all that is put in UDDI is a keyValue.
>>
>> The philosphy was to keep UDDI simple and extensible.  Similar to the 
>> philosphy around SOAP: keep it simple and provide well understood 
>> mechanisms for extending it (e.g., SOAP headers).
>
>
> 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)

-Does it allow the same user to extend existing taxonomies with 
additional values?

-Does it check that a categoryBag is using a valid taxonomy value from 
this 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?

-Does it allow a UDDI client to examine taxonomy values for this use 
defined taxonomy?

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

-Can changes made to user defined taxonomies be versioned?

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). In ebXML 
Registry first there is no distinction between find and get.
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").

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.

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.

UDDI started out with a specific problem as its target: 
"Publish/discovery of businesses and services"
ebXML Registry started out with the assumption that the problem domain 
is infinite and that
we MUST design our architecture accordingly.

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.

-- 
Regards,
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 checkout Sun's Service Registry at Booth 
#802 in the Java ONE Pavillion.

begin:vcard
fn:Farrukh Najmi
n:Najmi;Farrukh
email;internet:farrukh.najmi@sun.com
tel;work:781-442-9017
url:http://ebxmlrr.sourceforge.net/tmp/DSCN0278.JPG
version:2.1
end:vcard



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