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

Title: Message

To throw another idea into the puzzle: we have had an implicit assumption 
that administration is a "mode" of the portlet (which correlates with many 
portal implementations). There might be merit in also considering the option 
that administration is another service (possibly a complete WSRP-compliant 
service) that's provided by the same business entity that provides the portlet 
itself, but is provided using a separate service (WSDL-wise). This would support 
implementations where the administration capabilities are deployed in a separate 
environment than the run-time capabilities (e.g., secure/non-secure). In this 
model, each portlet may have a sister portlet that's responsible for its 
administration.

 

Not sure if that approach provide significant value, but it might hint 
that this topic is worth a somewhat more elaborate 
discussion.

 

--Eilon

  

  
-----Original Message-----
From: Alejandro 
  Abdelnur [mailto:] 
Sent: Wednesday, May 
  22, 2002 5:33 PM
To: Michael Freedman
Cc: Tamari, Yossi; 
  'Thomas Schaeck'; 
Subject: Re: 
  [wsrp][interfaces]: Portal Usage Scenario

  
My reply may not have been clear on this, I was not referring 
  to 
individuals when I've said that (b) is a subset of 
  (a), I was referring 
to the levels. Looking at the 
  definition of (b), from the portlet 
perspective, (b) 
  level is a subset of (a) level. 

  
I have concerns on putting this as a requirement. As I've 
  written 
yesterday, a portal could definitely leverage 
  a portal framework for its 
administration (and 
  Page/Portal Designer) but I don't like that being 
imposed. 

  
Also, I do not like the idea of a portlet being responsible 
  for its own 
administration as this could include 
  delegated administration and it 
would the portlet, not 
  its context, the one deciding what a given 
administrator can do. 

  
I'm more comfortable with the idea of providing metadata 
  together with 
the portlet. 

  
The metadata approach does not preclude a WSRP producer to 
  offer 
administration of application portlets through 
  WSRP-producer portlets 
that process the metadata and 
  create the proper content. This would 
allow a WSRP 
  producer to use the 'usage interface' for administration 
but it would be done using WSRP producer specific administration 
  
portlets different from the application portlets. And 
  it would not 
require to do this through a 
  portlet. 

  
Regards. 

  
Alejandro 

  
Michael Freedman wrote: 

  
> Two potential reasons: 
>     a) in practice we find that the 
  individuals given the Admin role 
> and those given 
  the Page design role are distinct users vs. being a 
> pure subset. 
>     
  b) We have (and would like to continue to) provide page design 
  
> operations via the "usage interface". 
  
>    -Mike- 
> 
> Alejandro Abdelnur wrote: 
  
> 
>> Mike, 
>> 
>> I agree with (a) 
  Administration and (c) End User level definitions as 
>> you are describing them. 
>> 
>> I think that all (a) 
  Administration functionality should be done 
>> 
  outside of the 'usage interface'. 
>> 
  
>> What is the rationale not to see (b) Page/Portal 
  Designer as a subset 
>> of (a) Administration 
  when from the portlet perspective it's just a 
>> 
  further configuration of portlet settings ? 
>> 
>> Regards. 
>> 
>> Alejandro 
>> 
>> Michael Freedman 
  wrote: 
>> 
>>>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> 
  
>>>> 
>>> 
  
>>>      
>>> 

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