SCA 概念、现状和展望

http://osteching.com/node/8
今年年初的一篇《SOA已死》的博文，在SOA业界引起了广泛的争论。把SOA作为宣称噱头来看，那SOA确实要完蛋了，“云”已经遮住了她，盖过了她前几年的风头。但是如果把SOA作为通过提炼服务，快速响应业务需求的技术风格来看待的话，SOA却依然有实实在在价值。

在开发SOA类型的应用的时候，目前大致有BPEL、ESB和SCA这三种最主要的开发技术。其中BPEL主要是做服务的编排，假设已有一组以WSDL形式定义的服务，如何把他们编排起来提供新的有价值的服务，这个是BPEL适合的场景；ESB可以看作是一条服务通道，把符合ESB工具要求格式的服务单元挂在ESB上，就完成服务之间的互联互通，给客户带来价值；SCA很适合把分布式的甚至是通过不同协议暴露的服务混合组织在一起。

本文主要关注的是SCA。SCA是一种语言无关的编程模型，它提供了统一的面向服务组件（Component）的开发方式，从而使得客户可以把不同的软件模块通过服务组件的方式统一封装起来，进而被调用访问。SCA 规范的参与者是包括IBM、Oracle、（BEA）、Sun、SAP等在内的业界领导厂商。厂商的广泛参与，在很大程度上确保了，SCA规范的接受度。

SCA的起源可以从IBM的WSIF说起。IBM在WSIF的基础上提出了一个面向组件的架构模型（Service Oritented Architecture）。2005年十一月SCA规范以0.9版本首次发布。在2007年三月SCA正式发布1.0版本。在SCA 1.0的规范中，主要包括组装模型（Assembly Model）、策略框架（Policy Framework）、以及各种（Java、Spring、BPEL和C++）实现规范和各种（Web Services、JMS、EJB）绑定规范。就像它的名字，SCA规范主要关注的是面向业务的组件装配。但是，SCA规范没有涉及SCA容器的实现和组件的管理。

1 SCA规范简介

1.1、SCA组装规范

SCA的基础单元是组件（component），它是SCA的最小构成单元。组件(component)由一个可配置的实现（implementation）实例所组成。在该组件中，实现是提供业务功能的程序代码片段。该业务功能可以作为服务（service）而提供给为其他构件使用。一个实现也可能依赖其他构件所提供的服务，这些依赖被称作“引用”(reference)，即引用其他组件提供的服务。实现可以有可设置的属性（properties），属性是外部可见的，可以影响业务功能操作的数据值。请看下面图示（取自SCA 1.0规范）：


SCA把应用中装配在一起的内容和联接称为复合组件（composite）。组合构件能包含组件、服务、引用、属性声明以及描述这些元素间连接的连线（wire）。复合组件可以分组并连接以不同技术实现的组件。对应的，复合组件也能作为完整的组件实现来使用：提供服务，依赖引用以及可配置的属性值。复合组件可以作为单独组件的实现用到其他的复合组件中以支持业务解决方案的分层构建，也就是，高层服务由内部一系列的低层服务来实现。请看下面图示（取自SCA 1.0规范）：


复合组件部署于域（SCA Domain）中。典型地，SCA域描述了一组服务，这些服务提供了由某一组织控制的业务功能区域。为了方便构建和配置SCA域，复合组件可以用于分组和配置有关系的单元。请看下面图示（取自SCA 1.0规范）：


1.2、策略框架

在服务的定义中非功能性需求的获取和表达也是很重要的一个方面，并对SCA有很大影响，而这贯穿复合组件和单一组件的生命周期。从组件设计到具体部署，SCA 提供了一个框架来支持约束、性能和QoS 期望的规范。这就是SCA策略框架。SCA策略框架允许使用WS-Policy和WS-PolicyAttachment以及其它策略语言来指定与SCA 组件相联系的策略和策略主题。在1.0 版本的策略框架中，明确定义了安全策略和可靠性策略。

1.3、SCA实现和绑定规范

SCA的实现（implementation）是用于描述实现面向服务应用中的服务的软件技术的概念。这些软件技术，如Java类、BPEL流程、XSLT和C++的概念都可以用来实现服务。一个SCA复合组件也可以作为一种实现。SCA的绑定（Binding）在服务（Service）和引用（Reference）中用到。引用使用绑定来描述调用服务的访问机制。服务使用绑定来描述客户端要调用服务必须使用的访问机制。SCA 1.0版本中给出的实现和绑定规范请看表一。


2、SCA使用的情况

SCA规范定义了多种实现和绑定机制。在规范上就保证了不同技术的互通性。也就是说，不同技术定义的服务，通过使用SCA，就可以做到直接的交互。为多平台的应用提供了便利。

