Introduction

Command runs a job and Event provides the input (command pattern). Part of the input is a list of listeners (observer pattern) for end-of-the job and during-the-job analysis. They are called OutputListener and ExeListener, respectively. Event is an interface and as such Command is reuseable across input providers. EventImpl provides a base implementation for Event using Properties. Those properties are delegated to appropriate builders, building objects specified in the Event interface. The properties can be specified in a well-defined XML, Console-XML and the jos run via ConsoleClient. There is a also a GUI interface of the same jobs via Job. Job has OutputComponent and ExeComponent which are component counterparts of OutputListener and ExeListener, respectively. Job does the work of Console-XML, letting user modify the properties using a GUI and passes the modified properties to the same command for execution. This pipeline ensures that all GUI Jobs can be specified in Console-XML as well.

 A Hello World Example

public class HelloWorld {

   public static class Cmd extends Command<HelloWorld.Evt>{
      @Override
      protected void executeImpl() throws CommandException {
         final String name = getEvent().getName();
         getPrintWriter().println("Hello " + name + ", Welcome to my World!");
      }
   }

   public static class Evt implements Event{
      String getName();
   }

   public static class EvtImpl extends implements HelloWorld.Evt {

   }

}

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.