项目该如何着手

许多博客作者一直对服务组件体系结构（SCA）的标准化工作感到疑惑。

SCA的选择规范样式使您很容易迷失在SCA领域。 因为在社区中使用SCA的经验很少，所以许多值得详细说明的领域仍在调查中，甚至尚未涉及。

刚开始时，读者很容易被误认为是SCA是Java领域的革命。 这有两个方面是错误的。 首先，尽管面向Java的工作吸引了大多数注意力，但是SCA不仅涉及Java领域：还有C ++，COBOL，PHP和BPEL的规范。 但是，我们要重点关注的是SCA并不是主要是要替换现有环境（例如Java EE和OSGI），而是要创建一个基础结构，在该基础结构中应用程序可以跨越这些环境中不同编程模型之间的边界。 SCA如何与现有技术集成的详细信息是已发布的SCA规范目录中缺少的部分。 找出与这些环境在所有层进行集成的乏味细节，仍然有大量工作要做。

技术整合很难。 任何有趣的技术都不应受到其使用的限制。 但是，SCA完全涉及跨技术集成。

SCA看起来很有前途。 在各种场合（包括公开会议）都展示了非常有趣的原型：

• Oracle开发人员已经通过专有的中介组件，工作流组件和事件代理演示了BPEL流程的组成（请参阅此处 ）
• SAP开发者已经示出具有Java EE应用包内BPEL过程和域级装配在Java EE应用Java EE组件的组合物（参见2007年的JavaOne会话这里 ）
• Apache Tuscany项目可以运行包含脚本语言组件和Java组件的组合
• SCA的Fabric3实现显示了如何在分布式运行时环境上通过各种编程技术实现组装服务网络。

让我们尝试总结一下我们可以从以下示例中学到的知识：

SCA是对框架的增强，该框架为组件和连接抽象提供了编程模型。 这些框架可以是标准产品，也可以是专有技术，例如SAP系统的远程功能调用（RFC），专有中介或脚本组件，SQL存储过程等。SCA定义了可以集成到以下框架中的汇编语言。为了实现一些好处。 我们将详细讨论各种好处。 以下是我们将提出的主张：

• 可以结合现有技术来支持SCA。 那可能是它的主要用例。
• SCA的基本价值在于为跨技术编程模型集成，分布式部署和组装提供基础。
• SCA将允许实施者以一致且可识别的方式提供专有技术，这对开发人员和供应商都有利。

与现有环境集成

如果有的话，SCA是关于与现有技术的集成。 这与设计SCA时不重用一个或另一个规范有关。 这是另一回事：规范将描述如何与SCA模型进行深度集成。 在osoa.org上浏览SCA白皮书或遵循原型工作时，您会看到这一点（请参见上文）。 这里的想法是，只要使用特定技术，只要使用SCA都能扩大使用价值，它就可以进一步增加其价值。

SCA程序集与给定环境的深度集成减少了抽象引入的讨厌的模型摩擦，这些抽象试图将任何类型的运行时一般地包装到一个通用的“较高”运行时模型中。

例如，曾经有一段时间，通过WSDL接口抽象所有服务并在一些通用的面向XML的WS- *功能的运行时中实现服务调用似乎是一个好主意。 尽管从高处看这似乎是个好主意，但从服务开发人员和服务消费者的角度来看，它似乎吸引力不大：无论您身在何处，都必须通过转换为非定律来支付非集成的阻抗失配税。不同的技术-包括命名，交易处理，安全性。

相反，SCA集成将尝试提供对本地工件的解释，以便可以在装配体定义中立即引用它们，并且仅在需要使用以前不可用的功能时才需要对其进行修改。

跨技术编程模型集成

SCA引入了实现类型的抽象概念。 实现类型从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组件和生命周期模型无缝集成。 让我们看看这给我们带来了什么：Java的本地BPEL（反之亦然）调用确实是本地的（尽管没有通过引用传递），因为我们有足够的应用程序本地程序集元数据。 特别是，BPEL流程可以通过SCA连线调用会话bean，并在同一事务中使用Java Persistence API（JPA）更新持久性数据，而不会通过为应该是本地的接口公开Web服务而损害信息隐藏。 在这种情况下，SCA线的一端由WSDL接口定义，即BPEL实现组件的一侧，而一端由Java接口（会话Bean的业务接口）定义。

