与 Jim Marino 谈 Fabric3 1.5 版的发布

Fabric3 ，一款新的服务组件架构（SCA）的开源实现，最近发布了其1.5 版。

该版本基于已经实现了 OASIS SCA 组装规范 V1.1 的 1.4 版本之上，在此之外还提供了以下新特性：

• 改进的集群支持，包括跨集群对部署的回滚以及对等部署。
• 深入与 WebLogic 10.3 整合，包括支持 WebLogic 集群、JMS、自优化的线程管理、JMX、事务和自动数据源发现等。

InfoQ 有幸采访了 Metaform Systems 的创始人暨 SCA 规范的功臣 Jim Marino。

InfoQ：您能从解释为什么我们需要 SCA 开始吗？我们已经有 J2EE、.NET、Web 服务、REST、JMS 等，为什么我们还需要另一种规范 / 实现呢？

JM：整体上说，SCA 让分布式应用的编写更为简单，并且它让之前难以实现或不可能实现的很多能力成为现实。SCA 是使能并管理分布式应用的基础。因为这种说法相当模糊，所以我将尽力通过解释 SCA 与你所提到的那些技术之间的关系来让这种说法具体化。

首先，SCA 与 Java EE 的关系是多方面的。SCA 与很多 J2EE 的 API（如 JPA 和 Servlets）配合得相当好。举例来说，我们在 Fabric3 中提供了实体管理注入、持久上下文管理以及基于 Hibernate 的透明事务管理的集成。Hibernate 与 JPA 是 Fabric3 中访问关系型数据的最流行的方式。

从编程模型级别，SCA 提供了与 EJB 以及其他编程模型等之外的又一选择。由于这些编程模型都是围绕依赖注入而设计的，所以他们没有本质的差别。但是，SCA 的编程模型特别注重异步编程以及为更好地处理远程服务调用而提供的便利。而且，SCA 规范小组还正要增加一项支持，也就是将发布订阅模式直接加入到该编程模型中。我认为它的加入将带来很多重要的附加能力。

SCA 还带来了 J2EE 和其他技术不具备的关键特性——装配和策略。装配是一种通过本地或异地的服务构建应用系统的方式。这一点非常类似与 Spring 的应用上下文，它是一种连接应用程序不同部分的方法。然而，不同于 Spring 的应用上下文，装配可以是分布的，而且可用于描述跨应用的连接。装配带来另一特性是模块化。在装配中，服务可由其他服务组装而成。这使得开发者可以在低层次的模块化系统（如 OSGi）之上设计模块化应用架构。

装配的确很强大，它不仅能描述单个应用的组合，还能描述企业内的一组服务，它们可以是细粒度的服务也可以是非常粗粒度的服务。我们使用 Fabric3 中的该特性对装配进行分析，确定服务的中间件需求，并且动态地提供相应的运行时基础设施。它还可用于依赖分析，从而能确定哪个客户端在使用服务， 或者 SLA 是否满足。由于分布式系统已发展成含有数千计的服务，所以由装配提供的信息将更好地用于这些服务的管理。

SCA 提供的另一关键特性是是跨应用的策略。SCA 提供了定义诸如安全类型以及 SLA 等的策略的能力，这些策略能够跨应用系统使用。其他编程模型一般都需要开发者为每个端点配置策略，这件事可能非常复杂、容易出错而且繁重。SCA 使得策略只需一次定义，却可以通过“推”或“拉”的方式得到重用。“拉”的机制可以通过在 Java 注解（Annotation）中引用策略别名的方式开启。“推”的机制可以理解成是一种“分布的”跨语言的 AOP。通过这种机制，人们就可以定义策略和基于 XPath 的查询表达式，查询表达式在装配过程中被解析并决定在何处应用策略。该机制的一个例子是“为所有部署的 Web 服务端点开启 X.509 认证”

上述这些表明，SCA 的确利用了很多现有技术。Web 服务（或更具体点，WS-*）用于提供互操作性。这对于需要向外暴露的 SCA 服务而言非常重要，比如用.NET 编写的客户端。JMS 可用于服务间的消息传输，它对于需要可靠性的场景非常重要。Fabric3 还使用 JAX-RS 为 SCA 应用提供了一个 RESTFul 的门面。

我把.NET 放在最后说，因为它与 SCA 的关系是最有意思的。不同于 J2EE，SCA 被设计成跨语言的。Windows 通讯基础（WCF）是.NET 使用的基于服务的编程模型，它是由类似于 SCA 的需求发展而来的。换句话说，微软希望创建一个适用于创建分布式的，基于服务的应用需求的简化的编程模型。如果将 WCF 服务与 SCA 组件做个比较的话，你会发现他们非常相似。事实上，二者的大多数概念都能直接映射。

