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?
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp-pfb@lists.oasis-open.org
- Date: Fri, 23 Jan 2004 10:30:37 -0500
If I understand your argument, you would
place highest priority on use cases that directly answer user (usually
a page designer in this case) questions. These boil down to the generic
"What portlets are available" and "What portlets can I use"
questions. We both seem to agree that the first of these questions drives
the need for #3. I am arguing that the second question has a business undertone
that drives the need for #4 while you are arguing that it has a technical
undertone that drives the need for #5. My comments about the technical
undertone will come after the following comments about the tooling arguments.
You also argue that tool-oriented needs
(i.e. understanding things about Producers) are secondary as they relate
to artifacts of the design of the WSRP protocol. I would agree with that
argument, but would also place them on the required list as fundamental
needs of those tools. For me that leaves one question to grapple with for
these, "Should #1 merely be the tools doing an OR on #2 for those
versions they understand"
I would note that a corollary to the
tooling question of collapsing out #1 is whether #5 is really just a tooling
issue of combining #2 and #4.
The following are repeated merely to
remind people what the use case numbers refer to:
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.
5. Ability
to locate all WSRP Portlets supporting a particular WSRP version.
Rich Thompson
OASIS WSRP TC Chair
Interaction Middleware and Standards for Portal Server
IBM T.J. Watson Research Center / Yorktown Heights, NY
Phone: (914) 945-3225 / (203) 445-0384 email: richt2@us.ibm.com
Andre Kramer <andre.kramer@eu.citrix.com>
01/23/2004 09:50 AM
|
To
| wsrp-pfb@lists.oasis-open.org
|
cc
|
|
Subject
| RE: [wsrp-pfb] [UDDI #4]
WSRP_v1_Bindings tModel equals WSRP_Produc
ertModel? |
|
Stepping way back for a moment,
I would say that end-users (as the actors in our *Portlet* UDDI use cases)
do not really worry about "producer services". They form business
relationships (with UDDI business entities) and discover and use Portlets
from those businesses (3). The relationship that you refer to is really
a portlet to business (and business to business) one for Portlet use cases.
The fact that a producer service
is required to actually make use of portlets (the UI components) is a WSRP
artifact that consumers (Portals) can deal with (wrt Portlet use cases).
That makes non-end user use cases, such as search for a WSRP version, where
the actor is the WSRP consumer secondary ones for me.
Getting back to UDDI / registry
mapping for (5) below:
Portlets can be nicely abstract.
They are flagged as being a "WSRP Portlet" with access/binding
information being the portlet handle and some kind of reference to the
producer service (i.e. service key).
However, if I know that my WSRP
consumer implementation only supports WSRP version 1.0, then I need to
filter all portlets by WSRP version. Later, when I select and use a particular
portlet, then my consumer needs to dig down a level and register with the
portlet's producer. Users should not get a version failure at this stage.
Our *Producer* UDDI use cases
are different and likely involve administrators (as the use case main actors)
searching for and registering with producer services directly so that they
can make portlets available to end users (2). But this would then tend
to make use of our service discovery factor for (4)?
regards,
Andre
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 23 January 2004 14:20
To: wsrp-pfb@lists.oasis-open.org
Subject: RE: [wsrp-pfb] [UDDI #4] WSRP_v1_Bindings tModel equals WSRP_Produc
ertModel?
If the importance of use case #4 is under debate, I would prefer to debate
it as a use case rather than convoluting the discussion with issues arising
from a specific mapping to UDDI.
The reason I view this as a fundamental use case is that I expect page
designers to frequently want to know what portlets they gained access to
via a business relationship that has been established between a pair of
Consumer and Producer enterprises. I would expect this query to occur at
least as frequently as the generic "What portlets are available"
query as the page designer's real question is "What portlets can I
use".
As to your #5, "locate all Portlets
supporting a particular WSRP version", what scenario are you envisioning
where this query would be issued?
Rich
Andre Kramer <andre.kramer@eu.citrix.com>
01/23/2004 04:22 AM
|
To
| wsrp-pfb@lists.oasis-open.org
|
cc
|
|
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]