SCA 访谈

自从它于2005 年首次面世以来，SCA 已经广为人知。尽管许多分析师认为SCA 是一个好东西，但并非所有的评论都是正面的。最值得注意的事实是：它作为另一组闭门造车的规范出现，远离标准团体。但是，在2007 年情况发生了变化，此时 SCA 被捐献给了 OASIS 并且成立了OpenCSA 工作组，该组包含几个负责标准化SCA 不同方面的技术委员会。在9 月，伴随着OpenCSA 全体大会，举行了这些委员会的首次面对面会议。InfoQ 见缝插针接触SCA/OpenCSA 工作组的几个成员并询问了一些问题。

本次访谈中，我们与Mike Edwards（IBM）、Steve Jones（CapGemini）、David Burke（TIBCO）、Sanjay Patil（SAP）和Michael Rowley（BEA）进行了交谈。

Michael Rowley 在 BEA 的 CTO 办公室中致力于标准方面的工作。他目前是开放组合服务架构（OpenCSA）成员部（该部负责检查 SCA 和 SDO 的标准化）的 OASIS 指导委员会的 7 名当选成员之一。他是 SCA-J 技术委员会（负责 SCA Java 规范）的联合主席和 SCA Assembly 与 SCA BPEL 规范编者之一。

Steve Jones 目前是 Capgemini 全球 SOA 和 SaaS 外包业务总监，曾是负责他们与 Google 的合作伙伴关系（该关系最近刚刚启动）的全球产品主管。他是几个 JCP 工作组–包括最初的 JAX-RPC 组、JBI（1 & 2）和 JavaSE 6–的成员，Capgemini 的 JCP 成员关系执行发起人。Steve 还发起了 Capgemini 与 OASIS 的联姻，他在 OASIS 是几个工作组的成员，包括 SOA 参考模型和 eGov 工作组，并且最近代表 Capgemini 加入 Open CSA 工作组。他还是 InfoQ 书籍“企业SOA 实施策略”的作者。

Sanjay Patil 是位于 Palo Alto 的 SAP 实验室的标准架构师，他是许多标准团体（包括 OASIS、WS-I 和 JCP）的积极成员。他目前是 OASIS Web 服务可靠交换（WS-RX）技术委员会和 OASIS 服务组件架构 BPEL 技术委员会的联合主席。他的兴趣领域包括 Web 服务、SOA、组合技术和 Java EE。

David Burke 是 TIBCO Software 产品管理的主管，担任 OASIS OpenCSA 指导委员会成员，负责推动 SOA 规范的 SCA 和 SDO 家族。

Mike Edwards 博士是位于英国的 IBM Hursley Park Lab 的从事服务组件架构的策划师，目前是 OASIS SCA Assembly 技术委员会的联合主席。Mike 从事软件开发已有 25 年，曾开发 OS/2 图形表示管理器（Presentation Manager）、CallPath 计算机电话集成（Computer-Telephony Integration）、Java 和 Web 服务。

InfoQ：你们认为是什么原因使 SCA 花了如此长的时间才与标准团体接触？

Mike Edwards（ME）：我认为 SCA 与标准团体接触并没有花很长的时间。SCA 从一开始就致力于解决 SOA 领域的问题并抓住 SOA 领域的机会，它由一些合作者共同推动发展。这不仅涉及创建规范，同时还牵涉到实现，以检验规范并提供有用的反馈。唯有一旦规范成熟了，而且我们对规范被漂亮而可靠地实现有信心，把它进一步推向标准团体才有意义。时间就是现在。

Steve Jones（SJ）：我不能肯定时间真的是那么长。我记得 JBI 启动的时间大约与 SCA & SDO 的开始时间一致，因此鉴于 JBI 2.0 在 JCP 中刚刚开始，那么 SCA 现在光临并不见得时间太长。实际上，在 SCA 1.0 到达 OASIS 之前，BPEL 1.1 走过相同的道路。

