向服务组件架构出发

相当数量的博客们一直想知道关于服务组件架构（SCA）的标准化努力。

SCA 的挑选（pick-and-chose）规范风格使人很容易在 SCA 的宇宙中迷失。因为社区中基本没有 SCA 的使用经验，许多值得详细说明的领域依旧还处于调查研究之中，或者甚至还未被触及。

首先，读者很容易被误导相信 SCA 是 Java 领域的（又一个）革命。就两点来说，这是错误的。首先，尽管面向 Java 的工作吸引了绝大多数的注意力，但是 SCA 不仅仅只关心 Java 领域：还有针对 C++、COBOL、PHP 和 BPEL 的规范。话说回来，我们所要注意到的是：SCA 主要目的不是替换现有环境（如 Java EE 和 OSGI）而是创建一个基础设施，其中的应用可以穿越这些环境中的不同编程模型间的边界。SCA 将如何与现有技术集成的细节是已发布的 SCA 规范目录中缺失的一块。在描绘出与这些环境在所有层次上集成的繁琐细节之前的确还有很多工作要做。

技术集成是困难的。在它的使用过程中，不应该仅仅局限于单一的有趣的技术。可是，SCA 的全部内容就是关于跨技术（cross-technology）集成的。

SCA 看起来前景不错。在不同的场合（包括公开会议）已展示了一些非常有趣的原型：

• Oracle 开发者已经示范了 BPEL 过程与专用仲裁组件、工作流组件和事件代理的组合（参见这里）。
• SAP 开发者已经展示了在一个 Java EE 应用包中 Java EE 组件和 BPEL 过程的组合，以及在几个 Java EE 应用之上的域级别（domain-level）装配。（参见这里的 JavaOne 2007 会议）
• Apache Tuscany 项目可以运行混合有脚本语言组件和 Java 组件的组合。
• SCA 的 Fabric3 实现展示了如何在一个分布式运行时环境和不同编程技术实现之上装配服务网络。

让我们尝试总结一下我们可以从这些例子中学到的东西：

SCA 是对框架的增强，该框架为组件和连通性抽象提供了编程模型。那些框架可能是标准产品，但是也可能是私有技术，例如，用于 SAP 系统的远程函数调用（RFC），私有仲裁或脚本组件、SQL 存储过程等。为了兑现一系列的好处，SCA 定义了一门装配语言，它可被集成进入这样的框架中。我们将详细讨论各种益处。我们可以得出以下的结论：

• SCA 支持与现有技术结合。那将可能是它的主要用例。
• SCA 的基本价值在于提供了跨技术编程模型集成、分布式部署和装配的基础。
• SCA 允许实现者以一种一致和公认的方式提供私有技术——这对开发者和厂商都有好处。

与现有环境集成

如果有什么不同的话，那就是 SCA 关心与现有技术的集成。在设计 SCA 时，它就不是关于重用或其它规范的。它的做法另辟蹊径：规范描述如何与 SCA 模型深入集成。当在 osoa.org 浏览 SCA 白皮书或跟踪原型成果时（参见以上），你就会看到这点。这里的想法是，无论一个特定技术好在哪里，只要利用 SCA 向外扩展它的使用就更能增加它的价值。

集成现有技术可能用不同方法，在不同层次上发生。对一门脚本语言来说，一种实现类型定义是一种自然选择。对于服务调用技术来说，例如消息传递、远程协议、绑定都是集成的方式。对于如 Java EE 这样提供了一个部署模型的运行时环境，一个（可能更多）组件模型集成可能发生在不止一个层级上。

与给定环境的 SCA 装配深入集成可以减少由抽象所带来的烦人的模型摩擦，这些抽象一般试图将所有类型的运行时包装成为一个公共的“更高级”运行时模型。

例如，有时通过 WSDL 抽象所有的服务，并在一些通用面向 XML 的 WS-* 运行时中实现服务调用，这看起来是个不错的点子。尽管从高层看那似乎是个不错的主意，但是从一个服务开发者和服务消费者的角度来看缺乏吸引力：不论你身处何出，你都必须付出非集成的阻抗失配代价，这种非集成需要在不同技术之间来回转换——包括命名、事务处理、安全。

相反，一个 SCA 集成将试图给本地器件提供表演机会，这样它们就可以在装配定义中立刻被引用，只有当需要用到以前没有的特性时，才需要修改。

跨技术编程模型集成

SCA 引入了实现类型（implementation type）这一抽象概念。实现类型从 SCA 装配的角度描述了组件的外观。换句话说，它说明了一个组件提供了什么服务端点、它需要什么引用，以及为它指定了哪些配置属性。在那种意义上，一个实现类型提供了独立于技术的组件实现表示。

这听起来有点象是科幻小说，并且我们以前就已经听说过这样的东西了。然而，SCA 并不企图捕获一个组件和它在自身语言内进行交互的所有方面。例如，SCA 并没有定义它自己的接口描述语言，而是依赖 Java 和 WSDL。其他接口语言在需要时被实现者支持。按照同样的精神，尽管 SCA 定义了一个策略框架，它确实尽可能的重用 WS-Policy 定义。

一旦你有了一个实现类型，比方说 foo，你就可以使用 SCA 装配来定义组件类型 foo 如何与其他环境相结合，比方说 BPEL 过程、Java POJO、或 EJB 会话 Bean——凡是你选择的环境所支持的东西。

