EJB Command
一个ejb客户端为了完成一个用例需要执行商业逻辑。
怎样让一个开发者用一个轻量级的态度实现一个用例的
商业逻辑，使客户端和ejb解耦并且用一个事务和一次
网络调用执行用例？
设计ejb系统时的一个重要的架构决定是把商业逻辑
放到什么地方？一个用例的商业逻辑是代表你的领域
模型中的合适的方法或跨多个其它entity bean 和/或
session bean执行逻辑(工作流逻辑)。
把商业逻辑放到客户端(servlet,applet,等等)有严重的
负面效果，影响性能和可维护性，如session facade
模式所解释的。问题可以被使用session facade模式
纠正，需要把商业逻辑放到session bean中，session
bean的每个方法映射到一个特定的工作单元，或者
用例。这样做，客户端被从服务器端的对象模型屏蔽
起来，并且在一个事务和一次网络调用的round trip中
执行用例。
session facade模式自己是ejb开发的关键，不过也有
它自己的缺点。直接从客户端调用session facade会导
致客户端和服务器之间的依赖(在一个大型项目和复杂的
客户端代码中)，因为对EJB的紧耦合，如Business
Delegate模式所讨论的。这些问题能被用 business delegate
解决，增加一个封装所有对ejb层的存取的对象层。business
delegate能帮助让客户端代码简单，使客户端和服务器之间的
依赖最小。
然后session facade模式和business delegate模式一起提供了
使客户端从服务器端的实现细节解耦并允许在一个网络调用
和一个事务中执行用例的格式下写商业逻辑的最好的实践。
和通常一样，有trade-off:
1.更慢的开发过程。因为用例逻辑(经常会变化的)在一个
session bean中运行，任何时候一个用例需要改变(就是，
增加一个参数到一个方法或返回一个额外的属性)，实现
那个用例的session bean方法可能需要修改。改变一个
session bean的过程不是可以忽略不计的----一个改变通常
需要编辑3个不同的文件(接口，bean class,deployment
descriptor)并且对ejb server的重发布和可能的重起服务器。
附加的，封装变化的session bean的在客户端的business
delegate将也需要修改。
2.大型项目中的劳动分工将更困难。依赖于一个项目中跨
开发者分配工作的策略，session facade是导致不同组或
开发者互相争斗的瓶颈，因为它将是随着项目进展时经常
变化的主题。
3.在一个大型公司中服务器资源经常被一个小组控制。
对一个有建立了的并且正在工作的发布的ejb集合的大型
公司，很难让其他项目的小组对已有的类施加影响和改变。
简单说，用session facade和business delegate开发会导致
长期的变化->发布->测试的round-trip,会成为大型项目的
瓶颈。问题的关键是商业逻辑放在一个session bean层，
几乎是重量级的开发。
综上所述:
使用Command模式来封装商业逻辑到轻量级的command
bean,使客户端从EJB解耦，在一个网络调用中执行，作为
EJB层的一个facade。
一个command bean只是一个有get,set和一个execute方法的
普通Java类，和最初的command模式(四人帮(gof),1995)描述
的一样。应用到EJB,Command模式为了达到和session facade
和business delegate相同的好处提供了一个轻量级解决方案:
一个隐藏ejb层的对象模型，在一个事物和一次网络调用中执
行一个用例，完成使客户端从ejb解耦的facade。command模式
通过提供本地交互的类达到这一点，不过实际上在一个远程
ejb服务器上执行，对客户端透明。
Command被用来封装应用程序中的单独的工作单元。比如
placeOrder,transferFunds,等等的用例，将有它的商业/工作流
逻辑封装在只为那个用例的特定的Command，如图1.7所示。
和一个command交互的客户端十分简单。一旦一个客户端得到
一个command(创建一个或从一个factory得到，取决于实现)，
