osteching.com

SOA杂谈 --- 兼谈J 记

最近在做技术概念验证，为下一个项目做准备。碰巧，这次主要目的就是要检验SOA 适不适合我们下一个项目。由于整个团队对SOA 理解不多，而且选择的目标平台也多少有点灰煮牛，所以这个验证过程多多少少出现了一些问题。本文把这个平台叫做J 记SOA 平台。

J 记有配套的开发工具，有要钱的商业版，也有不要银子的社区版。因为没钱，所以只能拿免费的社区版来用。对我来说这个社区版有两个问题，首先配置约束不够，很多可视化的配置文件编辑，各个配置项属性之间的前后约束都没有，如果不是对J 记平台非常熟悉的话，光靠这个社区版的开发工具，恐怕很难折腾出一个能运行的例子出来。其次，和服务器结合有问题，经常不能直接在IDE 内部迭代发布，严重影响开发效率。也许商业版不会有类似的问题，可惜我没用过，没有发言权。

如果非要加上第三个问题的话，那么我会选择配套的示例和文档。即使我们这个团队和J 记稍微有点关系，拿到了很多收费文档，这些文档的价值也不是那么明显，很多地方版本对应不上，例子不够详细，参数介绍不全面。例子其实还可以，都能正常运行 -_-! 我只是觉得多少有点不够丰富。

总得来说，这个J 记SOA 平台在我看来多少有些山寨。当然这很大程度上是因为我潜意识的就不看好J记 的SOA 平台，希望看到本文的兄弟姐妹们不要受我影响。

老实说，用J 记平台之前，我没想到过居然会花好几天才稍微折腾起来这个东西，虽然我之前一眼都没看过这个平台，但我以为以自己对SOA 的了解，很快上手应该不是件难事。现实是，SOA 确实是个很宽泛的概念，每个平台都有很多自己的技术细节，虽然大体方向是一样的，但是在细节上也很难做到一通百通。所以我觉得，对新手来说，培训真的是一个必要的过程。尤其是对像我们这次这样，想要初次接触就要完整得采用SOA 平台来作为技术解决方案的团队来说。当然培训要有针对性。其实用基本不熟悉的东西来做方案真的是很有挑战性的一件事，不管是对干活的人，还是对客户。干活的人在孤立无援的状态下承担了工期的压力，客户在呗蒙在鼓里的情况下承担了产品是否稳定可用的风险。

还有一个问题之前没有在意过，只是在我们这个特定的技术验证的情形下我才觉得这是个问题。也许是为了清楚也许是为了什么，老外要求每个模块打个包放到J 记平台去部署。我们只是要搞个技术验证，几个很简单的服务，在这个打包思路下，居然有将近二十个包要部署，EJB，ESB，WAR等等。简直无法想象如果生产环境沿用这个思路会是个什么样子。如果真的那样，我一定会在精神病院发个B 文记录一下。

Scala flexible syntax: bad or good?

Scala 风格太多变了，做一件事可以有N 条路，这是好还是坏？

比如声明一个方法：

这方法都可以用 multiply(3) 来调用。当然你完全可以说前一种是把匿名方法赋值给常量multiply。但是在我看来，这只是修辞上的问题，对结果并无影响。如果说上面这种还有说辞，那请看下面的代码：

这两种形式是完全等价的，只是在写法上有区别而已。

在语句分割上Scala 也采取了比较灵活的方式，一行是一条语句，如果想把两条语句放在同一行，可以用分号分隔。上面的常量声明可以像下面一样写在一行：

当然即使分开写成两行，也可以把分号用作一条语句的结束。

上面只是最基本的两点，还有其他的一些诡异的地方。老实说这很大程度上是因为我对Scala 还不是那么熟悉，以致我在刚开始摸Scala 的时候无所适从，嗯，其实刚开始摸什么都是一样-_-!

只有一个参数的方法调可以用 object method argument 的方式，Python 也有类似的情形。不过对Scala，我采用了对待Python 同样的方式，直接忘记这种写法，只记得object.method(argument)，毕竟这和多个参数的写法一致。

还有一处乍看起来很迷惑，但是如果糊里糊涂起来却很自然的地方，Scala 的类型推断。大部分的强类型语言中，我们都习惯于先声明变量的类型，然后再进行操作，像继承自C 的编程语言，基本都是这个路子。弱类型语言不是这样的，弱类型基本是采用了推断的方式，即看变量被赋予了什么样的值。比如看下面的循环：

变量 i 并没有指定是何类型， 但是完全可以通过1、2 来推定是Int 。 很自然不是吗？

使用Scala，既可以写命令式的代码，也可以写函数式的代码。命令式的代码就不用说了，C家族的语言到现在基本都是命令式的。函数式的代码可以把函数作为方法传到函数内，下面是个简单的例子：

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

中小企业如何开展SOA

中小企业如何开展SOA？这是最近半年来我经常被人问起的一个问题。看来经过铺天盖地的宣传攻势之后，大家都认识到SOA 确实可为、确实有价值，现在都想着怎么把它变现了。

