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的实现的其他优点。