服务组件架构

服务组件架构（Service Component Architecture，简称SCA，也译作服务构件架构， 服务组件体系结构）是新出现的但非常重要的由主要的Java EE技术厂商鼓吹的技术规范，提倡者认为SCA能够适合发布符合面向服务架构的原则的应用。

支持者

支持的厂商包括：

• 最初的成员 BEA，IBM，IONA Technologies，甲骨文公司，SAP公司，Sybase，Xcalia （页面存档备份，存于互联网档案馆）和Zend Technologies。
• 2006年7月26日宣布加入的成员： Cape Clear，Interface21，普元软件，Progress Software，Red Hat，Rogue Wave Software，Software AG，太阳微系统公司和TIBCO软件公司。^[1]

定义

发布的规范^[2] 在许多方面看起来都很模糊不清，但是随着新规范^[3] 的演变，SCA迅速地成熟起来（但某些方面仍然存在致命问题^[4]）。规范指出使用SCA设计的应用程序应当具有以下特性：

• 将服务的实现和服务的组合与基础设施能力相分离。
• 应该能与多数语言一起工作包括C++，Java，COBOL和PHP，以及XML，BPEL。 XSLT。
• 需要能够与不同的消息构造一起工作， 包括单向，异步，调用-返回，通知。
• 基础设施能力，例如安全事务，和可靠消息的使用应该能够通过编写元数据应用。
• 数据应以服务数据对象标识。
• 在SCA中定义的组件应该很容易重用。
• 服务的本地调用应该更加紧耦合，减少为了在网络上传输而创建和解析消息的开支。

进一步分析

Gartner集团曾发布研究结果，认为SCA以及服务数据对象 (SDO)技术已经成熟将被快速的采用。^[5]

优势：

• 迎合所有现存的Java平台技术和C++（然而SCA的C++组件模型定义存在致命问题^[4]）
• 较少的技术依赖性 - 不需要依赖于Java程序设计语言和XML技术
• 使用服务数据对象，服务数据对象是SOA的数据访问的唯一工业标准。
• 缺少微软的支持，使得潜在用户可以在大量提供商之中选择SOA解决方案。b

劣势：

• 缺少微软的支持，这减少了SCA与大量潜在用户的关系。
• 规范并未解决SOA应用的性能问题，这将持续阻碍SCA被采用。

实现

• Fabric3 （页面存档备份，存于互联网档案馆）
• Rogue Wave HydraSCA
• Covansys的服务组建架构框架^[6]
• Apache Tuscany
• Paremus Infiniflow （页面存档备份，存于互联网档案馆）：分布式的，动态的，轻量级的SCA和OSGi运行平台
• Newton开源的分布式SCA和OSGi
• SCA and SDO for PHP
• PocoCapsule SCA组装容器（C++） 该GPL开源实现基于控制反转（IoC）及领域特定建模（DSM），并附带丰富的应用实例（包括SCA著名的BigBank）