Discussions

J2EE patterns: The Local/Dispatchable Command Pattern

  1. The Local/Dispatchable Command Pattern (3 messages)

    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.

    Local Command:
    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
           extends CommandInterface
    {
        public void execute(CommandContext commandContext);
    }

    Dispatchable Command
    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
  2. You're touching on an interesting topic here. One of the points I don't particularly like about Struts is e.g. the fact that their actions are so tightly coupled to the servlets API. That's why we've also added an intermediate Command pattern/layer in our frameworks (see http://www.tuple.be/solutions/solutions.html), similar in goals to what you mention.

    I also agree that the framework should be flexible as to where the commands are actually executed: e.g. in the servlet engine context (or locally in any application context), or in a remote context (e.g. a remote EJB application server).

    However, I don't think it is optimal to provide two separate command interfaces for this. We've implemented this with one common Command interface (that should always be serializable) and an extra interface such as:

    public interface CommandHandler {
       public void handleCommand(Command aCmd);
    }

    This one is then implemented by e.g. a LocalCommandHandler
    and a RemoteCommandHandler. The remote one must then be initialized correctly to send the command to the desired remote controller.

    This permits a clean reuse of command code, and a clean decoupling of responsibilities.

    Kind regards,

    Erwin De Ley (erwin dot de dot ley at tuple dot be)
  3. The reason for defining two separate interfaces for local and dispatchable commands was principally concerned with whether or not the command contains logic which should be executed in the EJB container. While dispatchable commands can be guaranteed to have access to the full services of a J2EE application server, local commands are never dispatched to the EJB container and cannot really be guaranteed to have access to anything other than a J2SE environment. The type of the command therefore defines the kind of logic which is contained in that command therefore giving a clean seperation between presentation logic and business or domain logic.
     
    You mention the concept of a command handler which we use as well, however our command handler is designed to chain together command classes (both local and dispatchable) as well as to configure various variables according to the commands XML deployment descriptor. I didn't really want to cloud this pattern by outlining our entire execution Framework

    Richard Hill
  4. You might want to look at another message in this discussion list, Robert Boothby's EJB Command Facade. It is very similar but gets around the Local/dispatchable command issue by having a "router" on the client.