How to integrate Pluto1.1 into a portal? (And when to do it)

[Heimo Laukkanen <he...@helsinki.fi>]

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

Re: How to integrate Pluto1.1 into a portal? (And when to do it)

["David H. DeWolf" <dd...@apache.org>]

See below:

On 12/5/05, Heimo Laukkanen <he...@helsinki.fi> wrote:
> 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.

Good! That's the point :)

>
> 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?

Potentially. I can't forsee anything at this point in time, but we are
definately still in development mode.  An alpha release will be coming
*very* soon (as in hopefully this week).  The biggest changes you will
see are adding support for more "optional" services.  I'd tend to say
that the basic apis (for creating and invoking the container) will
stay the same for all practical purposes.  I just can' promise
anything since we're still in development mode.

>
> - Is anyone even thinking about using Pluto 1.1 in production
>

Yes.  I have a couple of projects and as soon as we get alpha release
I will be submitting a patch to geronimo to upgrade them from 1.0.1 to
1.1.

> - Are there any major reasons not to do it
>

The one I can think of now is stability (as you mentioned).  How long
until you are production ready?

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

If you run through the testsuite you'll clearly see the areas that are
not yet fully functional.  Portlet preferences are about 60% there I
think.  User attributes are just being started. . .there are a couple
of other minor bugs here and there.  As a whole, session handling,
portlet scoped request parameters, request attributes, etc. . . are
all there.

> - Is there something better to consider for production use?

?

>
> - Has there been any thoughts on scalability and caching?

Scalability, yes.  Caching no.

>
> 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.
>

Any patches you submit would be *very* appreciated.

>
> 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.

Yes and no.  You don't *have* to use the portal driver.  The driver is
just there to provide a simple portal, an example of how to integrate,
and - if you'd like - provide a little kick start to get you going.

>
>
> 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

Looks like you're on top of things.

>
>
> 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?

Yes, FEEDBACK, FEEDBACK, FEEDBACK! :)

We'd love to hear more feedback concering 1.1.  Questions, Answers,
Suggestions, Documentation and Patches  are always very welcome.

>
> -huima
>