陈 兵

1. 什么是SCA

SCA（Service Component Architecture）是针对SOA提出的一套服务体系构建框架协议，内部既融合了IOC的思想，同时又把面向对象的复用由代码复用上升到了业务模块组件复用，同时将服务接口，实现，部署，调用完全分离，通过配置的形式灵活的组装，绑定。

从代码级的面向对象思想，到组件级的EJB概念，再到服务级的SOA理念，是一个开发复用的不断提升的过程，经历的经验教训正在给实践做出最好的指导。SOA提倡的就是更高级别的复用，服务的复用，Internet提供了开放的环境，但是没有一种统一的服务访问模式，让各个企业之间成了信息内部丰富的孤岛，需要将这些孤岛串联起来，同时要最大限度的复用有限的资源，因此提出了面向服务概念，但是多年的SOA口号下却缺少着一个真正的实施标准和解决方案，因此SOA的理论传播大于实际实施。

面向服务的体系架构(SOA)提供了一条途径来解决紧耦合和应用固化的问题。SOA承诺它将带来诸多好处，例如提高商业敏捷性,提高灵活性，降低成本，使异构和分布式环境中的信息共享变得更加容易。

SOA描绘了一个蓝图，但实现SOA仍然是一个挑战。可供选择的用来实现SOA的技术令技术人员迷惑, 他们需要具有比较全面的技术才能成功建构一个SOA应用。SCA可以解决这一问题——提供了一个用以创建面向服务的端到端企业应用的简单模型。SCA（Service Component Architecture）其实就是将过去EJB的成果继续下去，基于Component的复用，同时吸收了IOC的思想，Component之间的组装是通过SCA框架来实现的，但是很重要的一点，他没有走EJB的老路，而是学习spring的轻量级框架，不再为开发者作的面面俱到。SCA的Component和OSGI的Bundle一样其实是对Java封装的一种贯彻，它有需要Import的服务引用，需要Export的服务，很重要一点就是它对于Component，service,reference的实现都没有作限制，这类对象只需要有个接口定义和实现描述即可，当前规范中支持的接口定义可以是java接口也可以是wsdl文件（最终也是转换成为java接口），实现的话那么更加广泛java,webservice,rmi,jms,脚本语言等等，同时提供了扩展接口。采用了SCA的业务将从以下几个方面受益：

Ø     快速开发，提高生产力: SCA把一个应用看成一系列相互连接的组件。它提供了一个简单的、语言中立的组件模型，组件可以是新创建的，也可以重用已有组件。组件可以用SCA运行环境所支持的任何语言来实现。通过组件的实现和组装细节的分离，SCA实现了真正的松耦合。这种自底向上的开发风格允许开发人员集中精力开发业务相关代码,而不用担心如何使其适用于整个解决方案。

Ø     更高的组织敏捷性和灵活性:SCA同样支持由顶向下的开发方式，通过SCA灵活的服务装配模型创建业务解决方案。SCA组件可以在一个构件组中连接在一起。一个组件可以被有着相同接口的另一个组件所替代。这个构件组可以根据IT架构需求进行调整，例如服务连接、传输协议、事务、安全和消息可靠性。可供选择的传输绑定方式使开发出的解决方案可以适应更广泛的部署需求。

Ø     更高的投资回报: SCA组件模型使得重用已投资的现有应用和服务变得非常容易。其标准方法是封装和抽象接口，通过重新连接服务创建新应用,以此重用服务。SCA本身是技术中立的，也并非要取代现有的技术。其仅仅提供了一个组件组装模型，并描述了如何去装配新的和现有的服务。

2. SCA V1.0规范的组件

前面硕果SCA（Service Component Architecture）是基于Component（组件）的复用，当然组件就是SCA最主要的组成部分了。下面我们详细地讲解述SCA中的组件。

在SCA V1.0装配规范中,相对较为独立的组件只有三个,粒度由小到大分别是Component、Composite和Domain,其他Service、Reference、Property、Wire等都是辅助性的元素。这些辅助性的元素做为三个独立的组件中的组成部分,为组件与外部数据传输、对外提供服务和引用外部资源提供途径，将各个组件的组成粒度更大的上层组件。三个不同的组件，分别对应系统的三个不同层面：Component组件对应实现层，Composite组件对应架构层，Domain对应业务层。后面将会用三篇文章的篇幅分别说明三个组件和三个层面直接的关系以及使用。

1）Component（组件）