RE: [wsrp-pfb] [UDDI #4] WSRP_v1_Bindings tModel equals WSRP_Produc ertModel?

["Richard Jacob" <richard.jacob@de.ibm.com>]

Andre Kramer <andre.kramer@eu.citrix.com> wrote on 01/22/2004 04:28:39 PM:

> see <ak> below
> I don't see any additional effort wheter you fill out things here or
there.
> <ak> Broadly similar amount of effort to publish a binding, I agree.
> I was saying that we can just tag with two tModels instead of just
> one keeping binding related information together. </ak>

Understood and agree - similar effort. It's a question of concept, like I
noted reflecting the discussion with Klaus.

> <ak> More of a question of how easy it is to add categories to UDDI.
> What does one need do or to be allowed to add a new type of category
> to a registry? I understand save_tModel but can anyone just define
> new categorizations? </ak>

Yes, it's just a tModel marked as a categorization tModel.
See our Producer Service Reference tModel, it's a categorization, too.
That's why the tModel refers to the 2 tModels in its definition.
First one is "categorization", second one is "unchecked".

> <ak>Imagine we added a "resource" Web Service. How do we type that?
> A new tModel or "WSRP" category extension? I was only trying to say
> that the fact we have both portlet and producer services is just how
> we chose to model the problem space - we could have gone for other
> schemes. So how valid are producers or portlets as real world categories?
> </ak>

Right, it would mean either a new tModel if we used our current scheme
(tModel on binding).
Or it would be just another allowed value as the keyValue in the
keyedReference (categorization).
We could do even more things like checking the valid values, i.e. make the
categorization checked.
But this may go to far for the first shot :-)

> <ak> So why worry too much about tModel or category if the tools
> take the load?</ak>

It's just a modelling and concept issue. I don't worry about the technical
details.

> <ak> I would also seek approval but want a minimal simple solution
> (for me that is tModels based bindings only). Maybe it is not the
> most conformant way to represent things like "Producer/Portlet" or
> "Producer Refernce" but I don't see a great difference. </ak>

Agree, and I think we are trying this.
However we should keep our use cases in mind.
I think we must conform and should not contradict concepts already in
place.
I see that the tech notes and best practices are not at a standard level
but at least they contain the UDDI expertise and we should make use of it.

> <ak> Just to add that I think all the schemes work to a very large
> extend. I'm just expressing a preference. </ak>

And that's fine and good and I appreciate it. I also agree that from a pure
technical point of view they work.
Except the one model where we loose one use case ("find Producer's
Portlets").
And I guess that there are even more possibilities we haven't yet even
thinked of :-)
At least we should put them on the table and discuss the pros and cons.

cheers
Richard