Portal Container specification draft :

The portal container defines an environment for portal services.

This does not cover or focus on the followings :

• Advanced user management : the user/group management is not done at the portal container level.

• ...

The various base services recognised for portal are (see the UML diagram which complete

that part) :

• PortalContainer : the portal container aggregates a set of portals and applications.

• Application : this represent a web application and holds the various components that

  may come with.

• Component : a component child of an application, an example is a JSR-168 Portlet.

• Instance : a instance of a component. Its configuration is copied from the component configuration

  and may be customized. Thus is to possible to have several component running with different configurations.

• Window : the placement of an instance on a page, one instance can exist on several different pages

  and can even exist several times on the same page. The state held by the window is usually made of

  the viewport size, the placement, etc...

• Portal : the portal groups a set of instances. It is possible to have different portals

  with different configuration.

Several concerns of these services are managed by the portal :

• Lifecycle : cf microkernel. Services can be created declaratively

  from a deployment descriptors or can be created on the fly while the portal is running.

  One comparison in JBoss is : EJB container created from ejb-jar.xml, JMX management console

  triggers are created by using the management console and persisted somewhere

• Properties :

  a service delegates its property management to the portal.

  Properties a grouped in namespaces. These can be persistent or not depending on the nature

  of the service and its configuration.

• The client must see this as a tree. But each node of the tree can have a different

   implementation, for instance one node may maanage properties locally, one node could

   be persistent and one node could be persistence and replicated.

• An abstract set of interface is today designed :

• Replication : when a component instance is created it can be done locally

  but if the portal is replicated on a cluster there is a need to create the same component

  instance on all the nodes. Regarding properties their state must be managed on the cluster as well.

• Client context : component instances have a state. Usually the client context

  in stored in the client HTTP session.

• Deployment : web application deployments are intercepted and creates an application

  in the portal. During this phase custom component are given a chance to react and create component

  in the application. An example : the portlet component extension will look for /WEB-INF/portlet.xml

  and create portlet containers.

• Invocation : each web request is the serialization of a component invocation.

  The portal is responsible for encoding/decoding these invocation with URLs. This is pluggable to

  allows different flavors of URLs patterns.

• Internationalization : offer to each component a common way to work with resource bundles

  and encoding.

• Unified result, during an invocation a result may be :

• a redirection

• a page fragment

• an HTTP code

• a throwable : application error, unexpected error

• unavailable

• not found