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

[Alejandro Abdelnur <alejandro.abdelnur@sun.com>]

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