服务组件架构（Service Component Architecture，简称SCA，也译作服务构件架构， 服务组件体系结构）是新出现的但非常重要的由主要的Java EE技术厂商鼓吹的技术规范，提倡者认为SCA能够适合发布符合面向服务架构的原则的应用。服务组件模型（SCA，Service Component Architecture）中提出了一些新的概念，比如服务组件，模块，共享库，导入和导出等。
支持者支持的厂商包括：
最初的成员 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逻辑，不但易于应用的构建，也易于应用的更改和部署。1
定义发布的规范在许多方面看起来都很模糊不清，但是随着新规范的演变，SCA迅速地成熟起来（但某些方面仍然存在致命问题）。规范指出使用SCA设计的应用程序应当具有以下特性：
将服务的实现和服务的组合与基础设施能力相分离。
应该能与多数语言一起工作包括C++，Java，COBOL和PHP，以及XML，BPEL。 XSLT。
需要能够与不同的消息构造一起工作， 包括单向，异步，调用-返回，通知。
基础设施能力，例如安全事务，和可靠消息的使用应该能够通过编写元数据应用。
数据应以服务数据对象标识。
在SCA中定义的组件应该很容易重用。
服务的本地调用应该更加紧耦合，减少为了在网络上传输而创建和解析消息的开支。2
进一步分析Gartner集团曾发布研究结果，认为SCA以及服务数据对象 (SDO)技术已经成熟将被快速的采用。
优势迎合所有现存的Java平台技术和C++（然而SCA的C++组件模型定义存在致命问题）
较少的技术依赖性 – 不需要依赖于Java程序设计语言和XML技术
使用服务数据对象，服务数据对象是SOA的数据访问的唯一工业标准。
缺少微软的支持，使得潜在用户可以在大量提供商之中选择SOA解决方案。1
劣势缺少微软的支持，这减少了SCA与大量潜在用户的关系。
规范并未解决SOA应用的性能问题，这将持续阻碍SCA被采用。2
服务组件架构服务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调用目标程序执行业务功能。1
本词条内容贡献者为:
曹慧慧 – 副教授 – 中国矿业大学