服务组件架构（Service Component Architecture，简称SCA，也译作服务构件架构， 服务组件体系结构）是新出现的但非常重要的由主要的Java EE技术厂商鼓吹的技术规範，提倡者认为SCA能够适合发布符合面向服务架构的原则的套用。服务组件模型（SCA，Service Component Architecture）中提出了一些新的概念，比如服务组件，模组，共享库，导入和导出等。
基本介绍
- 中文名：服务组件架构
- 外文名：Service Component Architecture
- 缩写：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软体公司。
起源
基于组件的编程一直是软体业简化编程和提高效率和质量的一个重要方法，但是往往对于不同语言我们有不同的组件模型，从而需要不同的调用方式。SCA的目的是使用户在构建企业套用时有一个不再直接面对具体的技术细节的层次，而是通过服务组件的方式来构建套用。这种方式也使得客户的企业套用具有良好的分层架构，能够很好的分离套用的业务逻辑和IT逻辑，不但易于套用的构建，也易于套用的更改和部署。
定义
发布的规範在许多方面看起来都很模糊不清，但是随着新规範的演变，SCA迅速地成熟起来（但某些方面仍然存在致命问题）。规範指出使用SCA设计的应用程式应当具有以下特性：
将服务的实现和服务的组合与基础设施能力相分离。
应该能与多数语言一起工作包括C++，Java，COBOL和PHP，以及XML，BPEL。 XSLT。
需要能够与不同的讯息构造一起工作， 包括单向，异步，调用-返回，通知。
基础设施能力，例如安全事务，和可靠讯息的使用应该能够通过编写元数据套用。
数据应以服务数据对象标识。
在SCA中定义的组件应该很容易重用。
服务的本地调用应该更加紧耦合，减少为了在网路上传输而创建和解析讯息的开支。
进一步分析
Gartner集团曾发布研究结果，认为SCA以及服务数据对象 (SDO)技术已经成熟将被快速的採用。
优势
迎合所有现存的Java平台技术和C++（然而SCA的C++组件模型定义存在致命问题）
较少的技术依赖性 - 不需要依赖于Java程式设计语言和XML技术
使用服务数据对象，服务数据对象是SOA的数据访问的唯一工业标準。
缺少微软的支持，使得潜在用户可以在大量提供商之中选择SOA解决方案。
劣势
缺少微软的支持，这减少了SCA与大量潜在用户的关係。
规範并未解决SOA套用的性能问题，这将持续阻碍SCA被採用。
服务组件架构服务
CICS支持两种类型的SCA应用程式：基于通道的和基于XML的，这两种应用程式可以通过EXEC CICS INVOKE SERVICE命令调用。
有趣的是，应用程式编程参考手册（Application Program Reference Manual，APRM）指出，程式设计师应该使用INVOKE SERVICE命令代替INVOKE WEBSERVICE，这似乎是基于XML的服务可能是Web服务的超集或泛化的信号，实际上，APG中谈到了使用Web服务绑定Web服务描述语言（Web Service Description Language，WSDL），这意味着在SCA中，当域跨平台时，Web服务沦落到成为常规服务的一个特例。
基于通道的服务非常简单，SCDL定义了容器或通信区域（COMMAREA）看起来的样子，组件的实现是目标程式名，调用者使用INVOKE SERVICE命令，指定包括输入数据，服务URL，以及服务操作的通道，在识别服务后，CICS只需要简单地连结到程式。
基于XML的服务更多的是扮演我们已经使用过的Web服务，当调用者调用服务时，CICS传递信息给请求程式和提供程式管道，如果没有为服务定义管道，CICS会临时分配一个，所有信息都顺着管道传递，普通讯息处理程式像以前那样控制和处理讯息，最后，CICS调用目标程式执行业务功能。
