服务层（业务模型）应围绕主要实体（数据模型）进行设计。例如，UserService对于User，ProductService对于Product，OrderService对于Order，等等。你绝对不应拥有一个庞大的服务类。那是极端紧密的耦合。

对于服务层API本身，Java EE 6提供了EJB 3.1作为服务层API。在黑暗的J2EE时代，很久以前EJB 2.0难以开发时，Spring经常被用作服务层API。如今，有些人仍在使用它，但是由于Java EE 6结合了从Spring汲取的所有精彩经验，所以它变得多余。注意，EJB（和JPA）在诸如Tomcat之类的准系统servlet容器中不可用。你需要在其之上安装例如OpenEJB（或仅升级到TomEE）。

无论选择哪种服务层API，最好都是通过在服务层中完全执行业务作业来使JSF支持bean（动作）侦听器方法尽可能地简洁。请注意，服务层本身不应具有任何JSF依赖关系。因此javax.faces.*，服务层代码中的任何（间接）导入都表明设计不良。你应该将特定的代码行保留在备用bean中（通常是根据服务调用结果添加面部消息的代码）。这样，服务层可用于其他前端，例如JAX-RS甚至普通的servlet。

你应该了解，Java EE应用程序中服务层的主要优点是容器管理的事务的可用性。@StatelessEJB 上的一个服务方法调用有效地计为单个DB事务。因此，如果@PersistenceContext EntityManager在服务方法调用使用的任何DAO操作之一期间发生异常，则将触发完整的回滚。这样，你最终将获得一个干净的数据库状态，而不是一个脏的数据库状态，因为例如第一个数据库操作查询成功，但是第二个数据库查询没有成功。