[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?
-----Original Message-----
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Friday, January 23, 2004 10:44 AM
To: wsrp-pfb@lists.oasis-open.org
Subject: RE: [wsrp-pfb] [UDDI #4] WSRP_v1_Bindings tModel equals WSRP_Produc ertModel?
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
wsrp-pfb@lists.oasis-open.org 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
wsrp-pfb@lists.oasis-open.org 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
wsrp-pfb@lists.oasis-open.org 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
wsrp-pfb@lists.oasis-open.org 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]