SCA访谈

作者 Mark Little 译者 胡键 发布于 2007年10月21日

领域

企业架构

主题

SOA ,

SOA Appliance ,

SOA平台

标签

标准化 ,

服务组件架构

自从它于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

• 更早的 >