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


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

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

Subject: Re: [wsrp][interfaces] separate administration interface


On your first comment, that toolbox that you mention has to provide a containment for the portlet similar to a portal, in addition you are restricted to a 'toolbox' that provides markup support, the same supported by the portlet. Imagine an administrator having to use a phone (or an emulator) to administer a portlet because the only thing the portlet supports is WML.

On your second comment, my concern is not having that alternate mechanism always available. I would feel more comfortable if we say that both mechanisms  have to be present and that both have to allow the same level of configuration.

I do not see a clear difference between settings and configuration other than attributes guarded by a different roles and who may modify them. Would you please clarify that for me?



Michael Freedman wrote:
I don't see that the current point of view leads to the two deficiencies you state:
* An administrator has to set the portlet template in a portal page in order to configure it.
* There is no provision, neither metadata, to enable administration through other means such as a command line tool or a
configuration console. The Administration has to be done exclusively through the portal.

On the first, our current discussions page isn't modeled/discussed at all.  Rather, portlet entities can come into existence and they can be operated on.   I can easily see an environment that will create a portlet entity to represent a template in a toolbox.  Such an entity will be managed by the portal/consumer differently then entities created on pages.

On the second, allowing a mode/operation to support personalization/administration doesn't prevent alternative control of such information.  We have been discussing a requirement for  a setProperty/CustomizationData API that a client can use to update data directly.  With such an API you could have a command line interface and an end user interface (or with properly defined meta data) a command line only interface.

If you buy this then the question before us seems to be how do we want to model the (common) portal practice of exposing this function within the portal UI.  At least for settings (those things a page developer or an end user does) I prefer "extending" or utilizing the current personalization model we have vs. an independent one.  It probably would be easier to convince me for a separate model/interface to manage/control a portlets configuration (as opposed to its settings).  But this doesn't seem to be what you are concerned about.

Alejandro Abdelnur wrote:


In both cases, Personalization and Administration, I’m referring to the customization and personalization capabilities that a portlet exposes.

As it has been discussed so far, Administration is just a special case of Personalization where the user, because he/she has an administrator role, can set configuration data at template level and because of his/her role can see/touch more configuration parameters.

I see Personalization done through the portlet (i.e.: when the user clicks the EDIT button) as the user has the portlet in his/her portal page.  The portlet itself knows how to persist the configuration data that is meant for a specific user, the one making the customization. Based on the user’s roles more or less configuration parameters are exposed to the user.

The main problems I see by doing Administration in the same way as Personalization are:

* An administrator has to set the portlet template in a portal page in order to configure it.
* There is no provision, neither metadata, to enable administration through other means such as a command line tool or a configuration console. The Administration has to be done exclusively through the portal.

I’ll prepare a list of requirements on this matter and I’ll send it to the alias.

I have other concerns regarding portability of portlets across portlet containers but this is outside of the scope of WSRP.



Jeff Broberg wrote:

I am alittle confused.  If a portlet wanted to expose some administration
capabilities such as allowing parameters to be modified for personallization
wouldnt they expose an "Administration" action that would then be shown to
the appropriate users based on their roles.  Or is the type of
administration that you are talking about different from the
customization/personalization capabilities that a portlet exposes ?


-----Original Message-----
From: Alejandro Abdelnur [mailto:alejandro.abdelnur@sun.com]
Sent: Thursday, May 30, 2002 7:58 PM
To: wsrp@lists.oasis-open.org
Subject: [wsrp][interfaces] separate administration interface

I have some concerns on the idea of using the usage interface for doing
administration tasks on a portlet.

I think we should have a separate administration interface. And,
probably, some metadata (provided by the portlet) describing how the
portlet should be administered.

I'm re-posting a message I've sent last week, as it was a reply to
another email, because of the subject, some of you may have overlooked
it. Mike and Eilon replied to it, so you may want to check the thread in
the archives.

Thanks and regards.


-------- Original Message --------
Subject: Re: [wsrp][interfaces]: Portal Usage Scenario
Date: Tue, 21 May 2002 16:57:54 -0700
From: Alejandro Abdelnur <alejandro.abdelnur@Sun.COM>
Organization: Sun Microsystems, Inc
To: "Tamari, Yossi" <yossi.tamari@sapportals.com>
CC: "'Thomas Schaeck'" <SCHAECK@de.ibm.com>, wsrp@lists.oasis-open.org

Tamari, Yossi wrote:

Hi Thomas,

I don't think that the fact the portal can set the portlet's properties
means that there can be no plug-and-play.
The Portlet can advertise its properties and their type (XML-Schema like)
its meta-data, and the portal can use this meta-data to automatically
display a set-properties page. While this page can not be as customized as
the portlet generated page, it has the advantage of creating a uniform
set-properties look and feel throughout the portal.

I'm just saying both options have their merits, and we should regard both.



I agree with Yossi. We should investigate/consider other alternatives.

This is somehow related to an issue I've brought up in the WSRP/security
conf call last week about "...separation of interfaces and roles for
administrative vs. non-administrative usage. ..."

I see some key problems on the approach we are heading to, where we do
not have a separate administration interface from the regular usage
interface. Administration and personalization are very different beasts.

Using a definition from a colleague, personalization of a component is
when a user customizes the behavior of the component for himself; while
administration is when a user customizes the behavior of the component
for one (other than her) or more users.

I see personalization being done through the usage interface, as most
portal frameworks -if not all- do it today.

I see as a possibility to do administration of portlets through
portlets, not the same portlet but a special administration portlet
provided by the WSRP service.

I have problems seeing administration functionality being done through
the usage interface of the same portlet is to be administered.

Personalization is about a given portlet instance for a given user.
Administration may have to deal with roles, groups, templates, etc.

In my opinion, it will be very hard to implement a portlet to do this
administration unless the portlet is knowledgeable of the WSRP service
configuration data model. A portlet knows about the business logic it
produces presentation logic for. A portlet knows about the
configuration/personalization parameters it needs. But a portlet does
not necessary know how the container hosting the portlet organizes and
stores the configuration or personalization parameters handled to the

Another problems that I see are:

* The administration interface should allow an administration tool to be
built using portlets, but it must not impose additional requirements on
the administration framework.

* Administration should not require the administrator to put the portlet
in his portal page in order to administer it.

* It should be the responsibility of the WSRP service (or the portal),
but not of the portlet, to manage the details of delegated administration.

* Security of the usage and administration interface may be different.

* It's delegated to the portlet to decide if a user can do
administration or not.

* The usage interface may have different scalability requirements than
the administration interface.

Finally, there are different specifications that address management of
resources in distributed environments such as CIM, SMNP, JMX (Java
specific). Also, in OASIS there is a proposal for a Management Services
TC. We should investigate if any of them are suitable.



To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

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

Powered by eList eXpress LLC