SOA,不可实现的神迹？

  

我想记录下我这个不太成功的SOA学习和开发过程。

说他不成功，并不单纯指技术上的不成功，还掺杂了许多非技术方面的因素。

我坦白在SOA上我是个菜鸟。一个刚刚准备入门的菜鸟。但又有哪个人不是从入门菜鸟做起的呢。在过去的两周里就像踏进迷宫里，一个接一个的新名词出现，当无论是从网络上Google还是从书籍里人肉Google解释，看个似懂非懂后，接着就是一个又一个的新概念出现在我的面前，然后就不得不再重复上一个工作流程去搞懂这些概念。在这两周里“ www.google.com ”是恐怕是我打得最流利的一个网址了，所以在这里还是要向Google的致以崇高的敬意的。他们的搜索技术总是在我最需要时帮上我的大忙。

虽然我一直在为学习SOA而努力，但这两周的工作却让我感觉迷芒。这不是来自于技术上的，而是来自于非技术的，比如管理或商业考虑。

更改现在有的业务架构为SOA，这个理念是由上一任PM提出的。如果他还在任的话，我想我的处境会好很多。准确来讲是我们组的处境都会好很多。因为我们就是那个传说中的“SM”组。这个有些自谑的称谓来自于我们组英文名称的缩写。系统，侬晓得啊，在英文里就是“System”，那管理呢？我们全称为“System Manage Team”。其实他的缩写完全可以是“SMT”，但不晓得是哪位前辈把他硬是缩成“SM”，可偏偏组内编码规范里要求各小组所负责的Module或DB中的所有Class或Table名前要加上本小组缩写为前缀。于是就是有了打开Oracle就可以看到大量的“SM_”开头的Table，或者是IDE的Project Explorer中大量“SM_”开头类或Package。

有些扯远了。回来再讲我们“SM”组。从组名上你就明白我们是负责什么事情的了吧。SOA的事情自然要我们组负责的多一些。其实这也是一件很激动人心的工作。因为我们组里的每个人都将切深的参与到SOA的具体工作中去。这样也会奠定我们4个人在整个项目组核心地位。因为我们4人在SOA工作上的积极性也是空前高涨的。

但事情往往不能按照人的意愿而发展。因为上层对项目未来的担忧（主要是项目盈利和商业竞争上）迟迟不明确的制定工作计划和实施路线。甚至到现在选型都没有明确。再加之一些新任PM个人认识上的不同，造成现在这样一种现状。一边是我们压力巨大的在学习，另一边不紧不慢，不清不楚的空谈SOA。再加之SOA概念普及好多年，但到现在也没有让我们亲眼见识过什么样的系统才算是符合SOA。就像有那一个先知对你讲有一匹马，是一匹白色的有着纯粹的阿拉伯血统的高头俊马。但这匹俊马却一直存在于传说中，我们没有亲见更不要奢谈能亲手拉一拉它的缰绳。还是真的只要使用了Web Service就叫做SOA么？在那些架构师空谈什么业务拆分，粒度划分等“高深”问题时，有人能明确说一下具体的实施路线和方法么？如果这种情形持续下去，我想，SOA可能依然会是一个只存于“先知”口中的神迹。