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
