In a recent thread it was observed that the command pattern is typically implemented using dependent (ordinary Java) objects rather than as EJB's.
Although this is a good general rule, I have found on a number of occasions that the command pattern has a tendency to evolve into a strategy. This is typically due to the forces that act against a single method - before very long, there is a pressure to refactor into two or three methods. This can be either for configuration purposes (the command holds state) or because new discoveries have been made about the domain. For this reason, I have never been entirely happy about the command pattern - I see it as a special case of a strategy.
Anyhow, this has implications with EJB's, because the selection of a strategy often lies with the client (which might be another component) rather than with the component itself. One scenario is this - a client obtains one or more strategy implementations from a broker, and passes them to another component which performs its service using those strategies within its business flow.
As a result, I tend to be wary of using the command pattern as such in EJB's. I prefer starting on the assumption that it is a strategy. This allows me to narrow it to a command later if it is genuinely of this nature, or to expand it into a more componentised solution like the one outlined above if the forces lead in that direction.
I'd be interested to here other peoples opinions or related experiences...