...

Architecture

Below we have a high level view of the interactions between a new plugin and Pluto. This is essentially the 'plumbing' beneath the administration console.

We have a WAR file containing portlet information and the definition of an ACE Gbean on the left. The ACE GBean is the way in which we can invoke operations on Pluto (this will be covered shortly).

The portlet container that we use is Apache Pluto 1.2. Pluto allows for dynamically adding and removing pages and portlets without restarting the portlet container. The approach is important from a user interface standpoint, because we are not forced into performance bottle necks by restarting server components unnecessarily.

The dashed box around Pluto and its Pluto's API is intended to describe the approach taken to decouple Pluto's implementation from our own. This is a design decision to allow Pluto to be replaced by a different portlet engine for possible future development.

Understanding Through Usecases

Let's dig into the architecture a bit more now. It should be noted that the intended purpose of this architecture is to leverage Geronimo's flexible nature, as well as have the actual administration console be reflective of Geronimo's pluggability. The infrastructure should be simple to understand and easy to build on top of.

The first use case we will look at will also be used to describe the individual pieces that make administration console function.

On the left, we begin with a simple Geronimo deployment plan (geronimo-web.xml, for instance). This deployment plan is the same deployment plan included in any archive that you may wish to deploy into Geronimo. In this case, the deployment plan includes the definition for a special ACEGBean. The specifics of what goes into an ACEGBean will be described in more detail later.

On the right, we have Pluto. When Pluto starts, a PlutoContainerServicesGBean is started. This is how we access Pluto. When we deploy our archive, an ACEGBean containing portlet configuration information is started (based on the configuration specified in the deployment descriptor). The ACEGBean is where the developer specifies the information for the portlets and pages they are adding to the administration console.

The ACEGbean implements GBeanLifecycle. When the ACEGBean is started, it asks the kernel for the PlutoContainerServicesGBean (1). The ACEGBean gets the service (2) - now the ACEGBean can access Pluto through its API. We want to add a portlet to our administration console, so we invoke Pluto's addPortlet method, which will update Pluto's internal model.

In the above image, each of the grayed out GBeans is an ACEGBean instantiated by a deployment descriptor. Each ACEGbean modifies or adds exactly one page in the administration console. This essentially means that portlets may be added to an existing page by specifying the name of an existing page, or a separate page can be created if one with the specified name does not exist.

A deployment plan may also include definitions for multiple ACEGBeans. This means that a deployment plan, if it chooses to do so, may add as many pages to the console as it wants to.

Removing pages (Figure 3) from the console follows a similar process. Because the ACEGbean implements the GBeanLifecycle, when the installed component is stopped, its ACEGBean will also be stopped. When this happens, we once more ask the kernel for the PlutoContainerServiceGBean, which is used to call removePortlet on Pluto through its API. From the view of the administration console, the user will see the page has disappeared from the navigation menu (Figure 4). If the user starts the component again, the GBeanLifecycle's doStart calls addPortlet on Pluto Container, and the administration console extension reappears on the navigation menu (Figure 5).TODO: Architecture goes here

How to Develop an Administrator Console Extension (ACE)

...