The Local/Dispatchable Command Pattern proposes that instead of a single command interface, two are provided - a local command, which will always be executed in the same context as the controller, and a dispatchable command, which has the ability to be transferred to an EJB server for execution. In a web application, the controller context is the web container.
When implementing a system using the EJB Command Pattern as defined in ‘EJB Design Patterns’ (Floyd Marinescu), the functionality of the application is contained in lightweight command classes. These commands are transferred to the EJB container for execution.
The Local/Dispatchable Command Pattern proposes enhancements to the EJB Command Pattern: The commands are provided with access to their environment such as session data, references to application components they require. Therefore, the Local/Dispatchable Command Pattern is not dependent on a web environment and the application components do not have to have EJB implementations to provide remote access to the clients. It also allows the use of local commands for business logic that don’t require the transactional features of EJB or that don’t need to incur the overhead of dispatching to another container, for example
· presentation preparation logic
· simple non-transactional functionality
· altering local session state
· as a client to Web Services
In scenarios such as this, some developers may feel that a call to an EJB container is overkill. Indeed, it is also possible that the architecture of certain projects dictates that business logic is executed within the local context with the EJB container being reserved for domain logic. It is likely that particular applications will lean more towards the usage of one or the other type of command.
The Local/Dispatchable Command Pattern is not concerned with which type of command to use in a given situation but rather with allowing the developer to decide which execution context best suits their needs. Local and dispatchable commands are intended to be mixed in the same application and are not mutually exclusive.
The pattern provides two command interfaces that can be used to execute different types of application logic. The dispatchable command is executed in the normal way through a stateless session bean command executor. A local command is executed by a local command executor that cuts out the need for a remote call to the EJB container.
The LocalCommandInterface provides an execute() method that is run in the Local Context. The CommandContext parameter provides access to the command environment such as session-specific information unique to the user executing the command.
public interface LocalCommandInterface
public void execute(CommandContext commandContext);
The Dispatchable command interface provides three methods, initialize(), execute(), and postExecute(). The initialize() method is executed in the Local Context and is used to perform any tasks that are required prior to execution, for example the gathering of session information that is only available in the Local Context and that is required for the execute method to perform its task.
The execute() method is where the core business logic of the command is contained or where the command would access domain logic contained elsewhere in the application layer. It is run on the EJB server once the command has been transferred there.
The postExecute() method is run after the execute() method has completed and the command class has been returned to the context from which it originated. It should be used to perform any cleanup work required, any error reporting, or any extra view preparation that is required before the response is sent back to the user.
public interface DispatchableCommandInterface extends CommandInterface, java.io.Serializable
public void initialize (CommandContext commandContext);
public void execute (ModelUserSession modelUserSession);
public void postExecute(CommandContext commandContext);
In summary, the Local/Dispatchable Command Pattern attempts to offer the developer a greater degree of flexibility when they design their application. It allows them to code for different deployment scenarios and different trade-off decisions based on performance versus robustness considerations.
This pattern is implemented in the Xyrian Development Framework, for more information see : http://portal.remoteapps.com