BEA 发布了在 WebLogic 10.3 中支持的 SCA 技术预览版，它是以开源的 Fabric3 运行时为基础构建的。InfoQ 采访了 BEA Systems 的技术主管 Jim Marino，以及 VocaLink 的首席技术人员 Meeraj Kunnumpurath ，后者是 SCA 最早的参与者和 Fabric3 贡献者之一，并参与了 SCA 规范制定和 Fabric3 实现。
InfoQ：过去 10 年 SOA 有了长足的发展，你们如何看待软件工业向 SOA 方向的演变？
Meeraj：从最终用户角度来看，我们关心的是如何解决不断增长的复杂业务问题。 Vocalink 是世界上最大的银行同业支付服务提供商（interbank payment processors）之一。40 年来我们一直从事这个业务。今天，我们看到了许多商业机会，其中大部分在欧洲。这些新机会要求我们重用软件资产构建新的解决方案。我们认为 SOA 是使这些新的商业机会成功的关键。对我们来说，SOA 能使我们改进整体拥有成本和开发新的解决方案。
Jim：Meeraj 的观点有一定的代表性，我们发现用户在重用代码方面确实存在着困难。面向对象技术的引入显著地改善了应用内部的代码重用。然而，跨过程边界的代码重用有更多的问题。诸如 EJB 或 CORBA 这样的远程技术错误之处在于，试图将 OO 原则应用到进程间通信上。对于 SCA，我们为这一问题采用了完全不同的解决方法。SCA 为进程间调用引入了一个拥抱 OO 的编程模型，同时为远程操作所需要的异步、松耦合交互提供了便利。随着很多现有编程模型变得复杂，对于 SCA，我们力求编程模型在降低复杂性的同时通过组合（composition）来提供模块性。其中的组合是一个关键概念……
InfoQ：今天如何采用 SCA 呢？
Meeraj：我们期望看到更多来自厂商推广 SCA 的努力。在过去的 3~4 年间，SOA 已经演变成了一个构建解决方案的主要范式。但是在极大程度上，SOA 依旧是一组模式和最佳实践，有时难以实现。同时我们看到开发人员对基于容器的技术感到痛苦，并转而求助于象 Spring 或 Mule 这样的更轻量级编程模型。但是，这些技术依旧是私有的，它们会把你锁定到特定的技术和厂商。SCA 带来了一个新的轻量级编程模型，但是这次，它是基于标准的，锁定问题不再出现。在构建基于 SOA 的企业应用方面，SCA 提供了一组约定俗成的规范。
直到现在，我们的 SOA 实现还是基于 Spring 和 Mule 的。我们现在正向 WLS 10.5 迁移，而且利用了 SCA。在模块化、组合、策略增强和高度重用方面，它满足了我们的需要。对我们来说，这是一个极大的进步，这是需要被传播的技术，我们也愿意看到更多的来自厂商的努力。
Jim：我同意 Meeraj 所说的，在解释 SCA 是什么这件事上，我们做得不是非常好。即使它开始得到更多动力，但与早期围绕 EJB 所作的宣传相比，这个动力还很少。原因之一是我们现在还没有任何成熟的运行时。随着两个开源项目 Fabric3 和 Apache Tuscany 走向成熟，我们会看到更多人对这项技术发生兴趣。我也承认当今的技术环境不同了。新技术的普及速度更慢。总的来说，如果我们能小心地推进 SCA 的发展并避免匆忙地将技术投放到市场会是件好事。
Meeraj：我得说，只要新技术能解决问题，它们就会获益颇丰。例如，我们已经看到象 Spring 这样的技术正显现出一个巨大的市场。
InfoQ：说到新技术，OSGi 似乎也正成为一项重要技术，你如何定位 SCA 和 OSGi？
Jim：OSGi 是一项伟大的技术，而且 BEA 是它的一个强大的支持者。OSGi 和 SCA 可以是互补的。例如，一个 SCA 运行时可以运行在一个像 Equinox 或 Apache Felix 这样的 OSGi 容器中。但是，认识到 OSGi 并没有解决全部的模块化需求也很重要。为了给应用模块化提供更好的支持，SCA 提供了组合（composite）和部署单元（contribution）。我想稍稍多谈一些部署单元，因为它们是我们最近对 SCA 规范所作的一个主要变化。在 SCA 中，部署单元用来安装和共享应用部件。SCA 规定的互操作打包格式是 zip，如 Java 运行时中的 JAR。我们曾考虑过使用 OSGi bundle 的可能，但是我们没能那么做：OSGi 实际只考虑了单进程，单 JVM。SCA 需要处理分布式情况。此外，SCA 不限于 Java，需要处理非 Java 部件（如 WSDL 文档和 XML 模式）的共享。因此，我们认为我们需要开发部署单元这个概念，它负责分布式环境中的打包和共享。
SCA 部署单元机制的一个有趣方面就是它是可扩展的。这使得 SCA 运行时能支持 OSGi bundle 作为一个部署单元的打包格式。与之类似，一个 SCA 运行时也能支持诸如 WAR 或 EAR 这样的其他打包格式。
Meeraj：我们检查了 OSGi 和 Spring 动态模块。我们发现 OSGi 和 SCA 之间存在很多重叠。例如，SCA 提升（Promotion，译注：将组合内部的组件提升为外部可用的服务暴露出来）在 OSGi 中有等同的概念，SCA 部署单元也是如此。但是，据我所知，在 OSGi 中并没有等同传输层抽象和策略的概念，即使在企业 OSGi 中有一些关联的项目，但情况依旧。这些特性对于构建企业中间件来说有巨大价值。我们的经验是，SCA 真的使我们构建 SOA 应用的必由之路具体化了：实现 SOA 行话和模式变得简单，强调类型化的服务契约。同时，SCA 能使我们在将来自由地将我们的代码移动到不同 SCA 容器。
InfoQ：你们采用 SCA 的方法是什么？
Meeraj：我们正处于将应用从大型主机移动到中型服务器的过程中，使用 Java 环境。我们经历了两个不同阶段：首先使用重型技术如 EJB，然后转向更轻型的技术如 Spring 和 Mule。现在，就模块组合、策略增强、传输层抽象和异构联邦来说，我们正经历更复杂的问题。Spring 对我们帮助很大，但是 SCA 解决了比 Spring 或 Mule 更多、更复杂的企业软件工程问题。
在我们转向 SCA 时候，我刚刚参与 Tuscany。后来，在我开始从事 Fabric3 工作的时候，我担任了指导性更强的角色。这使得我们能更进一步了解这个技术。我们考虑在 2 个项目中使用 SCA。这是一个有见地的决策，因为我们参与了 OASIS 技术委员会和 Fabric3 项目。当然，我们还没有任何系统在生产，但是我们计划在今年第 4 季度发布这两个系统，这两个系统都在一个 J2EE 容器中使用了 Fabric3。
这些项目混杂着遗留代码和新写代码。绝大部分现有代码构建在象 Spring 这样的技术上。就迁移这些 Spring Bean 到 SCA 环境而言，基本上就是把它们找出来，然后给它们添加 SCA 注解。Fabric 3 也支持许多能将遗留代码作为 SCA 组件运行的启发式方法。那很简单。
Spring 允许我们完成依赖管理，这样我们就能在容器外运行我们的代码，然后改变配载在 J2EE 中运行。在 VocaLink，Spring 为使用更轻量级的编程模型奠定了基础。但是，我们发现 SCA 更好地解决了面向组件软件开发的复杂性。我们有一个关键需求必须用组件封装。我没有办法在把一系列 Spring bean 组装成一个组件的同时，将某些 bean 标识成是这个组件私有的。SCA 非常擅长管理这种区别，只提升组合（composite）中想给外部使用的那些 Bean，而将其他任何东西都留给组合私有。此外，SCA 策略对于强制 QoS 方面具有更多的表现力。SCA 意图（intent）抽象了那些能映射到运行环境中具体策略的需求。对我们来说，我们认为 SCA 以一种标准方式解决了很多过去用 Spring 解决的问题。而且，象 F3 这样的实现完全在无损轻量级开发模型和开发人员生产效率情况下做到了这一点。
Jim：许多的 BEA 产品正转向 SCA。我们正在 WebLogic 中支持通用的 SCA 能力。WebLogic Server 将 Fabric3 内嵌为第一级容器，与服务器包含的 JEE 支持的方式相同。这允许用户在 WebLogic Server 上安装 Fabric3 扩展，如绑定、策略，并支持不同的组件实现类型。它还允许用户创建自定义的扩展，它可被安装到任何内嵌了 Fabric3 的地方，无论是 WebLogic，还是其他服务器，如 Tomcat、Jetty 或一个基于 OSGi 的运行时。WebLogic Server 增加了诸如集群、管理、故障转移和可靠性方面的特性。我们还正在为开发人员和部署人员开发相关的 SCA 工具。
InfoQ：就松耦合和 SCA，你们能提供些看法吗？
Jim：SCA 的编程模型特意为促进松耦合而设计。在 Java 中，SCA 使异步交互、回调和会话成为了一等公民。如 Meeraj 之前所说，SCA 还提供了协议抽象，这样在远程调用时代码就无需处理低级的传输层 API。这就是某种形式的松耦合，它尽可能地移除了与传输协议有关的依赖。
但是，有趣的是，SCA 也支持更耦合的方式，本地交互。这是因为松耦合并不适于应用设计的所有层级。例如，处理远程异步交互一般就比处理同步本地交互复杂。通过它的组合概念，SCA 支持将更小的、紧耦合的组件装配成松耦合服务。这有助于促进应用模块化，因为服务由更小的单元组成，它们作为一个组合被一起管理。它还有助于减少复杂性，因为远程、异步调用可以被限制在应用的关键部分。
InfoQ：你们如何正视 SCA 中的管理和运营？
Jim：这一部分被认为是未来的工作重点。在 BEA 看来，我们看到 SCA 和装配模型极大地增强了管理，因为后者提供了描述运行时环境的统一方法，这些环境通常由不同技术组成。
Meeraj：在概念上，SCA 有两方面导致管理简化。域（domain）概念，如 Jim 所说的，它提供了一个统一视图。另一个重要的概念是递归。递归允许在域的更高层定义策略，然后将它们强制到内部所有组件实现和交互。Fabric3 在支持异构联邦域上花费了不少功夫。这样，SCA 为管理复杂互联系统提供了基础。但是的确，我们需要更进一步对有助于管理和运营的具体策略提供支持。
InfoQ：在采用 SCA 的过程中，你们遇到过什么困难？
Meeraj：缺少成熟的产品绝对算的上是一个，但是对于我们来说，SCA 是迈向构建 SOA 应用的重要一步。规范尚处于 1.x 级别，而且还会发展。参与者的背景很广泛，不仅仅限于厂商。在技术委员会中，我们提供和得到实践反馈，同时面对现实世界的问题：与规范中指定的场景相比，策略如何工作在某个确定的场景中。这是一个非常积极的工作环境。
InfoQ：SCA 的关键好处是什么？
Meeraj：通常说的，如果你想比较 SCA 和其他技术的话，它没有将你限制在特定技术之上。你可以使用不同的组件实现技术如 Spring、Java、BPEL、脚本语言等和各种传输机制如 HTTP-WS、JMS、RMI、Hessian、 AMQP 等。SCA 还为我们解决了范围广泛的重要问题：装配、组合、传输层抽象和绑定、意图和策略、域……SCA 为我们提供的仍旧是一个轻量级编程模型，但是解决了大范围的复杂问题。我们真的期望看到来自厂商更多的推广，帮助他们的客户拥抱这些技术。
Jim：SCA 的确是应用开发的下一阶段。SCA 代表了一些人们常常统称为“SOA”的具体步骤：重用、组合、策略管理和松耦合服务。SCA 最大的好处就是试图以一种比传统方法简单得多的方式提供这些特性。
Meeraj：SCA 不只是呆板地实现 SOA 典型视图：不是所有东西都是松耦合或是无状态的。在你应用的某些层级，你有紧耦合的细粒度组件，经常有有状态的会话，你需要的会话回调支持等等。SCA 谈论的是这些基于 SOA 的应用构建方式：递归地构建它们。SCA 的确代表了一组描述你如何构建基于 SOA 应用的规范。
查看英文原文： Interview: Jim Marino and Meeraj Kunnumpurath on SCA and Fabric3
评论