David Burke（DB）：确实，从我们的观点来看，SCA 抵达标准团体的时间是非常及时的。相对于这个行业，SOA 是一个相当新的事物，相对而言 SCA 成为相关标准进展得相当快，例如，在 20 世纪 70 年代早期，查询语言就得到关注，但是直到 1986 年第一版的 ANSI SQL 标准才出现。同时有件非常有趣的事情必须被注意到，SCA 首先是作为合作与竞争（co-opetition）的产物出现，然后被移交到标准团体，我认为它是整个行业走向成熟的一个标志。

InfoQ：为什么选择 OASIS 而不是 W3C？

SJ：OASIS 比 W3C 更关注于业务和实现标准。SCA 是一个业务标准及相关实现，因此选择 OASIS 就显得更有意义。

ME：为任何规范选择管理它的标准团体都不是一件简单的事情。然而，SCA 主要关于编程模型而不是一个线上（on-the-wire）协议，而且我们觉得 OASIS 在该领域有良好的记录——例如 WS-BPEL 规范——并且 OASIS 也提供了一个构架，很适合 SCA 所需要的并行技术委员会组。

DB：当你看看两个组织内的标准活动之后，会发现 OASIS 更适合 SCA。OASIS 关注 Web 服务和业务级别的互操作，这非常适合 SCA 的目标。

InfoQ：为什么 SCA-J 没有在 JCP 内进行？

SJ：这是我们在 Capgemini 期望看到的方式。假如 SCA 成为将来 J2EE 规范的一部分，对我们以及我们的客户来说，是有意义的。当然，厂商之间存在有一些政治问题，关于这点认为每个人会开始变得成熟会好一些。

ME：作为一个整体的 SCA 并不是 Java 规范——它是包含了很多 Java 及非 Java 技术的 SOA 规范。将 SCA Java 规范与其它的 SCA 规范分离开来不见得有意义，而且还会使得该 Java 工作组和其它工作组之间的联络变得更加困难。这样也保持了所有 SCA 规范在一个单一的、容易理解的许可证下。

DB：在很大程度上，SCA-J 尽量避免描述 Java 代码运行的环境。围绕 SCA-J 服务是怎样运行的问题可能应该作为 JCP 过程的一部分完成。SCA-J 更关注 Java 服务如何消费以及如何被其它服务消费，这些服务可能由 Java 书写，也可能不是。然后，这个工作的小部分关注 Java 如何工作，以及它应该如何影响关于 SCA 做什么这一更大场景。从那个观点来看，SCA-J 团队需要确保 Java 开发者觉得编写 SCA 服务很容易。然而，该工作的大部分是关于如何将 SCA 装配及策略问题映射到 Java，并且从那个观点来看，SCA-J 团队确实正在关注如何将语言独立的符号映射到 Java，尽管那些语言独立的符号仍在发展中。这样，尽管有可能将 Java 特定工作作为一个可分离的部分（在 JCP 过程中），暂时将其看作一个单一标准组织中其它规范的对等体显得更有意义。

InfoQ：如果你们只能用两句话来概括 SCA 给该领域带来什么的话，该怎么说呢？

SJ：封闭式设计和部署。一种创建和打包复杂应用的单一方法。

ME：一门用于描述组合服务应用的语言。一种用于构造服务组件的简单方法，关注于业务功能并使基础设施关注点保持很好的分离。

DB：两个词怎么样？开发者智力共享。说得更详细一点，SCA 给开发者提供了一种基于标准的组合应用开发方法。

Michael Rowley (MR)：我将其描述为一种用于创建、装配和部署基于服务的应用的技术，使用多种语言和通信协议。我们最重要的设计原则就是技术应该尽可能的简单，即使它意味着为了简单性而牺牲一些功能（在功能和简易性两者冲突时）。

InfoQ：为什么你们的公司对 SCA 感兴趣？

DB：在展望下一代产品的过程中，TIBCO 发现内部的专有方法开始显得与 SCA 中的一些关键概念非常类似。一旦我们意识到这一点，沿着与其它人一起开发一组标准这条道走下去对我们来说就更有意义了。显然我们仍然关注这个标准的某些方面，在我们的产品有些工作要做以实现我们认为对客户有意义的那些规范。

