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




I agree with Carsten. Alejandro, the "Management Services TC" is not Portal
specific is it?

Best regards,

Angel

Angel Luis Diaz, Ph.D
Senior Manager, Next Generation eXperience Frameworks
IBM T. J. Watson Research Center
aldiaz@us.ibm.com
(914) 784-7388 /  (914) 441-7594


Alejandro Abdelnur <alejandro.abdelnur@sun.com> on 06/04/2002 04:08:18 PM

To:    Carsten Leue/Germany/IBM@IBMDE
cc:    Angel Luis Diaz/Watson/IBM@IBMUS, wsrp@lists.oasis-open.org
Subject:    Re: [wsrp][interfaces] separate administration interface



Carsten,

That works assuming that everybody uses templates for a configuration
data model. I do see templates as an abstraction representing a
pre-configured portlet but I don't necessary see templates as the way
I'm storing that information in the the producer.

I would like to see an administration interface to allow arbitrary admin
tools (GUI & CLI driven), the current assumption is that everything has
to be done through the content rendered by a portlet.

I'm not saying we should not allow an administration UI done through
portlets, I'm just saying that it may not be enough or appropiate for
all cases.

An administration interface, decoupled from the UI, would also enable
integration with management frameworks. As I've mentioned before, there
is a proposal for a Management Services TC.

Regards.

Alejandro

Carsten Leue wrote:

>Alejandro - wouldn't the administraton ( = modification of configuration
>data) be done by editing the template and the condifuration by editing the
>portlet instance? In this case the would not be a need for a separate
>administration interface as the edit mode of the template already supplies
>one. The advantage is a consistent handling of confiuration/administration
>by simple switiching to the edit mode of the corresponding entity.
>
>Best regards
>Carsten Leue
>
>-------
>Dr. Carsten Leue
>Dept.8288, IBM Laboratory B÷blingen , Germany
>Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
>
>
>
>|---------+---------------------------->
>|         |           Alejandro        |
>|         |           Abdelnur         |
>|         |           <alejandro.abdeln|
>|         |           ur@sun.com>      |
>|         |                            |
>|         |           06/04/2002 04:35 |
>|         |           AM               |
>|         |           Please respond to|
>|         |           Alejandro        |
>|         |           Abdelnur         |
>|         |                            |
>|---------+---------------------------->
>  >
---------------------------------------------------------------------------------------------------------------------------------------------|

>  |
|
>  |       To:       Angel Luis Diaz/Watson/IBM@IBMUS
|
>  |       cc:       wsrp@lists.oasis-open.org
|
>  |       Subject:  Re: [wsrp][interfaces] separate administration
interface
|
>  |
|
>  |
|
>  >
---------------------------------------------------------------------------------------------------------------------------------------------|

>
>
>
>Angel,
>
>Assuming that you have a common API to code portlets, then you'll be able
>to deploy these portlets in any producer that support this common API.
>
>Then, a portlet could execute all the regular user functions run in any
>compliant producer, but for administration tasks the portlet would have to
>be aware of the configuration data model of the producer.  Unless all
these
>producers share a similar configuration data model for storing
>configuration, a portlet would only be able to do administration in the
>producer it has been coded against (or another with a similar
configuration
>data model).
>
>As an example of a different configuration data model than then one being
>used used (templates) during the WSRP-TC discussions consider the
>following: When a user selects a portlet and an instance is created the
>initial configuration values for the portlet are taken from default values
>associated with organization roles that are merged into a default set. So
>based on the user roles the default values will be synthesized.
>
>Regards.
>
>Alejandro
>
>Angel Luis Diaz wrote:
>
>
>            I have other concerns regarding portability of portlets across
>            portlet
>
>      containers but this is outside of the scope of WSRP.
>
>      I am curious! What are those concerns?
>
>      Best regards,
>
>      Angel
>
>      Angel Luis Diaz, Ph.D
>      Senior Manager, Next Generation eXperience Frameworks
>      IBM T. J. Watson Research Center
>      aldiaz@us.ibm.com
>      (914) 784-7388 /  (914) 441-7594
>
>
>      Alejandro Abdelnur <alejandro.abdelnur@sun.com> on 06/03/2002
>      01:22:49 PM
>
>      To:    jbroberg@silverstream.com
>      cc:    wsrp@lists.oasis-open.org
>      Subject:    Re: [wsrp][interfaces] separate administration interface
>
>
>
>      Jeff,
>
>      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.
>
>      Regards.
>
>      Alejandro
>
>
>
>      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 ?
>
>      jeff
>
>      -----Original Message-----
>      From: Alejandro Abdelnur [mailto:alejandro.abdelnur@sun.com]
>      Sent: Thursday, May 30, 2002 7:58 PM
>      To: wsrp@lists.oasis-open.orgSubject: [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.
>
>      Alejandro
>
>      -------- 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.orgReferences:
>      <5199D0E7CA63D511BB6F0008C75DAD1403653228@dbwdfx2e.wdf.sap-ag.de>
>      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>






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


Powered by eList eXpress LLC