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 的初衷。我所说的问题就是，如果团队划分比较细，夸张的说，一个团队只支持一个服务。会出现什么情况？各家自扫门前雪，不管他人瓦上霜。又或者说一叶障目不见泰山，一个团队只看眼前，对整体失去了把握。不管是从优化业务的角度，还是从性能分析的角度，都是不利的。

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

杂记一篇，不知所云。

中小企业如何开展SOA  

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

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

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

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

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

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

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

然后该干嘛了呢？整个企业的IT 系统里已经有大把大把的服务在那了，企业的规模在也上来了，再上新系统那是大把大把的银子出去了。领导就想啊，我现在在都这么多系统了，能不能利用已经有的东西实现新的需求呢？上个月系统流程觉得还很好，这个月又要改了，能不能不重新做，利用已有的东西改吧改吧就适应新的流程呢？要说搞IT 的就是聪明，很快就找到了解决方案。因为之前服务定义的比较合适，暴露的服务也很充分，这些需求都能够通过重新组织服务来完成。这就是服务编排编制的工作。往大里说，做到后面就是很好的业务流程管理（BPM）。

管理流程，快速响应业务需求。

企业变大了。从IT 系统来说，很多系统，很多有用的服务。这些服务在治理系统里面都有注册，但是却分散在多个独立的系统里，系统之间的连接单拎出来还算清晰，如果画个完整的图，就是可怕的错综复杂的网络。从性能上，从管理上，从多个系统交互上，都有很多问题，真是牵一发动千钧啊。有没有办法把这么多服务整合在一起呢？有的，搞IT 的人真是聪明啊—企业服务总线(ESB)。搞过自动化的对总线太熟了，一块板子，一堆插槽，来个新的东西插上去就OK了。往简单里想，其实ESB 也差不多。当然隐藏在简单表面的背后，还有很多复杂的技术细节。不过没事，聪明的IT 伙计能搞定一切。

服务总线，由繁入简统筹交互。

流程管理和服务总线这两者的引入顺序，可以比较灵活。大致的思路是，如果IT 系统是业务流程为主，那应该优先考虑流程管理；如果IT 系统是消息集成为主，那应该优先考虑服务总线。满足最紧迫的需求是第一位的，给将来打下坚实的基础可以稍微往后靠一点。

现在回头来看整个系统的情况，从技术上来说已经是基本完备的了。但是请注意，SOA 不是一个技术问题，SOA 是搭建IT 系统的方法论问题。就是首要的是对服务的理解，用适当的技术完成服务的暴露，然后通过这些服务响应业务变化，满足应用需求。所以，技术基础具备之后，不应该停滞不前，而应该善用这些工具，按照能快速响应需求变化的方向，去逐步演进IT 系统。用SOA 看问题，不是各个孤立的系统，而是各个有价值的服务的集合。它只是手段，赚钱才是目的。

再进一步会怎么样？SaaS 是个方向，或者再进一步叫她云计算。我见过的最贴切的对云计算的定义是：虚拟存储+SaaS。但是对中小企业来说一下就考虑这么远其实没什么必要。当然这里有个快速的切入点，那就是，如果你有一个对全球人民都很有用的内部服务，那不妨把她放到大庭广众之下，按SaaS的路子暴露出去。

CXF和Metro的OneWay实现与JSR-181规范不一致的情况 

最近朋友问我了Web Services中一些关于MEP的问题。在讨论问题的过程中偶然提及了JSR-181规范中的Oneway注解。本来打算直接写一篇MEP的东东，没想到翻看Oneway的过程中发现了规范与实现的某些不符合，于是先有了这篇很短的B文。

先看一下Oneway在JSR-181 v2.0的规范中有着如下明确说明（这段直接引用自规范文档）：

4.3 Annotation: javax.jws.Oneway
4.3.1 Description
Indicates that the given web method has only an input message and no output. Typically, a oneway method returns the thread of control to the calling application prior to executing the actual business method. A JSR-181 processor is REQUIRED to report an error if [...]