Place business transactions in commands. The commands become standalone objects that are completely independent of the bean itself. The bean just provides transactionality, security, distribution, etc. 

This aids in testing by reducing coupling. The commands can then be reused in other contexts. The same bean implementation can be reused for different sessions. For instance, if you needed a session with a longer timeout, custom access levels, or different transactional attributes, you just need to create a new bean with a different ejb-name in your deployment descriptor. 

Since all transactions use a single interface, this provides a good opportunity to use the DecoratorPattern. For instance, you can create and register a UnitOfWork at the beginning of each transaction and commit it at the end. See other examples at TransactionDecorators.

Here is the bean interface.	

public interface StatelessCommandSession extends EJBObject{

	public Object execute(Transaction trans) throws RemoteException;

}


--MikeRettig


-----

Yup.  I HaveThisPattern. I've done this at about a dozen customers -- including one where I refactored a design that had each Command as a separate EJB (imagine 200 stateless session beans...) into this design.  Check out the IBM Pattern Development Kit, which has a generic implementation of it.

KyleBrown

------

I agree.  I have used this pattern to design a simple Rules engine.  The Rules and Tasks are Java objects.  The Tasks (basically these are wrapped collections)are created based on the Rules for a particular type of process.  The executor of the Tasks and is a stateless session bean.  The Rules are loaded based on the strategy (Strategy Pattern) for the business process.

Raj Sankuratri