MR：BEA 认为行业正在由纯 Java 服务器端应用转向一种模型，该模型中的应用使用不同的高层技术（如 BPEL、数据集成技术、XPDL、ESB 管线等）来建构。我们也认为用户希望这些将不同技术粘合在一起的组合服务能以 XML 进行声明性指定，而不是使用 API 和编程。然而，还是有许多关键叶级（leaf-level）服务用 Java 创建。SCA 使得有可能以一种标准方式去创建和部署这些混合技术的应用。它也提供了书写服务的 Java 编程模型，该模型没有限制用来在服务间进行通信的传输技术，它非常适合 SCA 的装配模型。

ME：我们相信 SCA 是使用 SOA 构建业务应用的重要构建块。它使得 SOA 更具消费性，而且它将创建一组公共的技巧，公司可以利用它们来构建自己的系统。

Sanjay Patil (SP)：我们同意以上说的，而且我们还想补充的是，我们认为 SCA 提供了一个适合集成现有运行时和部署技术（如 Java EE 和 OSGi）的框架。

SJ：我们为我们的客户构建和支持了大量的系统，这使得我们可以做得更好。我们在 SCA 的第一个 beta 版发布上就与 IBM 合作了，在商业上我们目前正使用它来为我们的客户服务。它是一种强大的方法，非常适合我们的 SOA 业务驱动观点。

InfoQ：你们认为 SCA 和 JBI 之间存在重叠吗？

MR：技术上不存在重叠。JBI 可被作为创建运行时的基础设施使用，这些运行时可以部署和执行使用 SCA 组合体（Composite）描述的应用。但是我愿意有些争议性，并直言关于 JBI 是否是用于完成这一任务的最好技术，我心中存疑。JBI 立足于一个在运行时对规范消息做出路由和处理决议的消息传递范式。但 SCA 使得使用一种更为有效的基础设置成为可能，其中的路由和绑定决议在部署时被确定，因此消息无需规格化即可发生通信，并使基础设施的开销最小化。这就是我所熟知的开源 SCA 运行时（Fabric3 和 Tuscany）中没有一个基于 JBI 的原因。

ME：一个字，不。SCA 主要关心使用非常广泛的技术去构建最终用户应用。JBI 更关心为 Java 平台上的异构服务应用构建基础设施。SCA 可以在 JBI 运行时之上使用，但是也能在没有 JBI 的情况下使用 SCA，以及在没有 SCA 情况下使用 JBI。

SJ：JBI 是引擎到引擎（engine-to-engine）的，SCA 包装了引擎中的代码。开始两者存在有重复的风险，但是我们已经反馈给相关团体有几年了，我们认为两个工作组一起工作对大家都有好处。

DB：SCA 关注定义设计时服务调用的抽象概念，而 JBI 定义运行时服务调用的 API。某些概念显然是关联的，但是重叠（如果有）是最小的。

InfoQ：在微软的 SOA 技术兵器库中是否有与 SCA 对等的东西？

ME：Windows 通信基础（WCF）具备一些 SCA 服务组件模型的特性，但是对于应用组合来说，不存在真正与 SCA 装配模型对等的东西。

InfoQ：你们如何看待 SCA 目前在一个标准过程中的发展？它会发生大改变吗，还是你们认为它其实接近完成了？

ME：我们期望 SCA 不会从目前 1.0 规范改变太多。OASIS 技术委员会的主要任务是创建细化的一致性表述和相关测试套件，该测试套件有助于确保来自不同提供者符合 SCA 规范的实现之间的移植性和互操作性。这才是对最终用户真正有价值的东西。

SJ：我愿意看到第一版的标准快点出来，这样可以使之得以广泛采用。然后，我们就可以开始考虑接下来干什么。不管用什么手段 SCA 都不会完工，因为它可延伸到许多企业问题，但是与其等到我们把海蒸干不如去迭代规范。

DB：因为 OASIS 目前有 6 个技术委员会，将 SCA 规范作为整体推广非常的困难。其中一些规范明显比其他的更成熟。我们可以相当肯定相关公司（作为一个集体）将对用户作出反应。既然规范现在是“1.0”级别且可以公开获得，希望我们会从真正的用户那儿获得反馈，告知我们哪些是最需要改动的。在短期内，没人会指望为一个厂商工具所写的 SCA 组合体可以与另一厂商的工具完美地一起工作。就像在 SQL 的早期，也没人会指望为一个数据库写的 SQL 语句可以与其他厂商的一起工作。当然，用户肯定会指出某些领域进一步兼容性比其他的更重要。