换个角度来看：当提供对诸如BPEL之类的编排语言的支持时，就需要能够尽可能无缝地重用现有资产。 SCA可以帮助在本地“几乎就地”使用它。

虽然期望C ++代码与Java进行类似的集成是不合理的（但...谁知道），但是有很多来自企业服务总线（ESB）或企业应用程序集成（EAI）的编程模型可以与BPEL集成的路线相同。

分布式部署和组装

尽管SCA明智地没有描述特定的部署格式，但确实定义了围绕部署的一些方面。 特别是，它定义了“对SCA域的贡献”的概念。 这是SCA的另一个关键概念。

当我们讨论一个贡献（认为是可部署的）的那一刻，我们可以讨论除了单个贡献之外的程序集，这恰恰就是SCA中的域级程序集。 域被可视化为包含来自贡献的组合的组合。 也就是说，我们获得了一种使用跨本地表达的汇编语言来表达跨贡献的汇编关系的方法。

域概念支持的分布式程序集是编程级别上跨技术集成的逻辑对应。 实际上，业务应用程序必须跨应用程序包进行集成，并且通常跨技术差异很大的系统进行集成，以至于编程级别的集成是不合理的。

幸运的是，一个域可以跨越多个系统并互连多个系统。 从这个意义上说，域级程序集提供了一种连接性抽象，它将物理端点的配置从系统到系统转移到复合域构造的定义中。

它不仅涉及域内端点寻址的抽象。 除此之外，程序集信息可能对要使用的实际传输协议保持沉默，并且取决于域的异构性，将该决定留给域管理员甚至运行时实现。

从企业服务总线（ESB）的角度来看，这表明当今的趋势是“将ESB功能转移到ESB的边缘”。 也就是说，编程模型集成（请参见上文）使我们能够与业务应用程序逻辑自由混合地实现集成功能，而域则抽象化ESB拓扑详细信息-即在服务总线上进行编程。

专有技术和SCA

上面有一个重要论点：降低提供者和用户的新编程模型的边际成本。 这是一个简单的双赢局面。

传统上，由于要使开发人员和工具可以使用它，因此厂商会不惜引入新的编程模型。 看到为引入新的编程语言（例如BPEL）而提出的新的部署模型，管理工具和工具套件并不少见。 这是合理的吗？

同样，为什么用户应该乐于面对更多需要学习的知识，而不是帮助他们简化开发人员生活的最必要部分？

谈到专有技术，这意味着供应商可以使用SCA更快，更轻松地访问新技术或专有技术。 用户应该期望进入特定领域技术的门槛更低。

摘要

您应该从本文中删除的是，SCA主要不是试图替代或革新您喜欢的技术。 它添加了可以根据需要使用的程序集的抽象。

与SOA有关吗？ 如果说SOA是关于抽象连接详细信息，能够处理各种传输协议和编程模型以进行集成和应用程序开发，那么SCA就是要简化SOA开发。

现在，SCA在OASIS中被称为开放式复合服务架构（OpenCSA），其开发将继续在公众中进行。 敬请关注！

参考文献：

• InfoQ上的SCA辩论： http : //www.infoq.com/news/2007/10/sca-debate
• 在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
• SCA在JavaOne 2007上满足了Java EE演示： http : //developers.sun.com/learning/javaoneonline/j1sessn.jsp? sessn=TS-41500&yr=2007& track=3
• SCA OASIS教程（第1部分）： http : //www.osoa.org/download/attachments/250/SCA_OASIS_Tutorial_part1.pdf
• Fabric3： http ： //fabric3.codehaus.org/
• Apache Tuscany： http ： //incubator.apache.org/tuscany/
• 开放的CSA全体会议计划： http : //www.oasis-opencsa.org/node/51

翻译自: https://www.infoq.com/articles/setting-out-for-sca/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

项目该如何着手