然而，.NET（更具体地说是 WCF）所缺乏的是装配的对应。目前，WCF 的服务视图是非常“自治的”，它们是孤立地创建，配置和部署的。SCA 的装配可用于组装 WCF 服务。事实上，我觉得从 SCA 的角度，“微软比其他基于 Java 的（支持 SCA 的）提供商做得更好”的说法并不牵强。他们有 CLR，它是跨语言的而 JVM 却不能。此外，.NET 是应用开发的一款非常完整的端到端平台。如果.NET 版的 SCA 被开发出来，它将可能成为比基于 Java 的平台更完整，更完善的选择。

当然，另一方面，SCA 装配代表了现有.NET 产品不具备的一项创新。微软对此的反应值得关注。

InfoQ：您能描述一下 Fabric3 中都支持哪些 SCA 规范呢？下一版还会有什么？

JM：当然可以。Fabric3 当前支持 SCA 装配、策略、Java，Web 服务绑定、HTTP 绑定和 JMS 规范。

我们正在做的并将在下一个版本中发布的两个关键特性是对消息传输（发布 / 订阅模式）及 Spring 的支持。前者将使得使用 SCA 创建基于事件的架构成为可能， 而且将复杂的事件处理集成到应用中也会更加简便。我们在金融服务行业中的很多用户准备利用这项功能更进行市场数据分析。对 Spring 的支持使得 SCA 能够把 Spring 的 Bean 连接到远程服务。

我们还对运行时设计有很大投资，让其利用虚拟和基于云的环境所带来的优势。不同于很多“遗留”中间件提供商，我们不对现有中间件进行改造使之适应这些（遗留）环境。而是向前看，我们关注与 Amazon EC2 设施的集成，比如用于基于消息的服务连接的 SQS 以及非基于多播的集群。

InfoQ：除了 SCA，Fabric3 还提供了那些特性？你是如何针对这些特性作出决定的。

JM：Fabric3 提供了一组通常可以在商业中间件产品找到的特性，包括：

• 集群。Fabric3 包含非常简单的集群配置，支持多集群拓扑和向集群节点的自动添加应用程序和运行时资源。
• 可靠性。Fabric3 支持分布式事务和恢复（我们依赖于 Atomikos，它是一款很优秀的产品，我们非常推荐它），并且支持基于补偿 / 记忆模型的可靠部署 。
• 可移植性。Fabric3 有一个很小独立服务器，它可以寄宿在很多应用服务器（如 Tomcat）之中。我们最新版提供了对 WebLogic 服务器的支持并使用了一些高级特性，如自调优的线程管理和集群交互。Fabric3 甚至嵌入了 Ant 和 Maven 运行时。我们重点关注的是让应用程序可以不需任何修改就可以部署到这些环境中。

可以说以上这些特性都是企业级软件所需的。Fabric3 还提供了很多创新的特性，包括动态连接与策略。应用程序能够在不影响服务中正在发生的交互的前提下被更新或重新连接。另外，如 SLA 策略可以在服务部署之后被“添加”到服务之上。

Fabric3 可以配置成自动根据应用程序需求提供运行时扩展。举个例子，Fabric3 能够发现一些服务使用了 Hibernate，并在服务部署时自动向集群节点提供 Hiberenate 运行时扩展。该过程是完全动态发生的，根本不需要重新启动服务器。类似地，当一个应用被卸载时，如果其扩展在节点上不再需要时，服务器也会自动移除它。

我最喜爱的特性是运行时扩展。Fabric3 是围绕模块化内核而设计的，在内核中，诸如对远程传输和事务的支持这样的能力都是以扩展的方式加入的。有趣的是这些扩展实际上并未“超出”SCA 的范围。我们对运行时进行了设计使其成为一组 SCA 服务。Fabric3 有一个很小的启动程序，它读取 SCA 装配图，并连接服务与创建运行时。这意味着运行时是在编写 SCA“应用”并将其部署到特定的运行时域时被扩展的。正因为如此，动态更新运行时才成为可能，它基本上等同于部署一个终端用户的应用

一旦我们完成了对事件的支持（在 Fabric3 中源码中有一个初级的实现），我们将能够创建并利用时间流的运行时。到那时，就能实现对运行时事件执行复杂的事件操作和让 Fabric3 根据各种环境条件进行调节。

InfoQ：你能把 Fabric3 与其他流行的 SCA 实现做个比较吗，如 Tuscany？

JM：Tuscany 项目在帮助 SCA 的采用方面做了一项很好的工作。一个标准有用多种实现（特别是多个开源实现）是件好事，因为这为用户带来了更多选择，而且还可以通过竞争来激发创新。

即便如此，我显然认为 Fabric3 有很多优势。这些优势已我前面提到的企业级特性为核心，如扩展性、动态连接与方便使用等等。Tuscany 由 IBM 领导，他们的业务模型通常是诱导客户购买基于开源软件之上的提供了企业级特性的产品。所以，他们的定位与我们不同，所以将来很可能也有不同的方向。