从一个厂商的角度来看，这意味着 SCA 降低了给他的用户提供实现或绑定技术的边际成本。对于使用者，它意味着 SCA 降低了利用实现或绑定技术的边际成本。

在 Java EE 的情况下，我们实际上在 SAP 进行了一次研究。我们将一个 SCA 运行时和一个 BPEL 引擎与我们的 Java EE 5 环境（就是 SAP Netweaver）集成起来，得到了一个无缝的 BPEL 与 Java EE 组件集成和生命周期模型。让我们看看我们所得到：真正的本地 BPEL 到 Java（反之亦然）本地调用（虽然没有按引用传递，pass-by-reference），因为我们有充足的本地应用装配元数据。特别是一个 BPEL 过程可以通过 SCA 连线（wire）调用一个会话 Bean，使用 Java 持久化 API（JPA）在同一事务中更新持久化数据，而且通过为局部接口暴露 Web 服务不会泄漏隐藏信息。在本例中，SCA 连线有一端由 WSDL 接口定义，它的组件侧由 BPEL 实现；有一端由 Java 接口定义，它是会话 Bean 的业务接口。

从另一侧来说：在为诸如 BPEL 这样的编排（orchestration）语言提供支持时，需要尽可能地能无缝重用现有资产。此处，SCA 有助于允许在本地使用它，几乎是“就地的（in place）”。

尽管没有理由去期望 C++ 代码和 Java 进行类似的集成（但是……谁知道呢），但是有很多的来自企业服务总线（ESB）的编程模型或企业应用集成（EAI）遗产，它们可按照集成 BPEL 的相同套路来被集成。

分布式部署和装配

尽管 SCA 明智地没有描述一个特殊的部署格式，但是它确实定义了部署的一些方面。特别是它定义了“部署到 SCA 域（contribution to the SCA domain）”这个概念。这是 SCA 的另一关键概念。

在我们讨论部署单元（Contribution，即：可部署的）的时候，我们可以超越单个部署单元去谈论装配，它实际上就是 SCA 所说的域（domain）级别的装配。域被可视化为一个包含来自部署单元的组合的组合。即，使用与我们本地使用相同的装配语言，我们得到了一种表示跨部署单元装配关系的方法。

被域概念激活的分布式装配是在编程级别跨技术集成的逻辑对应物。实际上，业务应用必须跨应用包集成，而且往往跨几种技术区别巨大的系统，编程级别的集成是不合理的。

幸运的是，一个域可能横跨不止一个系统和内部互连的几个系统。在这种意义上，域级别装配提供了一个连通性抽象，它将来自系统到系统的物理端点的配置，移到了复合领域结构的定义中。

它不仅关于抽象域内端点寻址。除那之外，装配信息可能对实际使用的传输协议保持沉默，依赖于域的异构性，域把那个决定留给领域管理员或甚至是运行时实现。

从企业服务总线（ESB）的角度来看，这说明今天的趋势是“ESB 能力的边缘化”。即编程模型集成（参见以上）允许我们自由地在业务应用逻辑中实现集成功能，而域抽象了 ESB 拓扑细节——即服务总线上的编程。

私有技术和 SCA

以上得出的一个重要论点是：为提供者和使用者降低新编程模型的边际成本。它是简单的双赢情形。

厂商一般不愿引入新编程模型，因为涉及将它推向开发者和工具所付出的额外努力。新的部署模型、管理工具和工具套件促使引入了一个新的编程语言（如 BPEL），这并不少见。这样公平吗？

类似地，为什么用户应该对必须学习多余的东西而高兴呢？而且这些东西并不能使他们的开发生涯更舒心。

讲到私有技术，这意味着厂商可以使用 SCA 提供对新技术或私有技术更快、更省力的使用。使用者应该期望进入领域特定技术更低的门槛。

总结

你从本文可以了解到 SCA 主要不是企图替换或变革你钟爱的技术。它增加了你可在需要时使用的装配抽象。

它是关于 SOA 的吗？如果我们说 SOA 是关于抽象连通性细节，能为集成和应用部署篡改不同的传输协议和编程模型，那么 SCA 就是简化 SOA 开发的。

现在，SCA 进入 OASIS 并被称为开放组合服务架构（OpenCSA），SCA 的开发将在大众注视下继续进行。保持关注！

参考：

• InfoQ 的 SCA-debate： http://www.osoa.org/display/Drumbeat/Conferences+and+Events （中文站新闻）
• InfoQ 的 SCA 访谈： http://www.infoq.com/articles/sca-opencsa-interview （中文版）
• OSOA.org SCA 主页： http://www.osoa.org/display/Main/Service+Component+Architecture+Home
• OASIS SCA：OpenCSA http://www.oasis-opencsa.org/
• SCA 1.0 规范： http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications
• 2007 年 JavaOne 会议的 SCA 结合 J2EE 的 PPT： http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-41500&yr=2007&track=3
• OASIS SCA 教程（第一部分）： http://www.osoa.org/download/attachments/250/SCA_OASIS_Tutorial_part1.pdf
• Fabric3： http://fabric3.codehaus.org/
• Apache Tuscany： http://incubator.apache.org/tuscany/
• Open CSA 全体大会议程： http://www.oasis-opencsa.org/node/51

查看英文原文： Setting out for Service Component Architecture