考虑这个话题之前，我们先把公司分个类。对于厂商，其实没什么好说的。找准自己的路子，做的比对手更好就是了。嗯，实在找不到可以偷偷给我发个邮件-_- 好了，观众走了大半，只剩下IT 系统买家了。下面几段正是给软件软件使用者提供建议的。

老实说，一个老板几条枪的特小公司，其实真的没什么必要这么早考虑SOA。也许只需要一个Excel 做好账务工作就够了。先把脚跟站稳，生存下来是关键。

现在生存已经不是问题了。业务多了，人也多了，也采购了几套不同的系统。倒霉的是光图便宜，只买贱的不买合适的。同样的东西，这个系统一遍，那个系统一遍，搞的大家天天抱怨。怎么办，买个大而全的NB 系统？把整个公司都搭进去都不够。回过头来想，还是只好在老系统上做文章。一面安抚众人，一面怒斥搞IT 的：赶紧解决，还想不想要饭碗？搞IT 的苦啊，兄弟。好在现在很多软件卖出去都送源码，不知道为什么要送，反正我没送过，恩，当然我的软件也就没人要了。IT 哥们在代码中发现了解决方法，我在这个系统提交的时候，给另一个系统一份不就行了？用数据集成？饶了IT 兄弟吧，那俩系统里的数据比代码还乱呢，一时半会研究不明白。看到这就哦了，套SOA的官话，那边提供一个服务，这边调用就好了。

暴露服务，最开始的入手点。

从上面这一步开始，逐渐的有更多的服务交叉在各个系统之间。这玩意多了就是烦，IT 大哥最近要辞职，临走之前想做个好事，把之前所有的服务都写了个word 文档。敬业啊！其实，这确实是治理的开始，实现了最基本的服务记录和说明。但是这种方式确实又比较原始，查找起来比较累。过来交接的哥们，看着十几页的文档冷汗都下来了。正好交接有半个月的时间，趁这半个月俩人研究了几天有什么好办法把系统玩转。要说人多就是力量大，俩人找了个开源的服务治理工具，把这些都扔里面了。有了规范的工具，立刻世界变得美妙起来，一切都很方便。而且治理工具还带来了监控服务状态等等等等更多的好处。这就是专业的力量。

服务治理，世界美妙的开始。

闻名不如见面

在QQ群里扯久了，就纷纷有了见面对砍的冲动。我觉着这就和上个世纪末，（说起来很远，其实也就十年），聊天软件刚刚盛行之际纷纷扯“网友见面”差不多。
这次应该算是我第三次掺和面对面的群扯活动了。
第一次嘛，是十多个帅的和不帅的哥，围坐在避风塘的一个大桌子周围，挤在一个小屋里了。不知道周围那些人，看我们的眼神是什么样子，只是觉得第一次嘛，激动、害羞、向往，诸多感觉纷纷砸向晕乎乎的大脑，人多，屋小，气闷，缺氧。
第二次嘛，是美女up 组织的怀柔远足吃鱼。我带着老婆在其他单身帅哥美女嫉妒的眼神中，着实吃了不少鱼。爬红螺寺太累，吃饱了才有力气啊。那是和老婆第一次爬山了，依然回忆幸福中。
今次嘛，没有帅哥没有美女了。当年的帅小伙俊姑娘，在打磨技术的同时，也把打扮化妆的时间都扔在了一边。倒是技术上都沉淀的非常夯实。

Alex，对技术对整个市场环境都保持了非常非常高的激情。实在是令我汗颜啊，我已经心态老矣，经常自觉不自觉的得过且过了。这点要经常拿出来检讨一下。
轮子同学集成的经验那叫一个丰富，各种项目背景信手拈来，比我纸上谈兵要强过N 倍。
UP美女是巾帼不让须眉，RIA 的经验实力，不来几个筋斗云那是甭想有歪心思的。当然，想有歪心思，也得先看看旁边她的御用小奴Rosen，Rosen当年携db4o，席卷诸多技术网站之际，我还在一个角落默默的啃着咖啡豆。
满帅依然显得很谦虚，但真的很man，每次发问都问在要穴。
Gopher越发彪悍了，一搭眼眼就知道是东北人，一搭手估计就飞出天外了，当然我也没敢搭手。
还有一位Gopher的同事，不太熟悉，也显得比较腼腆，不过我相信下次再坐在一块的时候，肯定就能放得开了。

本来这次准备了四个topic，但是一开始大家扯的比较开，再加上轮子严重迟到，鄙视之，结果真正开始topic的时候已经快三点了。我的SOA，基本是纸上谈兵的多，好在轮子和Alex项目经验很丰富，让我的topic 血肉大大丰满了。Alex很实际，着眼现实，对SOA 成功案例有多少的发问，让我做为一个SOA粉丝，着实尴尬了不少。UP美女的RIA，确实让我学习了不少，虽然离UI久矣，但是仍然让我震惊于互联网应用对UI细节的精益求精。轮子的Portal案例共享确实大大丰富了我贫乏的项目经验，希望下次有人再问到项目经验的时候，我可以把学到的东东转述出去。本来Rosen还要分享一下最近他们尝试Scrum 的经验，可惜时间有些晚，只好期待下次了。