Anatomy of a Beatrix application

Figure: How the sample skeleton application is designed. Plugins marked (+) are those we have had to provide ourselves. The others are provided by Beatrix.

Figure  shows how our example application, ``skeleton'', is constructed.

This example application is detailed in Chapter , but in brief it provides a simple message consisting of the words ``world'' and ``hello'' among others.

The Manager and Worker classes are the standard Beatrix manager and worker netlets. Everything else is a plugin. Unmarked plugins are provided with Beatrix, while those marked (+) we have written ourselves.

The Manager netlet's plugins are as follows:

LifeCyclePlugin (+)

Starts up the application and adds all the other plugins. Flow control begins here. When start-up is complete all other flow is event-driven, perhaps by timed events (e.g. periodic checks on workers) or external events (e.g. a third party binding a service).

ServiceManager

A collection point for all the services the manager will provide. In this case, only the AdminServiceProvider.

AdminServiceProvider (+)

Allows the application's administrator to control it remotely from a console.

WorkerPool

Each worker pool is a collection point for plugins, all of which aid in the management of a particular worker type. In this case we have only one worker type and hence only one worker pool plugin.

InternalFacetCache

Beatrix allows netlets in the same application to communicate easily via facets internal to that application. The InternalFacetCache provides an extra tool to help this. It is plugged into the worker pool, which means it is accessible to all the other plugins in the worker pool.

SkeletonWorkerManager (+)

The main plugin which manages the deployment and life cycle of our worker netlets. It responds to a worker start event by adding the worker's plugins remotely. Hence the worker turns from a dummy netlet into a useful netlet dynamically. This plugin ignores worker die events. It also determines resource requirements when new workers need to be started.

FileSystemLocator

Helps the SkeletonWorkerManager find file system resources for workers. In fact, the way it is used in this example application means this plugin does all the work for the SkeletonWorkerManager, which therefore does nothing except configure it once.

SocketFactoryLocator

Helps the the SkeletonWorkerManager find a socket factory resource for workers. This plugin can take the entire workload off the SkeletonWorkerManager, just like the FileSystemLocator. But for the sake of example we have not done this. Instead, the SkeletonWorkerManager uses it explicitly to locate socket factory resources, then assesses the results itself and decides whether they are suitable.

As descibed above, the Worker netlet is configured dynamically by the SkeletonWorkerManager which adds these plugins remotely:

SkeletonWorker (+)

The first worker plugin to be started, and it is started remotely by the SkeletonWorkerManager. It binds the resources granted to it, but, since this is a dummy application, doesn't use them.

ServiceManager

The same plugin as above, this time added to the Worker netlet.

SkeletonServiceProvider (+)

Provides the main consumer service which in this case provides two facets. One is for applications to get the message; the other is for a user to get the message via a console command.