《Real World Java EE Patterns》阅读笔记 01：服务门面

对于任何一种技术来说，好用和用好是两个不同的概念。《Real World Java EE Patterns: Rethinking Best Practices》（真实世界 Java EE 模式：重新思考最佳实践）就是教我们如何用好 Java EE 的一本书，也是目前市面上能找到的唯一一本，非常值得一读。前两章是一些概述性的文字，所以直接从第 3 章“Rethinking the Business Tier（重新思考业务层）”开始。这次是第 1 节“Service Façade (Application Service)（服务门面（应用程序服务））”的阅读笔记。

概述

本节的开头对 Java EE 中的服务门面进行了简介，下面是我的归纳。服务门面的作用是将独立且可重用服务的组合起来，其概念和门面模式差不多，只不过要加上一些 Java EE 所特有的东西。 它是一个带本地接口的会话 Bean（通常是无态的）。除非需要从 JVM 之外进行访问，否则不应当提供远程接口。它充当展示层和业务层之间的界限，其方法都由客户端调用，不应当出现门面之间相互调用的情况。任何客户端和门面间 的交互都属于业务会话，每次调用都启动一个新的事务，因此门面类需要带有 TransactionAttributeType.REQUIRES_NEW 注解。

策略

然后作者讨论了各种服务门面的实现策略，它们是本节的重点：

CRUD 门面

一个 CRUD 门面只是一个暴露的、事务性的 DAO。在 J2EE 时代，通常将服务门面的所有方法调用委托给后台的 DAO。EJB 3.0 本来就是 POJO，所以这种委托已经显得多余了。在 EJB 3.1 里，甚至连 EJB 接口都是可选的，例如：

?

1 2 3

@Stateless @TransactionAttribute (TransactionAttributeType.REQUIRES_NEW) public class BookService { //...

双视图门面

服务门面通常都由部署在同一个 ear 中的 Web 组件直接访问，但有时候也需要提供远程接口供外部客户端使用（例如使用 Swing 开发的 EJB 客户端应用程序）。这种情况就可以使用双视图：

?

1 2 3 4 5 6 7 8 9

public interface BookServiceRemote { //...   public interface BookServiceLocal extends BookServiceLocal { //...   @Stateless @Local (BookServiceLocal. class ) @Remote (BookServiceRemote. class ) @TransactionAttribute (TransactionAttributeType.REQUIRES_NEW) public class BookService implements BookServiceLocal { //...

SOA 门面

SOA 门面的一大特点就是异步，最容易想到的方式就是 JMS，但 JMS 消费者在对事务和消息类型的处理上有些微妙的问题，JMS 生产者和消费者之间不容易交互，而且部署和维护消息队列的成本也比较高。EJB 3.1 引入的异步调用则提供了一种轻量级的异步门面解决方案，简单自然地解决了这些问题：

?

1 2 3 4 5 6 7 8 9 10 11

@Stateless @Asynchronous @TransactionAttribute (TransactionAttributeType.REQUIRES_NEW) public class BookService {        public Future<Order> orderBook(Book book) {          //...          return new AsyncResult<Order>(order);      }   }

多通道门面

通过在门面上增加注解，可以使同一个门面以更多的形式暴露出来。下面代码中的门面不仅是一个 EJB，而且能够提供 SOAP 和 RESTful 的 Web 服务：

?

1 2 3 4 5

@Stateless @WebService @Path ( "book" ) @TransactionAttribute (TransactionAttributeType.REQUIRES_NEW) public class BookService { //...

IIOP 门面

这种门面主要用于和 CORBA / IIOP 兼容，例如可用于和老系统或者 .NET 客户端通信。在一般的 Java 开发中应该很少用到。

总结

虽然本节有很多理论性的东西，但实际上都是围绕 EJB 3.0/3.1 的新特性给 Jave EE 设计所带来的变革在讲。正如作者所说，J2EE 时代的诸多模式都是出于对规范的短处进行修补，而并非设计上的最佳实践。这让我想起以前从阿三手上接过来的一个项目，虽然使用 EJB 3.0，但充斥着 EJB 2.x 的“设计模式”，造成大量冗余的代码，甚至很多方法委托就是透传。我当时虽然觉得不妥，但也没有充足的理由反驳阿三架构师。看完本节，极有相见恨晚的感 觉。