MR：我认为 SCA 中的主要想法已经被非常好的设计出来，因此，如果它们有大的改变的话，我会感到惊讶。但是，我也认为 OASIS 技术委员会不会仅仅加固已经完成的设计决定，而且还会显著改进设计。技术委员会还会从 OASIS 成员获得好处，他们拥有 SCA 1.0 规范的实现经验，而且还可从为这些技术创建测试套件的努力中获得反馈。

InfoQ：早期对 SCA 的非议之一就是说它与 JEE 是竞争关系。既然 Sun 现在参与进来了，那么任何这样的评论都是毫无根据的。这样说对吗？

ME：在整个使用 SCA 组合的应用中使用 JEE 组件和应用是完全有可能的，其他技术亦被使用。SCA 甚至有一个针对于此的规范。因此，我想说的是 SCA 与 JEE 是合作而非竞争关系。SCA 确实承认在一个典型的业务环境中不仅仅只有 JEE——它只是 SOA 世界中的一分子。

DB：我认为那些早期非议的根源在于缺乏对 SCA 和它的目标的全面理解。Java EE 可能为企业应用付出了很多，但是在 SOA 的环境下，当你看看针对端对端的业务解决方案这一个更大场景或组合应用的时候，就需要比 Java EE 所提供的更多的工具和能力，这些元素超出了 Java EE 的范围。

SP：我们将 SCA 视为对 Java EE 有价值的补充。它将为开发者和厂商保留 Java EE 的投资，同时提供了一个框架，该框架允许新组件模型的插件。为了做到这点，通过扩展 Java EE 应用模型并允许访问新的实现技术（如 BPEL）和新的协议绑定，我们想为 SCA（它使 Java EE 更好的为 SOA 做好准备）创建一个进化模型。我们注意到了一个模型，它允许使用 SCA 部件和其他（在一个装配中 SCA 支持的实现技术）部件增强 Java EE 应用。

SJ：我们在 J2EE 上使用 SCA。我总是对那样说的人感到迷惑。

MR：我得说有些部分与 Java EE 是有重叠的，但是大部分不是。设想一个由 EJB session beans、JAX-WS（或 JAX-RPC）服务、消息驱动 Beans 和一些部署描述符创建的 Java EE 应用。使用 SCA Java 编程模型创建组件实现并使用 SCA 的组合文件配置它们，应该可能创建相同的应用。运行时可能依旧使用 JMS 以及 JAX SOAP 的一个协议栈，但是它们的 API 对开发者不可见。

没有重叠的领域包括表现层（Servlet、JSP、JSF 等）或数据层（JDBC、JPA）Java EE 技术。诸如 JCA 和 JMS 的技术依旧被使用，但是组件开发者不直接使用它们 API。相反，基础设施使用那些技术以提供可配置的绑定，那些绑定提供对后端系统或消息系统的访问。

InfoQ：对于给 OASIS 的捐献，是否存在有其他的 SCA 区域尚未达到成熟级别？如果有，你们能让我们知道它们可能是哪些吗？

ME：开放 SOA 协作正在继续讨论 SCA 那些还尚未成熟的方面。一些将直接作为 OASIS 技术委员会讨论的一部分。例子包括，用于装配规范的发布 / 订阅和事件模型。其他的，如方便管理的 SCA 关系和用于某些脚本语言的 SCA 规范还处于讨论的非常早期的阶段，最初将在 OASIS 外发展，直到它们成熟起来。

MR：另一个领域——我们期望 OASIS 技术委员会能做些工作，但是我们还没有一个输入文档提供——是描述 Java EE 应用和 SCA 如何集成的规范。但是，我们有一个 Wiki 页来描述我们关心的用例。

InfoQ：你们的公司是一个 SCA 的开发者、使用者或两者皆是？

MR：BEA 是一个 SCA 开发者。

ME：两者都是。IBM 构建提供 SCA 的产品，但是 IBM 也有旨在使用 SOA 为客户构建解决方案的服务部门。

SP：SAP 是一个 SCA 开发者。

