Version 4

    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