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
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
Unified result, during an invocation a result may be :
a page fragment
an HTTP code
a throwable : application error, unexpected error