OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-pfb message

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


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


The importance of 4 is under debate. It is a question of how efficient searching needs to be (directly supported by a UDDI query without result filtering). And not all a producer's portlets need be published into a particular registry.
 
I would also say that the primary use cases (that we need to support,  rather than those for users of WSRP) are for searching for portlets/producers in a business, followed by 1 and 3.
 
We also do not have a 5. "locate all Portlets supporting a particular WSRP version". That with 2 and 4 would be another secondary use case for me and, like 4, may require some result filtering.
 
The (non searching) use case I'm concerned about are:
 
A. Using a register under someone else's control => not requiring UDDI Admins (help or permission) when adding tModels/Categories.
B. Manual publish / find / bind => being able to publish and look up portlets using common UDDI UIs (Web HTML and other tools).
 
regards,
Andre
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 22 January 2004 17:57
To: wsrp-pfb@lists.oasis-open.org
Subject: RE: [wsrp-pfb] [UDDI #4] WSRP_v1_Bindings tModel equals WSRP_Produc ertModel?


This discussion has gotten very deep into the details of how something could be modelled in UDDI. It would help me to have a reminder of the use cases viewed as required. My understanding is that we would want all registries to include:
  1. Ability to locate all WSRP Producers, regardless of WSRP version(s) supported.
  2. Ability to locate all WSRP Producers supporting a particular WSRP version.
  3. Ability to locate all WSRP Portlets, regardless of WSRP version(s) supported.
  4. Ability to locate all WSRP Portlets hosted at a particular WSRP Producer.

Am I understanding the minimal requirements intended for the abstract information model?


Rich


Andre Kramer <andre.kramer@eu.citrix.com>

01/22/2004 12:41 PM

To
wsrp-pfb@lists.oasis-open.org
cc
Subject
RE: [wsrp-pfb] [UDDI #4] WSRP_v1_Bindings tModel equals WSRP_Produc         ertModel?





For "find producer's portlets" we can fall back to our service description factor.

Why do the registries say things such as "if appropriate categorization is not available, contact a UDDI Services Coordinator"? It made me suspicious that categories imply some sort of in-built sorting / indexing that we may need to watch out for. Otherwise, it seems to be an argument of some simplicity (just another instanceDetail/tModel tag) versus more clarity of being either a WSRP Portlet or Producer (a binary categorization).

Note that, if we allow other types of producer reference (still being debated) then I can image that a single service could be both a portlet and (via self - reference) be its own producer service too (needs two binding templates).

regards,
Andre

-----Original Message-----
From: Richard Jacob [
mailto:richard.jacob@de.ibm.com]
Sent: 22 January 2004 17:24

To: Andre Kramer

Cc: wsrp-pfb@lists.oasis-open.org

Subject: RE: [wsrp-pfb] [UDDI #4] WSRP_v1_Bindings tModel equals

WSRP_Produc ertModel?




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



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