Command Pattern

The Command Pattern

This is an example implementation of the Command Pattern (Wikipedia) design pattern build on top of Coherence.

The Command Pattern advocates that;

1. An action to be performed zero or more times at some point in the future should be represented as an object called a Command.
2. All necessary parameters required to perform the said action, should be encapsulated as attributes with in the said Command object.
3. The Command object must provide a mechanism to perform the action (typically represented an execute method defined on the said Command object)

This implementation of the Command Pattern additionally advocates that;

1. A Command may only be executed with in the scope of a target object, called a Context.
2. To execute a Command it must be submitted to a Context.
3. Once submitted , Commands are executed asynchronously. That is, the submitter of the Command does not block or wait for the Command to be executed after it has been submitted.
4. Commands are executed one-at-a-time, in the order in which they arrive at their Context.
5. A Command may not return a value to the application that submitted the said Command. If you require a Command that returns a value after execution, you need a Functor (see the Functor Pattern)

Dependencies

This project (like other Coherence Incubator projects) uses Apache Ivy for dependency specification and management. While a standard ivy.xml definition file ships with the source and documentation distribution, the following diagram visually indicates the current dependencies.

Coherence 3.6 Support

Coherence 3.5 Support

Previous Releases

The following releases are provided for historical purposes only.
Command Pattern 2.6.0, Command Pattern 2.5.0, Command Pattern 2.4.0, Command Pattern 2.3.0, Command Pattern 2.2.0, Command Pattern 2.1.1

Rationale

The Command Pattern provides a useful alternative to Oracle Coherence EntryProcessors with the advantage that Commands are executed asynchronously, instead of synchronously as is the case with EntryProcessors.

Additionally this implementation of the Command Pattern provides essential infrastructure for several other Incubator projects (namely the Store and Forward Messaging Pattern) to permit guaranteed, in-order, asynchronous processing of Commands.

Step 1: The Initial Environment

• One Client Application
• Two Coherence Cache Servers
• All part of the same Coherence Cluster ^*

^* The Client Application may be external to the Coherence Cluster when using Coherence *Extend

Step 2: Context Creation

• The client application creates an instance of a Context

Step 3: Context Registration

• The client application registers the created Context using a ContextsManager ^*
• The ContextsManager places the Context into a "primary partition" of the "contexts" Distributed Cache.
• Coherence ensures a backup of the Context is made to a "backup partition" (on separate JVMs and different machines where possible)

^* Typically an instance of the DefaultContextsManager

Step 4: Establishing the CommandExecutor (automatic)

• When a Context is registered, an internal event establishes an appropriate CommandExecutor and necessary infrastructure.

Step 5: Creating a Command

• The client application creates an instance of a Command

Step 6: Submitting a Command for execution

• The client application uses a CommandSubmitter to submit a Command for execution with an identified Context ^*
• The submitted Command is placed into the "commands" Distributed Cache (and automatically backed up)
• The submitted Command is then automatically queued (FIFO) and scheduled for asynchronous execution by the CommandExecutor for the Context

^* An individual Command instance may be submitted any number of times for execution to one or more Contexts. There is no need to create new instances of the same Command if it needs to be submitted for execution multiple times.

Step 7: Numerous Commands Submitted

• Multiple Commands may be submitted for execution at once.
• Commands are queued for execution (FIFO) in order of arrival at the Context

Step 8: Commands are executed by the CommandExecutor (Asynchronously)

• When Commands are queued for execution, an internal event notifies the CommandExecutor to start executing the Commands
• For efficiency, the CommandExecutor may execute Commands in batches (but remaining in order).

Step 9: Commands Automatically Cleaned-up when Executed.

• Once a Command has been executed, it is removed from the "commands" cache (as is the backup of the Command).