基于组件的编程一直是软件业简化编程和提高效率和质量的一个重要方法，但是往往对于不同语言我们有不同的组件模型，从而需要不同的调用方式。SCA的目的是使用户在构建企业应用时有一个不再直接面对具体的技术细节的层次，而是通过服务组件的方式来构建应用。这种方式也使得客户的企业应用具有良好的分层架构，能够很好的分离应用的业务逻辑和IT逻辑，不但易于应用的构建，也易于应用的更改和部署。

　　SCA全称Service Component Architecture，即服务组件框架。服务组件体系结构 (SCA) 是一个规范，它描述用于使用 SOA 构建应用程序和系统的模型。它可简化使用 SOA 进行的应用程序开发和实现工作。它由BEA、IBM、Oracle等知名中间件厂商联合制定的一套符合SOA思想的规范。

　　SCA是一个可执行的模型，用于将不同的 服务集成到一个业务解决方案。它简化了实现业务服务的组件编程模型，这些组件可以使用不同编程语言实现,对于企业应用，SCA还提供了关键的一些基础设施，像安全性、事务、可靠调用等，这对于企业应用的开发而言就变得很方便了。SCA确实可以成为企业应用开发的利器SCA确实可以成为企业应用开发的利器。SCA是第一项承诺提供一个组合模型以启用服务网络并支持构建下一代面向服务应用程序的技术。 SCA在2005年11月，发布了0.9版本的规范，其中包括了组装模型规范，Java/C++客户端以及其实现规范。2006年4月，整个SCA规范有了很大的改进，推出了对应的0.95版本。2007年3月，OSOA联盟宣布了SCA和SDO规范中关键部分的完成，发布了SCA 1.0和SDO 2.1，并将其正式提交给OASIS，通过其开放式标准过程进行推动。

　　SCA规范中着重解决了现有企业应用之间的相互调用和企业应用如何以面向服务的思想来建立和部署。但是对于构件容器的实现方面的规定则有些不足，仅仅是站在使用者的角度描述了客户端API的规格。

　　SCA可让你专心于分析业务逻辑，而不需要过多的去担心系统架构。SCA简化了所有开发者的使用体验

　　SCA可以将已有的程序、代码、服务添加上元数据，从而可以被其他的服务引用或调用。独立于程序代码的元数据描述信息，可以方便的描述已有的代码，而不须对已有代码做修改。

　　服务组件框架(SCA)提供了一套可构建基于面向服务的应用系统的编程模型。它的核心概念是服务及其相关实现。服务由接口定义，而接口包含一组操作。服务实现可以引用其他服务，称为引用。服务可以有一个或多个属性，这些属性是可以在外部配置的数据值。

　　SCA与SOA

　　既然SCA是为基于SOA思想的系统而制定的开发、部署规范，它首先必然是具备了SOA的一系列的优点，象跨语言、分布式、以服务的思想构建系统等。SCA对于组件中的服务的调用提供了异步调用的支持，在异步调用的支持上SCA的考虑也较为全面，象JMS方式的、RMI方式的等等。

　　使用SOA构建业务解决方案主要的优势之一就在于其能按照业务需求的变化和革新快速组装新的解决方案。解决方案组装的关键是包含现有的应用和功能的能力，而不是什么都从头开始。的确，只有尽可能地复用现有的功能，才能完成快速开发的目标。

　　SCA一种是使用SOA的业务解决方案的编程模型。SCA提供了这么一个特性，使得将已存在的功能组装成新的解决方案尽可能的简单。该文档检验了这些特性中的一些。

　　SCA提供了实现面向服务的架构(SOA)的一个编程模型。

　　面向服务的架构已经在软件开发领域存在很多年了。但是当一些组织试图去定义最佳的实现和管理技能的时候，为一个特定组织开发一个SOA的细节却是难以捉摸的。

　　SCA规范是为了企业应用集成而制定，OSGI规范的初衷则是为移动设备计算而制定的。由于二者的出发点不一样，导致了两个规范的侧重点不一样。SCA规范现在的版本是0.95，相对OSGI规范的4.0版本还显得多少有些稚嫩。

　　服务组件

　　服务组件是SCA中的基本组成元素和基本构建单位，也是我们具体实现业务逻辑的地方。我们可以把它看成是构建我们应用的积木。我们可以非常容易地把传统的POJO，无状态会话BEAN等包装成SCA中的服务组件。 SCA服务组件的主要接口规范是基于WSDL(Web Service Description Language)的，另外为了给Java编程人员提供一个比较直接的接口，SCA的部分服务组件也提供了Java接口。因此，使用服务组件的客户端可以选择使用WSDL接口或Java接口。