Proposal for Standardizing Portal Services

Owned by GaryG (Deactivated)
Last updated: May 19, 2010Version comment

A proposal for standardizing portal services such that administrative portlets could be developed outside of the uPortal war was brought up in a thread in the uportal-user mailing list.

The stated advantage to such work would be that standardized portal administrative portlets could be developed by parties outside of uPortal's core development team. In addition, if the standard were to be adopted by other portals, then there would be greater incentive and benefits for outside parties to develop portal administration portlets. In addition (and perhaps more importantly), it would open up greater integration possibilities with outside products and services to manage portals.

According to Eric Dalquist, "uPortal would have to find a way to expose a huge number of internal APIs 90% of which SHOULDN'T be used externally due to usage pattern restrictions on the API." While this proposal was stated by Eric not to even be at the bottom of the priority list for uPortal development as of May 18, 2010, there is interest from the community, including from Gary Weaver (of Duke University) and Tim Carroll (of University of Illinois at Urbana-Champaign).

In addition, Gary mentioned that previously he remembered plans being discussed of RESTful services for certain parts of uPortal, so perhaps RESTful APIs might be something to look at as a basis for the standard interface.

Gary stated that perhaps a starting point for a subset of services that could be offered could be in the list of import/export Cernunnos scripts (example of uP 3.2.1).

High-level List of Services Proposed to be Offered

Here is a list of high-level services that could be offered by splitting the administrative services off into its own web application with authentication and authorization these services (certain roles have access to certain services and not all services must be exposed).

Services proposed to be backed by uPortal implementations

  • Create/Read/Update/Delete User
  • Create/Read/Update/Delete Permissions
  • Create/Read/Update/Delete Group
  • Create/Read/Update/Delete Memberships
  • Create/Read/Update/Delete User Preferences
  • Create/Read/Update/Delete Fragment Definitions
  • Create/Read/Update/Delete Theme
  • Create/Read/Update/Delete Entity Type
  • Create/Read/Update/Delete Layout
  • ... ? (would need to look at each administrative portlet's requirements)

Services proposed to be backed by Pluto implementation

Backed by PortletRegistryAdminService

  • Create Portlet Application

Backed by PropertyConfigService

  • Read Container Name
  • Read Portal Name
  • Read Portal Version
  • Read Supported Portlet Modes
  • Read Supported Window States

Backed by RenderConfigAdminService

  • Create Page

Backed by RenderConfigService

  • Create/Read/Delete Page
  • Read Default Page
  • Read Pages

Backed by SupportedModesService

  • Read Portlet Config
  • Read Supported Portlet Modes
  • Read Portlet Managed Mode (boolean)
  • Read Portlet Mode Supported (boolean)
  • Read Portlet Mode Supported by Portal (boolean)
  • Read Portlet Mode Supported by Portlet (boolean)

Backed by SupportedWindowStateService

  • Read Windows State Supported
  • Read Windows State Supported by Portal
  • Read Windows State Supported by Portlet

Services Not Backed by uPortal or Pluto

Assuming this is an interface intended to be a standard for other portals (Liferay, JBoss, Websphere, etc.) it should possible include at least the interface for other portals' services.