Introduction

The application framework is concerned with running jobs for the entire coalescent framework. It is also concerned with managing those jobs so that they are reusable. Command design pattern is used to implement the jobs and the observer pattern is used to implement the job analysis. Job analysis is further separated from the reports using template pattern.

Command Pattern

In the pattern, there are events and commands. A single event could correspond to multiple commands. Events bring the necessary input for the job and commands contain the logic to execute the job. It is obvious that the same input could be useful for more than one job. This separation of input and the execution of the job is natural and allows the reuse of the command. The events are rather interfaces that are implemented differently by the clients. In fact, the clients are characterized by the different event implementations.

Observer Pattern

The execution of a job is separated from the analysis of its output. This separation is good because different clients would like to perform different analysis on the same output. For that matter even a single client might want to do more than one analysis on the same output. In this case an analysis can be thought of as a view of the output. This enhances re-usability of the commands. This design is made more flexible by making the analysis dynamic using the observer pattern.

The request to do a particular analysis is thought as an input to the job and thus processed by the event. More than one such analysis can be be dynamically (i.e. at the run-time) attached to the event so as to consume the command outputs (as they happen rather than at the end of the job) synchronously or asynchronously. This gives great flexibility to the user in terms of mixing and matching different analysis.

What are Provider and Builder? How are they different?

• Provider is an Interface and parametric on T The most important  method is T create() throws ProviderException.
• Builder is an abstract class. The most important method is T build() BuilderException.

What are Command and Event? How do I run a Command?

Job

A job is basically any analysis that is worth automating. It is important to note that there is significant maintenance overhead to a job. One should make sure that the analysis is interesting enough before creating a new job. Some rules of thumb for bad jobs are:

1. A job that is a trivial application of an existing job
2. A job with the objective of automating a series of other existing jobs
3. A job that goes out of the way producing ready reports. The purpose of the output should be flexible enough so that it can be processed further as to the needs. It should not try to create report-ready outputs. That shifts the focus of the application.

Hallmarks of a good job are:

1. A job that is atomic in nature
2. A job that answers a theoretical question.