Re: [wsrp][interfaces]: Portal Usage Scenario

[Michael Freedman <Michael.Freedman@oracle.com>]

Can you clarify what you mean by "Administrator"?  In our world we have (at
least) three levels:
     a) Administrator
     b) Page/Portal Designer
     c) End User

Your use of Administrator seems to map closest to our (a) Administrator.  [see
definitions below]. When others have talked about it I have mapped to (b)
Page/Portal Designer.  I can see how (a) might be done out of the "usage
interface".  Its less obvious to me the value to do (b) outside the "usage
interface".

Definitions:

The Administrator is responsible for registering/adding portlets to the portal.
The administrator can configure portlets (change those configuration settings
that are modifiable).  Changes made here effect all portlet instances created
here after.

The Page/Portal Designer is responsible for developing the initial structure of
the portal for a collection of end users.  In doing so the Page/Portal Designer
is capable of modifying portlet settings.  Portlet settings may effect either
portlet state or behaviors of a specific portlet instance (though its just as
easy to imagine that this instance is a template for future instances).
Commonly, these settings include the End user customization attributes allowing
the Page/Portal Designer to preset defaults for the End-Users.

End User is responsible for personalizing the Portal.  In doing so they are
capable of personalizing portlets.
   -Mike-

Alejandro Abdelnur wrote:

> 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) in
> >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.
> >
> >       Yossi.
> >
> >
>
> 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
> portlets.
>
> 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.
>
> Regards.
>
> Alejandro
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>