服务组件架构

服务组件架构（，简称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软件公司。Technology vendors extend collaboration on SOA technologies http://www.hoise.com/primeur/06/articles/monthly/E-PR-08-06-92.html

 定义  

发布的规范 在许多方面看起来都很模糊不清，但是随着新规范 的演变，SCA迅速地成熟起来（但某些方面仍然存在致命问题https://web.archive.org/web/20080224210629/http://ke-jin.blogspot.com/2007/11/service-component-architecture-sca.html）。规范指出使用SCA设计的应用程序应当具有以下特性：
 将服务的实现和服务的组合与基础设施能力相分离。
 应该能与多数语言一起工作包括C++，Java，COBOL和PHP，以及XML，BPEL。 XSLT。
需要能够与不同的消息构造一起工作， 包括单向，异步，调用-返回，通知。
 基础设施能力，例如安全事务，和可靠消息的使用应该能够通过编写元数据应用。
 数据应以服务数据对象标识。
 在SCA中定义的组件应该很容易重用。
 服务的本地调用应该更加紧耦合，减少为了在网络上传输而创建和解析消息的开支。

 进一步分析 

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

优势：
 迎合所有现存的Java平台技术和C++（然而SCA的C++组件模型定义存在致命问题）
 较少的技术依赖性 - 不需要依赖于Java程序设计语言和XML技术
 使用服务数据对象，服务数据对象是SOA的数据访问的唯一工业标准。
 缺少微软的支持，使得潜在用户可以在大量提供商之中选择SOA解决方案。b
劣势：
 缺少微软的支持，这减少了SCA与大量潜在用户的关系。
 规范并未解决SOA应用的性能问题，这将持续阻碍SCA被采用。

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

脚注

参见


 外部链接 
 SCA 0.9版规范 
 SCA 0.96版规范
 Open Service Oriented Architecture .org -- SCA规范相关信息的官方网站
 Apache SCA规范的开源实现 
 SCA Announcements at OASIS web site 
 Service Data Objects initial work by BEA and IBM
 Comparing WCF and SCA 
 Summary of SCA 
 BPEL in SCA assembly 
 PocoCapsule SCA组装容器（C++） 该GPL开源实现基于控制反转（IoC）及领域特定建模（DSM），并附丰富的应用实例（包括SCA著名的BigBank）
 Eclipse STP SCA Tools 
 SCA被认为是有害的！

Category:服務導向
Category:企业应用集成