Bobby Woolf写了一篇文章：How to Implement a Service in J2EE。他建议，假如服务使用同步传输（如：HTTP或RMI），就使用SSB（无状态会话bean）；假如使用异步传输（如：JMS或JCA），就使用MDB（消息驱动bean）。
“将服务实现为SSB的一个好处是，客户可以灵活地同步或异步地调用它。我已经讨论过对HTTP或JMS传输使用service activator进行异步访问的情况了。服务的java客户机可能希望同步调用该服务——这使用SSB很轻易做到，只需使用其本地或远程home和接口。所以SSB使服务调用非常灵活。”
很难不同意他的观点。将服务公开为由J2EE应用服务器托管的SSB和MDB确实是一个好方法，因为它会自动为客户机和服务提供者提供远程、事务性、入池、负载均衡、故障恢复等功能，尤其是假如您承担得起使用应用服务器的费用，就完全不必重新构建并花时间重新实现这些服务。
“有些人不喜欢EJB。也许他们使用的不是Java，而是.NET，他们使用.NET中与SSB等效的东西。又或者虽然他们使用的是Java，但不是J2EE，至少不是EJB。原则仍然适用，他们会使用JavaBean/POJO。若非J2SE对象需要处理安全性、事务、远程、入池，您就已经重新创造了EJB，所以使用EJB作为起点就可以了。”
所以在Java中SSB不是实现服务的唯一方法，但是假如您要利用J2EE，那么使用SSB是一个好方法。”
前些时候，当IoC（反向控制）容器开始流行时，引发了很多讨论。“基于POJO的设计缺少安全性、事务、远程支持等等”这种说法可能有些不实。这些都的确是横切关注点，而且与实际的业务逻辑没有太大关系。此外，这些独立的关注点不一定需要单元测试，而只需要集成测试。
依我来看，更灵活的取两者之长的方法是，只将EJB作为可能具有远程、事务性等功能的边界的Service Facade，而将实际的业务逻辑实现封装在由某种IoC容器驱动的POJO中。这样EJB代码就应该与下面的代码类似（使用了Xdoclet注释）：
PRivate RequestProcessor requestProcessor;
/**
* @ejb.interface-method view-type = "both"
* @ejb.transaction type = "RequiresNew"
*/
public String request( String msg) {return requestProcessor.submitSync( msg);}
其中，requestProcessor是由Spring托管的POJO。注重，该代码非常简单，其实不需要进行组件级的测试。
服务组件的连接方式如下所示：
注重，在容器外（例如，在独立的客户机中）还可以使用POJO组件，这尤其方便测试和调试。
上述方法在开发时具有几个优点。下表对EJB和基于POJO的组件开发进行了比较。如您所见，POJO使测试更为轻松，本例中EJB的整个更改/构建/部署/测试/验证周期大约是POJO的5~10倍，而且POJO的开发流程更具动态性。
我将在以后的文章中继续介绍基于POJO的实现的其他优点。
