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

["Luc Clement" <lclement@windows.microsoft.com>]

Title:

Claus,

I just posted comments on my reservation with providing a "seal of approval". On reflecting on this a tad more, the act of posting the information on the uddi.org site is indeed a "seal of approval"; thus my reservations aren't entirely valid. I remain concerned about establishing a relationship/seal of approval between uddi.org and a publisher. Futhermore, we need to consider resource constraints and reduce to a minimum human intervention requirements, otherwise this will doom the proposal on the basis that it may not be implemetable in practice.

Regardless, let's work on this idea and see where it takes us - inline.

Luc

-----Original Message-----
From: Von Riegen, Claus [mailto:claus.von.riegen@sap.com]
Sent: Thursday, May 15, 2003 02:17
To: 'Tom Bellwood'; 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

I like the idea with a businessEntity that represents the UDDI TC.

[LC] I think that the member section should be represented and not the 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.

[LC] This approach has merit but introduces 1) business "relationship" issues between uddi.org and the publisher - this concerns me, and 2) needs more coordination and complicates the query patterm (one that we could implement to easily implement a dynamically generated page for instance). I think that Tom's suggestion would be prefererable:

"A businessEntity can be created which is owned by our TC (LC - the member section) 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."

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.

[LC] We need to set the bar fairly high on the matter of v3 key derivation given that you need to involve an operator in registering the tModel given the need to "set" a special-sauce v2 key. An operator would have to agree.

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