这些不同的实现方式和相应的绑定通过在组件（Component）中引入得到支持。通过这种方式就从根本上减少了业务逻辑对实现技术和平台的限制：对于新建的应用，更方便在适合的地方采用适合技术；对重用的应用，也极大程度上减少了新的开发工作。这样一来就可以发挥各种语言、框架和规范的优势，最大限度地采用他们各自的最佳实践，之后可以通过SCA组件组装应用。SCA的组件就象是一个组装适配器，通过SCA组件，把不同技术开发的功能适配到统一的模型下面，进一步完成服务的组装。这个组装结果就是复合组件。

多个组件组装在一起就是复合组件（Composite），复合组件是SCA域中的组装元素的基本单元。在实践中，一个复合组件应该是提供了一个服务的单元，否则就会导致服务的界限不清楚，可重用性下降。为了实现一个完整的业务功能，可能需要多个服务单元配合工作，在SCA规范中这体现在将多个复合组件组装在一起。这里有两层含义，首先，复合组件可以作为一种实现（Implementation）在更高层的复合组件中使用；其次，如果由多个复合组件组装的服务是可发布的，那他们应该在同一个域中对外发布。

将SCA发布出去就需要用到域（Domain）。SCA域完全是一个运行时的概念，可以分布在有联系的多个运行时节点上。域界定了SCA元素可见边界，也就是说，各种SCA规范定义的元素只能在域内直接访问。跨域访问的服务需要通过具有远程寻址的绑定机制来访问，比如通过WSDL提供服务的Endpoint来访问。注意，SCA规范并没有定义什么样的服务应该组装在同一个域内。但是从实践的角度来说，按照业务功能划分域是比较合理的一种方式，同一功能的服务放在同一个域进行组装，这样下来整个应用的层次更加清晰。

SCA规范为解决部署问题，引入了部署单元（Contribution）的概念。一个部署单元是复合组件配置和组件资源的集合。典型的部署单元包括SCA复合组件，配置文件，类和接口定义甚至HTML 文件等等。部署单元可以是某个单独的复合组件或资源目录，也可以是JAR、WAR或EAR存档。

3、SCA在SOA体现中的作用

SCA是目前开发SOA应用中采用的一种比较广泛的技术。遵循SCA这一标准将使SOA应用开发更简单方便。 SCA规范定义了很多实现和绑定的规范，而且SCA的实现和绑定方式是可以自己扩展的。这就使得重用成为可能，通过应用这些规范，可以很容易地从已有系统中抽出可重用的服务，把已有投资转化为可重用的资产。通过SCA，一方面服务的组装者只需要根据接口定义组装服务，而不必考虑服务内部的实现；另一方面，服务的开发者只需要关注各自服务的内部细节，不必考虑和其他服务如何交互。

SCA是一种让开发人员更“懒”的规范。使用SCA开发人员不用学习诸多技术规范，因为SCA规范与各种语言、技术和协议无关。在SCA规范下开发，只需要考虑业务逻辑，不必过分关注技术规范。SCA提供了统一的模型处理对各种技术规范的适配和服务生命周期的管理。

在实践中，通过Spring Bean组织和暴露服务的方式也经常被用来开发SOA应用。与SCA相比，Spring相当于是私有的协议，虽然我们不能否认他在JEE应用中被采纳的广泛程度。另一点就是Spring目前只针对Java平台，不像SCA支持那么多技术平台。注意Spring和Web Services基本是可以无缝结合的。

4、SCA的发展

SCA规范发展这几年来已经有了很多实现。几家SCA的合作伙伴，包括IBM、BEA、ORACLE、TIBCO等，都有自己的SCA实现。开源社区也有比较活跃的SCA实现，包括Apache的Tuscany和codehaus的Fabric3等。

OSGi也是近两年很流行的一种技术。OSGi和SCA结合也是一种趋势。基本的方式有两种，一是按照SCA的实现和绑定规范引入OSGi，二是把SCA作为OSGi的bundle运行。目前开源的Tuscany在2.0的版本（还没有GA版）中正在采用第一种方式实现两者结合。另一个开源项目Newton，采用第二种方式实现SCA和OSGi结合。

SCA规范本身也仍然在快速发展中。其最新成果是事件处理和发布、订阅的装配模型扩展规范。

5、总结

总的来说，SCA确实是一项值得投入精力关注的技术。使用SCA可以很容易的把已有IT投资改进为可重用的服务带来新的价值。同时SCA又是非常包容的技术，在SCA的基本架构下，各种语言、技术和规范都能直接组装。

SCA规范已经发布1.0 版本两年多的时间的，可以说比较成熟了。各种实现也有很多，尤其是Tuscany和Fabric3 这两个活跃的开源实现，更为我们学习和应用SCA规范提供了极大的便利。

现在开始学习了解SCA规范，还不算晚。