Discussions

J2EE patterns: EJB Command Facade

  1. EJB Command Facade (10 messages)

    I was inspired to record this variation after getting my hands on a copy of Mr Marinescu's excellent "EJB Design Patterns". Having reviewed the IBM version of this pattern at http://www-106.ibm.com/developerworks/ibm/library/i-extreme13/ I recognise that there are features in common, but I feel that there are enough unique features to make this worth presenting.

    The primary aims of this variation are to address the tight coupling of client to the commands and ensure that the logic previously floating with the commands is localised to the session layer (making it more like a session facade pattern) and to simplify grouping commands under one transaction.

    This pattern can aid the development/maintenance effort greatly, allowing logic changes to be made to commands without requiring a redeployment to the client. It does not completely prevent any redeployments occurring since the commonality implicit in DTOs (Data Transfer Objects) is still present. If you really wish to minimise redeployments, you can always go to using HashMaps instead of DTOs... not to my taste.

    The core of this variation is to use a command class which does not contain the execution logic - the logic is stored in a session-facade like layer. The command class as in EJB Command can be routed to different execution locations, but in the case of EJB execution it is routed to a CommandHub for distribution to CommandCOnsumers.

    I use a root command class looking like:

    public abstract class Command implements Serializable
    {
    private String _commandName;

    protected Command(String commandName)
    {
    _commandName = commandName;
    }

    public String getCommandName()
    {
    return _commandName;
    }

    public execute() throws CommandException, ...;
    }

    Early in the development process I use a generic command class looking like:

    public class GenericCommand extends Command
    {
    private Serializable _dto;

    public GenericCommand(String commandName, Serializable dto)
    {
    super(commandName);
    _dto = dto;
    }

    public Serializable getDTO()
    {
    return _dto;
    }

    /* Unlike Floyd's example of the EJB Command pattern I like to
    ** use the Execute method signature as a command that the client uses.
    ** The exact implementation details are up to you, but I have my own version
    ** of a client side routing framework if I need to decide between execution
    ** locations.
    */
    public execute() throws CommandException, ....
    {
    ...
    someRoutingStructure.executeCommand(this);
    ...
    }
    }

    This can give simple rapid prototyping and can be taken into a production system but can reduce maintainability.

    Later on when your commands have stabilised and you want to increase type safety you can replace the command with a more specific command type.

    public class insertCustomerCommand extends Command
    {
    private CustomerDTO _customer;

    public insertCustomerCommand(CustomerDTO customer)
    {
    super("insertCustomer");
    _customer = customer;
    }

    public CustomerDTO getCustomer()
    {
    return _customer;
    }

    public execute() throws CommandException, ....
    {
    ...
    _customer = (CustomerDTO)someRoutingStructure.executeCommand(this);
    ...
    }
    }

    Though if the generic handler was used earlier in the development process, it would mean going through the already written CommandConsumers and replacing the generic command handling. You can potentially make the specific commands extend the generic command class, but I personally prefer not to do that as I feel that the time spent revisiting the CommandConsumers can be an effective part of refactoring earlier work.

    Factories to produce commands can be easily written.

    The next step on the EJB container is the implementation of what I call a CommandHub EJB which is the eventual destination of any client side EJB routing, it is an extremely simple and highly reusable stateless class. In a lot of situations, Command.execute() could be written to address directly address the CommandHub EJB.

    public interface CommandHub extends javax.ejb.EJBObject
    {
    public Serializable routeCommand(Command command) throws CommandException, RemoteException;
    }

    The implementation of the routeCommand method in the bean goes something like this assuming EJB2.0 and local interfaces:

    public class CommandHubBean implements javax.ejb.SessionBean
    {
    ...

    public Serializable routeCommand(Command command) throws EJBException,
    CommandException
    {
    ...

    try
    {
    // The command names are mapped to actual command consumer beans
    // in the ejb-jar.xml file, this makes it quite simple to switch
    // which command consumers handles a command without any recoding and
    // without expending effort on a homebrew solution.
    CommandConsumerHome cch =
    (CommandConsumerHome)lookupFactory.getInstance().lookup("java:comp/env/ejb/" +
    command.getCommandName());
    return cch.create().handleCommand(command);
    }
    catch (CommandException ce)
    {
    throw ce;
    }
    catch (Exception e)
    {
    ctx.setRollbackOnly();
    throw new CommandException(e);
    }
    }

    ...
    }

    All command consumers are stateless and use these local interfaces:

    public interface CommandConsumer extends EJBLocalObject
    {
    /*The return on this method is what is returned (eventually) to
    **_dto in the Command.execute() method.
    */
    public Serializable handleCommand(Command command) throws CommandException;
    }

    public interface CommandConsumerHome extends EJBLocalHome
    {
    public CommandConsumer create() throws CommandException
    }

    The actual implementation of the command consumer is dependent on the commands that you are expecting it to handle, but it is important that the command consumer should validate the command name passed and the dto payload and give sensible feedback should an invalid command be passed to it. The CommandHub bean uses the CommandConsumer interfaces as its local ejb interfaces allowing local routing to occur. On the CommandHub the handleCommand/routeCommand methods must have the trans-attribute set to 'supports', this allows multiple commands to take place in the same transaction.

    The logic of the command is located in the bodies of the command consumer beans, thus the command transaction settings can be set on the command consumer session beans. We can now easily write command consumer beans that can themselves issue 'commands' via the CommandHub as part of an overall transaction using the local interfaces.

    Another possibility is to write command consumer beans using similar code to the hub, allowing us to implement a decorator pattern - the hub passes a command to a command consumer that does something useful like logging or applying a transformation, before passing the command to another command consumer and so on.

    This variation addresses certain of the issues of the EJB Command pattern and adds new capabilities while weakening compile time checking and adding burden in maintenance of ejb-jar.xml files.

    Threaded Messages (10)

  2. EJB Command Facade[ Go to top ]

    Why there should be one more inderection level ?
    The command is already some self-described entity that could be executed direct
    in the container context or mapped whatever you wish with jndi help.
    Personally I like more the blueprints html-action/event/ejb-action approach.
    But why not , anyway there are millions of variants of such stuff.

  3. EJB Command Facade[ Go to top ]

    I like this pattern a lot, coincidently I have been toying with the Command pattern recently and have come to a similiar solution. What I particularly like in your solution is the command execute method acting as a router or local implementation as required. I went off in a non-OO direction by having a "CommandProcessor" singleton on the client which received a command (name & DTO only) and decided where to send it (i.e. to a local or remote implementation) but I prefer your OO solution. I guess the router could be implemented in the GenericCommand.execute method and re-implemented if required. On the "server" side I used the same solution.

    I actually started with the problem of designing a framework that could function both synchronously and asynchronously. Therefore I built the equivalent of your CommandHub as a singleton that could be accessed by both a StatelessSessionBean and a MessageDrivenBean. Additionally, I placed toXML / fromXML methods on the Command object so that I could send the command via an XML message bus (in our case MQIntegrator routes faster with XML than serialized data).

    I also added a validate method to the Command object to enable validation to be performed on the client. In fact I have found another message on this site "Validation of Data Transfer Objects" which has a great pattern for this.

    My only concerns though are that for performance I implemented the CommandConsumers as standard Java classes and therefore lost declarative transaction, security, etc. I guess a balance needs to be struck between putting together a reusable framework with the drawback of extra levels of indirection, versus a more performant but more labour intensive design.
  4. EJB Command Facade[ Go to top ]

    Sounds like an interesting framework you've put together there, it's amazing how much variation that there can be around the Command pattern.

    My 'GenericCommand' class a lot in common with your name and DTO approach and it is feasible to use my Command Pattern variation without ever strengthening up the typing.

    I've used something similar to the Validation of DTO approach (Just looked at the posting! I think I'll add a quick comment this afternoon.), especially with asynchronous processes, but I think that you have to be extemely careful about what validation goes on.

    You performance concerns are why I really only put this pattern forward with EJB 2.0 in mind, by being able to use local EJB references I can still get all the nice declarative stuff while not sacrificing too much performance.

    What do you think about using the JNDI lookup to help handle the routing logic in the CommandHub classes?
  5. EJB Command Facade[ Go to top ]

    Q: What do you think about using the JNDI lookup to help handle the routing logic in the CommandHub classes?

    Well I have been round the loop several times on this one and can't say I've come to a conclusion. I'm hoping to get some time to do a rough and ready performance comparison between using standard Java classes and Session Beans (via Local Interfaces) for the Command Consumers. The pros and cons (shown as + / - below) I have worked out though are as follows.

    Standard Java Command Consumer
    + Light weight, more performant
    + Can easily migrate code from non J2EE applications
    - No declarative transactions, security, pooling, etc.
    - Less scalable, can't distribute to seperate JVM / server

    Using Session Beans reverses the + / -. Also I'm not sure whether holding the CommandConsumer references within the CommandHub could improve performance - obviously you'll have to set up a pool of some kind and make sure the Beans don't get removed from their instance pool - could get too complicated.

    P.
  6. EJB Command Facade[ Go to top ]

    I tend to cache the Home interfaces and create remote or local instances as necessary. Not as immediate as pure java but, as I use moderately coarse grained commands, the overhead on using EJBs becomes less significant versus the benefits. Code migration isn't normally an issue in a lot of the work I do, so I don't often take it into account.

    Please let me know what you conclude on this and why, it's always interesting to see where different design decisision are applicable.

  7. EJB Command Facade[ Go to top ]

    Are any of you distributing example code ?
    Would you be interested in doing so ?
  8. EJB Command Facade[ Go to top ]

    I've been working with the Command Pattern, too, and have come to similar conclusions.

    I've been similarly concerned about tight coupling and re-deployment issues when your client-side commands include server-side logic.

    My project has ended up with a Generic Service Interface which uses DTOs to pass information back and forth and to identify the business logic to be executed.

    public interface Service {
        public Reply invoke(Request request);
    }

    Request and Reply are (interfaces for) DTOs to pass information to and from a service. In my implementation, Requests identify the actual service to be invoked and I've a generic server-side service instantiating (via a factory) and invoking the appropriate concrete services. This generic server-side service seems to be somewhat similar to your CommandHub and Paul's CommandProcessor.

    I'll have to look at using Command for packaging requests, dispatching the business logic execution, and unpackaging the reply: this would allow to realize the benefits of using Command on the client-side and still get ride of the re-deployment issues.
  9. EJB Command Facade[ Go to top ]

    Hi Robert,

    This comment maybe comes one year to late. Hopefully there will still be somebody interested in commenting...

    I am currently architecting a new application and I need to choose between the classical ‘Business delegate + Session façade’ or ‘EJB command’ pattern. In my opinion I prefer the former one, for being more flexible and maintainable. Nonetheless, I am currently doing some research in EJB command pattern variations that may make me change my opinion (and this is how I have come across with your pattern).

    As far as I believe, the main benefits of the original EJB command against Session Façade are:
    1) uses lightweight classes for business logics, instead of using EJBs (thus speeding up initial development + making it easier)
    2) encapsulates the EJB API from clients (although this is not a problem if we use Business delegate).

    The main problems are:
    1) you do not have transaction control (isolation level and transactional attributes),
    2) only generic error handling (ie no specific exceptions and no exception checking)
    3) you have hundreds or thousands of fine-grained classes, and usually for each screen (Select-Add-Update-Delete) you will have a minimum of four classes. This is clearly a maintenance problem.
    4) you need to deploy classes with business logics in both client and server environment

    What I am not so sure about your solution is to use an EJB for each command (correct me if I understood wrong). This is not only against once of the main benefits of the original EJB command pattern (number 1 above), but it also means that you will have to multiply the number of classes by 4, and of course you will have thousands of small/fine-grained EJBs that will put an enormous strain in your application server.

    On the top of that, this pattern only overcomes drawback number 4 (business logic), but by doing so, it seems to me as if your command objects are a type of ‘Business delegate’ object, and your CommandConsumer EJBs attempt to resemble the EJB layer of the Session Façade pattern.

    Why not to use the ‘Business delegate + Session Façade’ in the first place?
    What are the benefits of this pattern over the 'Business delegate + session facade' pattern?

    Hopefully you will be able to post your impressions after one year of using this pattern...

    Thanks

    Eduard

    PS: Robert please don't take offence by my criticisms of your pattern. I am just trying to get into a 'healthy' discussion.
  10. EJB Command Facade + transaction[ Go to top ]

    1)
    Actually, it is possible to have transaction with EJBCommand pattern. All you need to do is to write a methods separate transaction settings in the EJB which execute the command classes.

    EJB.execute() {
        // (1) look at txn setting - can be read from some config
        // (2) have a local interface to the same bean (or diff bean)
        // and execute the command class
    }

    EJB.executeTxnRequired(EJBCommand cmd, ...){}
    EJB.executeRequiresNew(EJBCommand cmd, ...){}
    EJB.executeNotSupported(EJBCommand cmd, ...){} ...

    3)
    Depending on how you write each Command,
    you can write one class with four methods and redirect in
    the execute method accordingly or you can write 4 classes
    each with each function: add view delete modify
    Whether which class the request is mapped to which request
    will depends on the factory inside the EJB Command server.

    public class CustomerCommand implements EJBCommand{
        private void add();
        private void view();
        private void delete();
        private void modify();
        public void execute(Param p) {
             int condition == p.getCondition();
             if (condition == ADD) {
                 this.add(p);
             } else if (condition == DELETE) {
                 this.delete(p);
             } else if (condition == VIEW) {
                 this.view(p);
             } else if (condition == MODIFY) {
                 this.modify(p);
             } ...
        }
    }

    my 2 cents of comment
    CL
  11. EJB Command Facade[ Go to top ]

    Eduard,

    Thank you for reading my pattern and commenting on it.

    As with all these things, there is no real answer to which is the 'best' solution. I tend to look at the problems presented by the project and select solutions accordingly. I have now seen a lot of projects where all patterns are perceived as 'good' and used without regard to their appropriateness.

    Having used both patterns, I can only say that they each tend to fit certain business contexts more naturally. When one can identify a clean set of clear business objects with a simple grouping of methods - Business Delegate and Session Facade are very good. In other situations I have found that there are no business objects that coherently group the methods and it makes much more sense to model them as commands.

    In defence of what I have written above - I would ask you to look a little more closely at it. The rapid prototyping is still available as you do not need to use EJBs to execute the commands. You can overcome drawback 1 by using the EJB per command.

    I also comment that I tend to use much coarser commands than most people using the command pattern so I tend not to end up with the situation you describe.

    In fact if I were to end up with thousands of commands or indeed thousands of methods exposed on the session façades I would query the modelling... You would likely end up with a very chatty application sending a lot of requests across the network.

    To achieve the coarse commands, I sometimes break the underlying behaviour down into classes that contain common behaviour that is used by several commands - indeed suborning some of the aspects of the session façade pattern for my own ends.

    Hope this makes sense,

    Bob Boothby