扩展Tuscany binding 的注意事项 

最近在琢磨着整个BlazeDS的SCA binding出来，Tuscany 用的顺手了，自然就用Tuscany 来做SCA 实验。虽然因为从BlazeDS 中扒代码出来遇到了点困难，但是扩展Tuscany Biding 的思路已经理清，所以先写这么一篇来灌水。本文不涉及BlazeDS 的部分，只是列出几个兄弟在实现Tuscany Biding 中遇到的容易被忽略的地方。

0/ targetNamespace 在各处要保持一致

其实理由很简单，目标命名空间一致才能找到东东嘛。但问题是这个targetNamespace 分散在各处，而又没有统一的维护工具，目前的IDE 工具做的也不够好。嗯，当然也可能是我比较圡，没找到好用的工具。我的case 比较简单，就三处有targetNamespace：composite 配置文件，/META-INFO/services底下的ValidationSchema 和 StAXArtifactProcessor。

1/ 是否真有必要实现StAXArtifactProcessor

如果扩展的binding只要配置一些基本的属性，完全可以用org.apache.tuscany.sca.assembly.xml.DefaultBeanModelProcessor 来完成配置的解析，没有必要实现自己的StAXArtifactProcessor。比如，我的就一个uri 要配置，DefaultBeanModelProcessor 完全可以做这事了。注意：此项配置要保留，否则会杯具的。

2/ 尽量提供ValidationSchema

ValidationSchema 是用来保证Binding 使用者正确使用你的扩展的校验机制。如果提供了足够多的校验，并且提示信息都很友好，使用者很容易就能完成一个自我学习的过程。

3/ 实现ModuleActivator 不是必须的

ModuleActivator 是模块加载过程的第一步。如果扩展模块在加载过程中不作什么特殊动作，比如注册扩展点，完全可以不提供自己的ModuleActivator，用默认的就可以了。

4/ 心思细致

自定义扩展模块时必须要心思细致，因为有太多的配置，而且都是约定性的。

ps: 推荐两个参考资料
0/ 这是极少的参考之一， http://tuscany.apache.org/sca-java-extension-development-guide.data/ExtendingTuscany1.pdf
2/ Tuscany 源代码，各类扩展都可以找到对应的模块来参考。

SCA 现状和展望

今年年初的一篇《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版本中给出的实现和绑定规范请看表一。 表一：SCA 1.0版客户端/实现和绑定规范 Client and Implementation Binding Java Component Implementation Web Services Binding Spring Component Implementation JMS Binding BPEL Client and Implementation [...]