相当数量的博客们一直想知道关于服务组件架构（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的开发将在大众注视下继续进行。保持关注！