SOA 五年之殇

http://www.artima.com/weblogs/viewpost.jsp?thread=290352

http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html

作者以Thomas Erl 的书籍 Service-Oriented Architecture (SOA): Concepts, Technology, and Design 为标记(2005年发布),定义SOA诞生的这5年.现在回过头来,评价SOA理念的功过.

先说作者的几个观点:

1. SOA,任何人都想要的理想国度,但是没有人能够说清楚这个概念;SOA成了空虚和模糊的代名词
2. 2009年7月,SOA香消玉勋,但是服务这个概念却长存下来
3. 松耦合,基于契约,服务自治,抽象,复用,复合性,无状态,可发现,这些都是SOA的特点和目标
4. SOA当初提出的一些技术已经被废弃,例如WS – notifcations，
5. 服务发现,这个概念早已无关紧要,UDDI早已被废弃
6. 服务组合,已经面目全非
7. REST模式克服了SOA的很多缺点

在我国,SOA的热潮仍然没有完全过去.从我自己的经验来看,SOA无非是更高力度的函数调用,只不过更加的与语言,平台无关而已.

SOA的概念忽悠了多少人栽在里面?

我的教训是,安心做自己的东西,千万不要被外面的喧嚣拉进去,顶多在外面看看热闹即可.

软件架构和软件新特性

当我们说要增加一个软件的心特性的时候,对于一个架构师而言,这意味着什么呢? 根据我的经验,这意味着三件事:

1. 概念的完整性
   一个新特性意味着一个概念的出现,那么首先需要保证是概念的完整性.如果概念是模糊的,那么在实现上就存在说不清,道不明的灰色地带,在测试的结果上就存在不确定性.概念的完整性是基于领域需求的,我们必须完整而准确的把握这些需求,才能保证概念的完整性,定义程序开发的接口规范.
2. 实现的确定性
   如果概念是清晰的,那么实现就是工具支持和自由创造了.操作系统提供的底层实现,领域基础软件提供的既有功能,开源软件的免费实现等,都可以作为我们实现的基础.从头开始,重复发明轮子,不仅是愚蠢的,而且也是不现实的.
3. 测试的正确性
   即便我们可以从方法上,从我们自己的经验积累上,我们可以确保程序的正确性.但是不经过测试的代码,仍然是不让人放心的.

比如说,我们前一段时间要增加地图输出文本格式化的特性,但是经过分析我们发现:在概念上这属于中文处理的问题,在实现方法上有点人工智能的味道,而且还对我们的qt插件实现光圈效果有所影响(淡然我们可以定义为Qt本身的问题).但是这些足以让我们对这个特性的添加持谨慎态度了.

小妞妞最近的几件事情

1. 三月初我们搬家了，小妞妞刚来的时候非常的不适应，经常哭闹，搞的一家人也神经兮兮。大约经过半个月的适应期，她才完全的适应，为此，老婆和我打闹一场，定为我的最大罪过之一。
2. 因为天气冷，因为室内空气质量的原因，老婆强令打开窗户，所以室温很低。小妞妞整个冬天都没有穿过棉衣，现在却要不得不穿棉衣了。其余的还好，就是原来她咬手指头的习惯，现在执行起来有点困难了。
3. 小妞妞现在的作息时间改变了。原来她在我下班以后不会睡觉，一般要等到晚上9点以后才睡，然后第二天很晚才醒。现在是我下班以后，大约7点半左右就睡了，一直到第二天的早上6,7点才醒。基本上她成了我的闹钟了。
4. 几天前，小妞妞大便开始出现干燥的现象。原来她的便便总是希希的，不成形状，现在开始的时候成条状了。这也是我们家的特大新闻之一

概念的完整性和接口设计

当我们要定制一个系统的时候,总是从需求出发,分析抽象,凝练概念,定制接口,实现接口,测试实现,不断的反馈完善.
但是用户的需求总是很复杂的,这往往需要我们去粗取精,去伪存真.当然这不是很容易,一种很常见的情况是,用户提出需求,而我们只是需要简单的修改接口就可以实现.我们该如何做呢?
这里的关键是保证概念的完整性.

昨天我和小孙两个讨论可以作为实例说明这个问题.
场景一:
昨天腾讯的员工给我们提出了这样的一个需求:标注的发布最好可以按照图层分别的发布,这样他们可以在先发布的标注图层上进行编辑,因为他们的进度比较急,而图层数据还没有整理好,他们不想分工的几方出现一边忙碌,一边空闲情况,最好能够并行执行.
这个要求看似很合理,而且小孙给出的实现方案也不复杂.但是我下意识的就反对这个提案,这种下意识的行为是我认为这违反了我们原来设计时候考虑的概念的完整性.
我们原来的设计思路是:标注是由注记转化而成为标注图层的;标注是一种静态的行为,不需要动态的计算显示的位置;在一个特定的比例尺下,只能够显示一个标注图层,否则使用注记显示文本;标注是一个整体的行为,是所有图层在用户控制下的一个整体展现.
而现在,腾讯要求我们把标注的这个整体行为进行分解,这显然违反了我们概念的完整性.
最后经过我们的讨论,认为这样做不仅是损害了概念的完整性,而且还会对用户本身的行为产生危害.因为用户这样做不符合发图的流程,局部范围标注的编辑会对整体的标注的行为产生危害,核心的问题是注记问题是一个整体最优问题,而不是局部最优问题.
概念的完整性不仅是对架构师,程序员,而且也是保证最终用户利益的一个核心问题.

场景二:
RTree的实现在我们内部有几种,在下一个版本中,我和小孙的实现要合并为一.我们实现冲突检测的接口内部就是使用RTree实现的,下一个实现打算使用SQLLite.
SQLLite 是数据库的模式,需要我们在修改之前开始一个事务,修改之后结束一个事务.这样把查询和修改分开,也就是把读数据和写数据分开.SQLLite这样的设计没有问题.
sun的建议是在冲突检测的接口上提出一个begin/end的接口,这样来反映SQLLite的要求.
我也几乎是立即对这个建议持反对意见,理由是:冲突检测和事务特性没有必然的联系,如果仅仅是基于内存的实现,那么就没有了事务的特性.从概念的层面上讲,在使用冲突检测接口的时候,我应该在什么时候调用begin/end的接口呢?我找不到依据.
更进一步说,SQLLite的事务特性只是实现的细节,这和冲突检测接口没有关系,我们不能把实现的细节体现在接口的设计上.
最后我和小孙讨论了一下,基本指定了一个比较满意的设计方案.

在<<人与神话>>中,概念的完整性是不断的被强调的一个核心,我也深有体会.
昨天老程也提到了我们不要被腾讯牵着鼻子走,要有自己的计划的步骤.我们能够坚持自己的设计,维护架构师和程序员的相对独立性,其依据就是概念的完整性.