portals-pluto-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Heimo Laukkanen <heimo.laukka...@helsinki.fi>
Subject How to integrate Pluto1.1 into a portal? (And when to do it)
Date Mon, 05 Dec 2005 06:42:08 GMT
Hi all,

I work currently at the University of Helsinki, and we are in progress 
of finding and integrating a JSR-168 compliant portlet container into 
our portal. Pluto1.1 is one candidate since it looks much cleaner and 
nicer than the 1.0.1.

And yes, I do understand that Pluto is a reference implementation - but 
bear with me when I do ask some questions that relate to production 
enviroments.

Our portal uses Spring Framework - and we are quite fond in doing things 
the spring way, since it eases our maintenance work and makes thing more 
consistent in style with each other.


Questions:
----------------------------------------------------------------------

- How stable is the internal structure of Pluto 1.1?

   Ie. if we start to integrate Pluto now into our portal structure -
   will we soon find that there has been a major refactoring and almost
   all APIs have changed?

- Is anyone even thinking about using Pluto 1.1 in production

- Are there any major reasons not to do it

- Is there something extremely important missing/hidden that
   we should watch out?

- Is there something better to consider for production use?

- Has there been any thoughts on scalability and caching?

Since our portal will have tens of thousands users, we are quite keen on 
making sure that each bit scales nicely even when loads grow.


How to do integration?
----------------------

We are interested to use parts of the portal driver and the portlet 
container as it is, and this is what I thought that we need to do to 
integrate Pluto into our portal.


1) Configurations / configurability

We will most likely take a stab at the way how portal driver is 
configured now - and use/create something that is more in line with how 
everything else in our portal is configured.

Naturally lots of things - like layouts, user preferences etc. - will 
come from the database.


2) Create own implementations of core services:
        - PropertyConfigService:
               To provide information about portal ( piece of cake )
        - PortletRegistryService:
               To provide information about available portlet apps and
               portlets
        - RenderConfigService:
              Implement our own url and page management
        - PortletPreferenceService:
              Based on DBPortletPreferencesService implement our own
              DB-based preferences storage-service that integrates with
              our other DB schemas


3) Implement our own management layer for user data and user preferences

     In the checkout that I have been playing with, I did not notice 
anything about providing userdata to portlets from portal / portlet 
container. But that is trivial thing to implement.


Is there anything else that we should take care of?

-huima

Mime
View raw message