InfoQ：Fabric3 提供了与 BPEL 引擎的集成吗？你认为 SCA 与 BPEL 的关系是怎样的呢？

JM：是的，我们有一个商业伙伴正在使用 Fabric3 作为他们的 BPEL 产品的 SCA 平台。另外还有一个 Fabric3 的开发者正致力于与 Apache ODE 的集成， 但目前还不能用，因为此项工作目前还在进行中。

至于 SCA 与 BPEL 的更为广泛的关系，前者允许服务通过使用 BPEL 而创建。二者之间的集成有很多值得提及的好处。从 SCA 的角度看，它是的开发者可以使用 BPEL 语言去实现面向流程的服务；从 BPEL 的角度，SCA 提供了连接应用的一部分（这部分更适合于传统的编程语言如 Java）的便利的方式。举个例子，若没有 SCA，从 BPEL 访问 Java 代码必须要使用 Web 服务或私有的提供商机的集成机制。SCA 对此做了标准化，使得访问 Java 时免除了负担及复杂的 Web 服务，并提供了将 BPEL 和 Java 组件部署在一个单元的方法……

InfoQ：Fabric3 在自动部署方面有什么特别的特性。

JM：Fabric3 提供了一组高级的部署特性。如我前面提到的，Fabric3 可以跨多个集群向节点自动提供应用程序包，这也包括了依赖关系。此外，因为运行时是使用 SCA 创建的，所以还可以使用相同的机制为应用程序提供所需的运行时扩展（及其依赖）。

我们在 1.5 版中加入的另一有意思的特性是基于补偿的部署。如果某次部署失败，那么该节点就会回滚到其之前的状态。在 J2EE 中，由于部署单元几乎都是自治的，所以这并不是一个什么难解的问题。然而在 SCA 中，一个应用中的服务可能连接到另一个应用中的服务，维护运行时的一致性就颇具挑战了。例如， 如果一个应用部署失败，对另一应用中的服务所做的任何更改（如动态连接）都必须要取消。Fabric3 使用了一种基于记忆补偿的方法来回滚更改，其结果是运行时总能处在一致的状态。

InfoQ：Fabric3 的实现是如何解决负载均衡以及故障恢复的呢？

JM：Fabric3 中的负载均衡是在传输层处理的。对于 Web 服务和 POX，Fabric3 依赖于 HTTP 的负载均衡。对于消息传输，F3 依赖于消息提供者的能力， 如 JMS 的实现。

对与无状态服务，其故障恢复非常直接——Fabric3 对服务器进行集群所以不需要做什么特别复杂的事情。我们正在做的一件事是支持集群的单例服务。我们的目标是让用户能通过注解（annotation）和定制的 SCA 范围来指定集群的单例服务。

会话服务显然要复杂得多。我们所使用的 BPEL 实现依赖于数据库来复制状态。虽然然在我们掌控之中，但我们目前还没有实现基于 Java 的会话服务的故障恢复能力。

InfoQ：Fabric3 的实现中支持哪种版本控制？

JM：对于工件的版本控制，Fabric3 依赖于 SCA 的输入 / 输出（import/export）机制，它部分建立于 OSGi 之上。对于 Java 工件，SCA 支持 OSGi 的版本范围。对于基于 XML 的工件，如 WSDL 和 XSD，SCA 允许归档（被称为贡献 [contribution]）输入和输出名字空间（namespace）。如果一个贡献（contribution）输入了一个命名空 间，它将被匹配到输出了该命名空间的其他贡献（contribution）上。在输出贡献（contribution）中的在该名字空间下的工件会对输入贡献（contribution）可用。要为 XML 工件定义版本，版本必须要包含在名字空间的声明之中。所以，SCA 的输入 / 输出（import/export）机制是 OSGi 输入 / 输出特性的子集。

对于服务的版本控制，Fabric3 支持将一部服务部署到多个端点。还可以通过 ESB 仲裁的方式通过一个端点代理多个服务的多个版本。对于后一种方法我们做得不多，但是 Fabric3 的架构支持它。

InfoQ：Fabric3 提供了何些工具？

JM：没有直接的工具。然而，现在 Eclipse STP 项目在其建模工具中支持了 Fabric3 扩展语法。我们还打算在策略定义的支持上紧密合作。

我还应该提到 IntelliJ 所具备的对于 SCA XML 装配的很好的重构能力，如当类或其所在包变更时，在 XML 中的自动进行重命名。我认为这仅仅是一种“凑合用”的特性。因为我不知道 JetBrains 正在做某种具体的 SCA 集成工作，这可能只是某个优雅且通用的 IDE 设计中的一个用例而已。

InfoQ：如果用户向感受一下 Fabric3 你有和建议。

JM：从我们的例子开始并订阅我们的用户列表。我们的目标是建立一个使用Fabric 的有益且友好的氛围。

查看英文原文: Jim Marino on Fabric3 1.5 Release