RE: [uddi-spec] Use of UDDI.org as a means of promoting TC, UBR, Std Group and Consortium tModels and Value Sets

["Von Riegen, Claus" <claus.von.riegen@sap.com>]

I like the idea with a businessEntity that represents the UDDI TC. However, I would still try to use the V2 relationship feature, especially because tModelInstanceInfos usually do not reference value sets.

A possible solution would be to create a new relationship type tModel, probably named "common tModel relationship". The valid values of this tModel are existing tModelKeys.
The process for announcing "common" tModels would then be as follows:

1) A tModel T1 is published by a publisher P who also owns a businessEntity B1
2) P publishes a publisherAssertion that consists of
- the businessKey of the UDDI TC businessEntity
- the businessKey of B1
- the tModelKey of the "common tModel relationship"
- a keyValue that equals to the tModelKey of T1
- a keyName of P's choice, usually the name of T1

Now, the existing "requests" can be tracked by the publisher of the UDDI TC businessEntity by using a get_assertionStatusReport API call. If the TC decides to accept an existing request, the following step is executed:

3) The publisher of the UDDI TC businessEntity publishes the very same publisherAssertion under his/her account.

As a consequence, the relationship becomes "visible" and "means" that T1 is a "common" tModel.

What we still need is a process for requesting the actual publication of tModels whose keys are to be based on a V3 key derivation - simply because V2 does not allow to pre-assign keys in save_xx API calls. Thus, I believe that we also still need the page that Luc originally prototyped.

Claus

-----Original Message-----
From: Tom Bellwood [mailto:bellwood@us.ibm.com] 
Sent: Donnerstag, 15. Mai 2003 04:46
To: Anne Thomas Manes
Cc: uddi-spec@lists.oasis-open.org
Subject: RE: [uddi-spec] Use of UDDI.org as a means of promoting TC, UBR, Std Group and Consortium tModels and Value Sets







Hi Anne,

Good point of course.  I guess 30 sec. of thought at the airport wasn't
adequate.  :)   In any event, there is a simple alternative for us that
should do the trick.   A  businessEntity can be created which is owned by
our TC which we can use to model this and other things.   We could then
create a businessService entry with a binding that contains
tModelInstanceInfos with references to all of the TC "approved" common
tModels.  The instanceDetails' overviewDoc could have a reference to our
OASIS page explaining that the referenced tModels were approved, etc.
Alternative modeling techniques could also be used.  The point is that this
business would be recognized as the UDDI TC's official BE because we would
also document it on the OASIS site, including its businessKey.

Thanks,
Tom Bellwood

"Anne Thomas Manes" <anne@manes.net> on 05/14/2003 03:13:27 PM

To:    Tom Bellwood/Austin/IBM@IBMUS
cc:    <uddi-spec@lists.oasis-open.org>
Subject:    RE: [uddi-spec] Use of UDDI.org as a means of promoting TC,
       UBR, Std Group and Consortium tModels and Value Sets



Tom,

I agree that it would be much more convenient to use UBR, but how can you
"certify" an individual tModel? Business assertions exist between business
entities, not between a business entity and a tModel. (Unless I'm missing
something...)

Anne