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 13:43:43 -0500
I think the key to this discussion is
deciding where to draw the line about what is the minimal required information
when publishing. Sounds like we have a couple of groups:
A. Functionally required: This includes
#2 and #3
B. Strong use cases presented: Depending
on the point of view, this includes:
#1 - By making it
simple to find all Producers, we reduce mis-communication for users.
#4 - By enabling
straightforward queries for all hosted portlets, we enable viewing what
a business relationship makes available.
#5 - Through enabling
queries for portlets supporting a particular version, we reduce instances
of late error messages.
It sounds to me like the key question
is what of the later three make it into the required set for the information
model. I suspect this will end up being a TC decision and would therefore
suggest we figure out the best way of presenting the reasoning why each
could be important as well as any draw backs there might be in trying to
realize them in a particular registry. I would think this would want to
be presented earlier rather than later as it becomes foundational both
to writing up the abstract information model and concretely mapping to
the various registry specs. Anyone have the time available to draft/edit
a short presentation or document for this purpose?
Rich
Andre Kramer <andre.kramer@eu.citrix.com>
01/23/2004 11:36 AM
|
To
| wsrp-pfb@lists.oasis-open.org
|
cc
|
|
Subject
| RE: [wsrp-pfb] [UDDI #4]
WSRP_v1_Bindings tModel equals WSRP_Produc
ertModel? |
|
That's a good summary.
I agree that #1 could be synthesised,
but then:
"An Portal admin is told
on the phone to register with a WSRP producer. She is unable to locate
the producer in her Portal Admin UI which only shows < 2.0 versions."
"A Portal admin UI shows
all the Producers the admin can't currently import in red. (Presume this
is so that she will pay for an upgrade)".
However, we are still discussing
other kinds of portlet to producer references (e.g. to another UDDI or
an EJB Registry). Then #5 could be quite inconvenient (e.g. external network
is down) if #2 and #4 need to be combined.
Not all registries need to support
all 1 to 5 (different use cases for UDDI itself) so should we just allow
optional optimization of such queries (e.g. using taxonomies/categories
that we may not even define)? With #3 and #2 being the "must have"
use cases we address? The question of needing other protocol bindings (e.g.
supporting user single sign on) will cause this to happen anyway (as no
one would want to parse wsdls when searching).
regards,
Andre
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: 23 January 2004 15:31
To: wsrp-pfb@lists.oasis-open.org
Subject: RE: [wsrp-pfb] [UDDI #4] WSRP_v1_Bindings tModel equals WSRP_Produc
ertModel?
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]