DB：TIBCO 是一个 SCA 开发者，提供客户可以用来建构基于 SOA 解决方案的产品。

InfoQ：你们认为 SCA 在你们的公司 SOA 战略中处于哪个位置？

SP：简化组合应用的设计和部署是实现企业 SOA 好处的重要因素。服务组件架构（SCA）旨在简化基于 SOA 的服务组合。SCA 还有巨大的潜力给基于标准的 SAP NetWeaver 扩展提供不同应用编程模型和通信机制（被我们合作伙伴和用户生态系统所使用）。

SJ：作为业务 SOA 技术交付的一部分。设计、实现和部署阶段它非常适合。

ME：它是支持构建 SOA 应用的核心产品的重要方面。

DB：正如我们看待它的，SCA 是目前用于 SOA 的"不二法门"。我们正为我们的 SOA 战略在 SCA 方面进行重大投资。

MR：我们认为它适合两个基础领域。一个是作为简化应用开发、配置和部署的集成技术，该技术使用了多种来自 BEA AquaLogic 和 WebLogic 产品线的技术。它也将提供新的简化编程模型，允许新的服务以 Java 创建并在 WLS 中部署。

InfoQ：为什么微软没有参与？既然 SCA 被认为是语言无关的，且包含许多微软已经参与的 WS-* 技术，他们的支持对于完成这个有意义的标准似乎应当是必须的？

ME：微软可以在任何时间加入 OASIS SCA 活动，我们会欢迎他们。SCA 是一个没有微软参与的有意义标准，即使微软不支持，SCA 也能够支持在微软平台上的实现。

DB：至于微软的参与，显然最好由微软自己来回答。但是，恕我冒昧的回答，我认为微软首先最应该关注的是他们的同构环境和他们那些已经在该技术上投入重大的客户。通过 SCA 具备的要素，我期望微软会找到一个参与级别，给他们在整个标准上的努力带来平衡。

InfoQ：在不同的 OpenCSA 技术委员会中你们的角色是什么？

MR：我是 SCA-J 技术委员会的联合主席和 4 个其他 SCA 相关技术委员会的成员。我还是检查 OpenCSA 工作的指导委员会成员。

DB：我目前在 OpenCSA 指导委员会服务并作为 6 个技术委员会的观察者参与。

SP：SAP 是 SCA-J 和 SCA-BPEL 技术委员会的联合主席。此外，SAP 试图继续成为一个积极的技术贡献者，也是技术委员会角色的志愿者，如规范编辑等。

InfoQ：你们认为 SCA 在其他方面将协作或影响其他标准活动吗？

ME：是的。有许多与 SCA 关联的其他标准。它们中的一些将影响 SCA，其余的则受 SCA 的影响。一个例子是涉及系统管理的标准，因为当一个 SCA 应用被管理时，它对于管理接口反映应用 SCA 结构非常有帮助。

DB：根据我们内部经验和用户交互，我们认为部署、安全和策略领域在短期内有协作或影响的机会。

InfoQ：你们期望从 OpenCSA 全体大会中有什么收获？

SP：我们希望看到有更多的 OASIS 成员加入到 SCA 的工作中来，以进一步验证和驱动 SCA 技术的开发和采纳。

DB：全体大会和面对面会议最重要的成果是使全部技术委员会有一个好的开始，并就其各自的章程开展工作。通过使全部 6 个技术委员会在这一个事件中启动，这会使他们对技术委员会间的内部倚靠和协调的感觉更好，这将成为 SCA 成功和采用的一个因素。

ME：从 OpenCSA 全体大会周将看到 6 个 SCA 技术委员会的启动。本周的成果也将设置明年 SCA 的工作模式。此外，对于那些 SCA 的新人，全体大会周提供了从那些由项目一开始就涉足其中的前辈那儿获得免费 SCA 教育的绝佳机会。

MR：我期待尽快处理程序问题，接着开始构造有意义的技术问题列表，它们是技术委员会成员由输入规范已经意识到的问题。我希望这些第一天的面对面会议将使我们处于一个坚实有效的技术前进轨道上，该过程我们会在接下来的电话会议中维护。

查看英文原文： SCA Interview