Hm.... This is getting interesting. Let me combine it with the
interesting use cases in Thomas' e-mail.
"Use Cases:
- A news WSRP service allows
users to select the news topics they are
interested in. They have
thousands of portals as customers and don't want
to persist all portlet
instance customizations of 10.000.000 users on their
site -> They require the
consumers to store the instance data ( selected
newsfeeds) and return this
data to be stored on the consumer and be sent
with subsequent
requests.
- A frequent flyer WSRP
service allows users to enter their frequent flyer
IDs and PINs (via a popup
window going to the service via SSL). They
consider this information
sensitive and don't want to have it stored at
portal servers -> They
implement the WSRP service to store instance data
itself and just return the
instance handle without additional data to be
stored on the consumer and
sent with subsequent requests."
I think there is a
fundamental difference between the two, and it is this difference which
_mandates_ who stores the data.
In the first use case, the
WSRP is being "invoked" on behalf of a user *of the portal*,
i.e. it can be seen as a case where the WSRP is run "under" the portals
user credentials.
In the second use case, the
WSRP is being "invoked" on behalf of a user *of the portlet*,
i.e. the WSRP is run "under" another user other than the portal user, and somewhere (in
the portal? portlet?) there is a map from one to another.
I submit that
personalization data storage should be "near" the user that the WSRP is being
"run under". Of
course, there may be use cases which validate this, but I think it is
fundamental and not "by chance".
Note that if the user "belongs" to the portlet, then
understanding of the portal hierarchy is not necessary by the portlet, as the
user "belong" to the portlet and so handling of the data is done using portlet
rules. And if the user "belongs" to the portal, then again understanding of the
portal hierarchy is not necessary by the portlet, as the user "belongs" to the
portal and so handling of the data is done using portal rules. (Whew! I'm
sure I can explain it better, but it's 1AM here
:->)
Gil
-----Original Message-----
From: Michael Freedman
[mailto:]
Sent: Thursday, April 11, 2002
00:07
To: Gil Tayar
Cc:
''
Subject: Re: [wsrp][interfaces and
protocols]: Portal using WSRP Service
Gil,
1) As I replied to Yossi, copy/clone is relevant to WSRP/portlets if the
portlet maintains its personalization data.
2) I agree that the "arbitrary levels" function complicates the portlets
life in managing the personalization data and it will be a challenge to define
this in an abstract way via WSRP so portals can define their own
hierarchies. But I don't think we can avoid doing so. I believe
(and we have found in practice), that there are some portlet providers that
find it unacceptable for the portal to know/maintain anything about its user
preferences. Also some portlets have personalization data that defines
customizations of "push" operations. These are very difficult to model
in a store and pass on request model. A final note, we have found in
practice that having a portlet maintain personalization data across portal
instances does not add complexity (over a single instance). I am pretty
confident we could articulate a model in WSRP that works well.
Good point identifying that it all boils down to who manages the
personalization data -- it has been added to the questions list.
-Mike-
Gil Tayar wrote:
1>How does your
two terms "Serialized/Stored Instance" and "Active Instance" differ from the
one's in my document; "Personalization Data" and "Portlet Instance"?
They seem very similar to me.
"Portlet Instance" in
your document means - "a portlet on a page; or more generically a portlet in
the portal layout structure". If this means a portlet instance is created
only when viewed by the end user (i.e. runtime and not design time),
then my apologies for failing to
understand.I believe my failure
to understand came from the list of operations you designated on portlet
instances. For example "You can copy a portlet instance. By copy it is
meant that a second portlet instance comes into being with its
personalization data being a duplicate of the instance it was copied from".
Why does WSRP need such an operation? Instead (In your terminology), the
portal can just create a new instance with the personalization data used to
create the old instance. Now, I understand why a portal would need to expose such
functionality to the end user (copy/paste of a portal on the page), but why
would WSRP?2>Also, why do
you think its important/required that portal store/manage the portlets
(producers) settings and personalization data? Isn't there value in
allowing these portlets to store/maintain this data
themselves?
Good question (and very much related to the
first!). This may be true, but remember that a remote portlet may
work with multiple portals (each with a different user base) at the same
time. If we require the portlet to store customization preferences, then
this puts too much burden on portlet. In the "local" portlet world, the
portlet had access to infrastructural code (of the portal) that can store
the preferences for the portlet. This structural code was usually code
supplied by the portal. In the remote portlet world, the portlet is "alone",
and must supply "preference" storage themselves, i.e. a
database. Moreover, this information must be synchronized with the data
stored in the portal itself about the portal instance (for example, the
location of the portal instance on the page). So the two must be
synchronized. But this is difficult - what happens when the user deletes the
portal instance from the page - should the portal send a "deleteData"
message to the portlet? What if the portlet is "down" at that time? Now the
portal needs to queue the request.Another (more conceptual/logical) problem is that (and I quote from
your document) "There are an arbitrary set of personalization levels defined
by the particular portal. The levels are hierarchical. The
deepest personalization level that has any overriding values controls the
user's view" - do we expect the portlet to understand this hierarchy and the
rules governing the overriding and inheritance? If portlet's store the
personalization data, then they must. And if they must, then WSRP must
define the hierarchy and the rules. Do we expect WSRP to standardize these?
Seems to me that this is the domain of the portals, and not of the
interface.I think these two
questions all boil down to the second one: who manages the
personalization/customization data - the portal or the
portlet?Gil
-----Original Message-----
From: Michael Freedman [mailto:]
Sent: Tuesday, April 09, 2002
00:23
To: Gil
Tayar
Cc:
''
Subject: Re: [wsrp][interfaces and protocols]: Portal using
WSRP Service
Gil,
How does
your two terms "Serialized/Stored Instance" and "Active Instance" differ
from the one's in my document; "Personalization Data" and "Portlet
Instance"? They seem very similar to me.
Also, why do you think its important/required that portal store/manage the
portlets (producers) settings and personalization data? Isn't there
value in allowing these portlets to store/maintain this data themselves?
-Mike-
Gil Tayar wrote:
Hi
Thomas,
<note>
As I was not in
the F2F, and have not yet posted to this mailing list, I would like to
introduce myself. My name is Gil Tayar, I am the Chief Architect of
WebCollage, and a colleague of Eilon Reshef.
</note>
I very
much liked your life-cycle description, and I think it can provide a
descent framework on which to base WSRP's life-cycle and
interface/protocol discussions. It also complements Mike's more detailed
document very well.
To
summarize the states of a portlet, you have the
following:
1.
Unbound: The portlet exists, but there is _no_ connection to the
portal.
2. Bound: the portlet is bound, and
registered in the portal.
3.
Template: a portlet template is created by the portal, with a
given set of parameters.
4.
Instance: A template inside a given user
page.
As a
member of WSIA, where states #1-#3 do not "exist" (yet!), I would like
to dig deeper into the "Instance state". It seems to me that this state
should be subdivided into two:
4a.
Serialized/Stored Instance: the template and the customizations
the user selected and put in the page, as it exists in the "persistence
store/database" of the portal.
4b. Active
Instance: the entity used to render the portlet and "do the
actions".
I believe
the distinction between the two is an important one, as important as the
distinction between a java object serialized to a stream, and the java
object itself. One (the serialized object or portlet) is "just" data
used to create the other.
To make
another point, the state names I gave are a bit confused. Some are
"states" and some are "entity types". We can deconstruct this
further:
Entity
Types -
1. Portlet. The remote service that
responds to WSRP messages.
2. Bound
Portlet. The location and registration information for the Portlet,
as stored by the portal.
3. Portlet
Template. The set of parameters to be used when creating a Stored
Instance, as stored by the portal.
4. Stored
Portlet Instance. The set of customization options to be used for a
certain user page, as stored by the portal.
5.
Active Instance. The viewed portlet, when viewed inside the
portal.
The above
lists turns the "states" into more of a list of "operations" which
create entities from other entities -
Operations
-
1. Binding: a request of the
administrator(?) to the portal to register the portlet and store
location and registration information, to be used when creating a
portlet template.
2. Creating a
Template: Using the location and registration information, get the
meta-data, query the administrator(?) for the parameters, and store
them.
3. Inserting Template into Page: User
selects a template, customizes it, and creates a Stored Portlet Instance
from it.
4. Viewing the Portlet:
User opens portal, and the portal creates an Active Instance from the
Stored Instance.Hope it makes sense,Gil-----Original
Message-----
From: Thomas Schaeck [mailto:]
Sent: Sunday, April 07, 2002 18:19
To: Michael Freedman;
Subject: Re: [wsrp][interfaces and protocols]: Portal using WSRP
Service
Hi Mike,
here's the life-cycle writeup I promised:
Binding to a WSRP Service
-------------------------
Pre: - The Portal and the WSRP Portlet Service are not
bound -
1. The administrator browses the directory for WSRP
services using the
portal admin UI
-->
- The Portal finds the WSRP Portlet
Service in the directory
2. The administrator selects a WSRP service
-->
- The Portal makes a call or series of
calls to the WSRP Portlet Service to
establish
a relation (bind) (may include establishing a trust relation, see
my security note)
- The
Portal creates a portlet template referencing the WSRP portlet
service. (Potentially, the template may need to be
parameterized with
template settings to become
usable.)
Post: - The portal is bound to the WSRP service through
the portlet
template, users may now see the
template beeing offered in the portal's
customizer -
Creation of Instances
---------------------
Pre: - The portal is bound to the WSRP service through
the portlet
template, users may now see the
template beeing offered in the portal's
customizer/toolbox -
3. A portal user selects the portlet template to be put
on a page -->
- The portal server creates a
portlet instance from the portlet template
-
The portal server links the instance to the user's page
Post: - The portal is bound to the WSRP service through
the portlet
template, users may now see the
template beeing offered in the portal's
customizer/toolbox and a unique instance which may have
persistent data now
exists for the user
Destruction of Instances
------------------------
Pre: - The portal is bound to the WSRP service through
the portlet
template, users may now see the
template beeing offered in the portal's
customizer/toolbox and a unique instance which may have
persistent data now
exists for the user
4. A portal user discards a portlet instance from a
page -->
- The portal discards the link from
the page to the instance
- The portal discards
the instance
Pre: - The portal is bound to the WSRP service through
the portlet
template, users may now see the
template beeing offered in the portal's
customizer/toolbox, the unique instance does no longer
exist
Unbinding a WSRP service
------------------------
Pre: - The portal is bound to a WSRP service through a
portlet template,
users may now see the
template beeing offered in the portal's customizer -
5. The adminstrator browses the list of portlet
tempplates and discards the
portlet template
-->
- The portal makes a call to the WSRP
Portlet Service referenced in the
portlet
template to undo the binding
- The portal
discards the portlet template
Post: - The Portal and the WSRP Portlet Service are not
bound -
Best regards,
Thomas
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
