osteching.com

扩展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: 推荐两个参考资料

SCA 概念、现状和展望

这篇文章是别人的约稿。
发现要在短短的一篇B文里尽可能多讲出内容，真是太难了。

ps：这里算是个预告片，看杂志社情况，如果杂志社不付印，马上就能贴出来，如果要印刷，恐怕要等下个月兄弟们才能看见了。
ps2: 《软件世界》二〇〇九年第七期。

ESB、BPEL、SCA简单区分

就我目前的理解，SCA其实是把其他各种服务引入自己应用的工具。

举例来说，现在有A->JEE(EJB/JMS/..)的应用（服务），B->BPEL(..) process，C->Web2.0 Component(Widget/json/..)，如果现在要做一个建立在A、B、C基础之上的应用，那么SCA是一种最合适的工具，它用类似的方式，把三种不同类型的服务引入系统，避免了维护三种不同服务接口的工作量。
而作为发布服务的工具，SCA其实是不太合适的。

再举例 :-) 已有应用是Web2.0类型的。现在要发布出一个服务，不管我是选择RESTful的，还是widget，还是json，都有相对应的简单工具，为什么我要引入SCA这么大型的工具呢？就好比现在我就想剪指甲，非买个瑞士军刀来剪，我觉得酷，你也看我像装13对吧？（又举例，真是一例解千愁啊）

ESB和BPEL都有他们各自的应用场景，直接拿来和SCA比较并不太合适，而且他们也不是同一层次的工具。ESB是要解决服务通道，BPEL要解决服务流程，SCA要解决服务装配。

BTW: 这篇B文是在一个Google Group里的回帖。贴在这里主要是觉得，还稍微有点价值，而且还有很多可以发挥的点，以后说不定可以做成一篇大大的B文。