SOA杂谈 — 兼谈J 记 

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

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

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

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

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

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

多少有些类似，不过我们这个简单的验证没考虑这么多。在你的生产环境中，你的诸多服务是怎么管理的？是散落在世界各个角落？还是分类整理在一个地方？你知道各个服务运行的情况吗？等等，等等，等，等等等。希望结合上面那个我认为不是问题的问题，会让你联想到服务治理多多少少还真有那么点必要。

软件SOA 化，也可能带来另一个问题。SOA 是以服务为基础的，把提炼出的服务组织在一起，快速影响业务需求，这是SOA 的初衷。我所说的问题就是，如果团队划分比较细，夸张的说，一个团队只支持一个服务。会出现什么情况？各家自扫门前雪，不管他人瓦上霜。又或者说一叶障目不见泰山，一个团队只看眼前，对整体失去了把握。不管是从优化业务的角度，还是从性能分析的角度，都是不利的。

当然我举的例子多少有些夸张了。但我认为，在以上示下的团队组织中，这种情形早晚都会出现。所以给所有团队予应用的整体概念是很必要的。让每个人都知道在做什么，发挥全体人民群众的智慧。

杂记一篇，不知所云。