An application based on Fluidlogic™ operates like this:

· A Client application issues a request containing one or more abstract commands to a request processor. An abstract command is an instruction to operate on persistent data in the database tier, but that contains no database specific implementation details. All commands in a request succeed or fail as a unit – a request demarcates a transaction.

· The request processor dispatches the request containing the abstract commands to its associated server.

· The server looks up and executes a concrete command for each abstract command in the request. The server determines which concrete command to execute based on a one-to-one mapping of abstract commands to concrete commands. A command is ‘concrete’ because it implements a service definition, which is what the server uses to realize the customized concurrency, caching, transaction, and persistence functionality. The database is updated and the transaction is committed.

· The server returns a response to the client. The response contains a command execution result for each command in the original request.

· The client takes the command results and either displays the results to the user, or proceeds to the next stage of its workflow.

Fluidlogic™ comes with a set of base Commands that you extend to create your own application-specific Abstract Commands. An abstract command defines a set of related operations. Each instance of an abstract command has a method and has an optional subject. The methods available are:

· Get: the client application requests instances from the persistent store using Get commands. Each Get command must be executed in its own request.

· Put: the client instructs the server to store the state of an object using a Put command. Can exist with other Put, Post, and Delete commands in a single request.

· Post: the client instructs the server to operate on a subset of the persistent state of one or more objects, such as adding 10 units to inventory. Can exist with other Put, Post, and Delete commands in a single request.

· Delete: the client instructs the server to remove the object’s state from the persistent store via a Delete command. Can exist with other Put, Post, and Delete commands in a single request.

You are free to define your own command methods, note that this will make your deployment incompatible with non-Fluidlogic™ HTTP clients. It is recommended that you stay within this set of command methods.

The subject of a command is typically the persistent business object on which the command will operate. You can create a command with multiple subjects, but only one method is allowed per command.

A command class is capable of implementing all of the available methods, and can implement multiple versions of each method. For example, you may create an abstract command that has the following interface [we will add the implementation details later]:

// this is the abstract command visible to the client application
public class ProductGPPD extends Command {

	// command method = GET
	public Product getByKey(Integer productId) {
	}
	
	// command method = GET, action = byname
	public Product getByName(String productName) {
	}
	
	// command method = PUT
	public void put(Product product) {
	}
	
	// command method = POST, action = inventoryadd
	public void addToInventory(int numberToAdd) {
	}
	
	// command method = POST, action = inventoryremove
	public void removeFromInventory(int numberToRemove) {
	}
	
	// command method = DELETE
	public void delete(Product product) {
	}
}

Since operations on the same entity are grouped in one place, commands are both fine grained and cohesive.

One drawback encountered when implementing a system based on the Command design pattern is the possibility of a command class explosion, where every unique command has its own class. Fluidlogic™ eliminates this problem by defining multiple methods and allowing multiple implementations of [‘actions’ within] the same basic methods. You typically create one abstract command per persistent domain object.

Therefore, instead of command explosion like this:

// without Fluidlogic’s ‘method’, you get command explosion
ProductGetByKeyCommand
ProductGetByNameCommand
ProductPut
ProductChangeQuantityCommand
ProductDelete

In Fluidlogic™, a single class takes care of all the commands related to a persistent business object:

// Fluidlogic commands are tidy and compact
ProductGPPD

Instances of this class will be parameterized to perform one specific task, one that would otherwise have required a separate class.

The ‘GPPD’ is a naming convention. When a command implements Get, Put, Post, and Delete, this is compressed into GPPD. When a command implements Get, Put, and Delete, this is GPD, and a separate command class will have a -Post suffix:

ProductGPD
ProductPostThis
ProductPostThat

You may choose to use this style if you 1) do not require Post methods, 2) your Post method implementations are complicated and you want them kept separate. You could also have a GPPD class and a special –Post class if the –Post class involves multiple subject objects and it would complicate the compactness of the GPPD class.