Michael Chai

I am SErVice-oRienTed !

  博客园 :: 首页 :: 博问 :: 闪存 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理 ::
  25 随笔 :: 8 文章 :: 62 评论 :: 2 引用
 

Metaphor: bridge to the unknown. – Object thinking

就像Object thinking那本书中所说的那样,“比喻: 通向未知的桥梁”,同样,我们在学习新技术和新名词的时候也可以通过打比喻,作对比来达到知晓的目的。那么比喻为什么能够帮助我们呢?那是因为,人们总对于自己熟悉的事物比较能够理解。通过比喻和对比,在新事物与旧事物之间建立快速联系,就能够帮助我们了解新事物的特征。

 

好了,本文的读者不需要太多的技术功底,只需曾经使用OOD进行过系统设计过即可,当然,如果你对OOP, OOAWeb Service有所了解,那就更好了;如果你已经对SO了解,那么不必读下去了。

 

我们总是在改变,我们的世界如此,我们的系统也是如此。那么当SO出现在我们的世界里,我们就会问了,”OO被淘汰了吗?,“SO能够解决OO解决不了的问题吗?”

 

如果第一个问题答案为是,而第二个问题答案为否,那么SO就没有任何存在的必要了,换句话说,我也不在这给大家介绍了。

 

好,“OO被淘汰了吗?”首先我们来看一个图

这个图很清楚地表明了我们使用OO进行系统开发的特征,也就是说,其实我们的系统就是通过将不同的对象进行引用而形成的。

好,我们再来看另一个图

 

 

那么有人会说了,SO不过是OO的一个扩展吧?

如果说系统是真理的话,那么OOSO是系统在设计世界中不同的模型折射,因为我们都知道,真理是立体的,它有不同的呈现方式,我们每个人看到它的不同的方面。

好像目前为止,我没有对上述问题做出任何正面的回答,其实答案已经有了,那就是“否”,OO没有被淘汰,我们只是对于系统的认知更进了一步,我们看到了系统的另一面。SO也不是对于OO的扩展,因为就好比宏观经济学和微观经济学之间的关系,你不能说前者是对于后者的抽象,而后者是对于前者的扩展一样。

不同的人看同一个事物,会有不同的观点和印象,对于一个实现了的系统而言,程序员因为看到自己写的代码只不过是些贴上标签的C#类,因此他们坚持认为这是OO; 架构师会说,我设计的是符合SOA所有的特征的,因此我坚持认为这是SO。这也就是现在对于SO的认知如此的模糊的原因。

 

通过这两张图我们可以清楚地知道,SOOO都是系统的在软件模型设计中的一个影射,因此不存在谁淘汰谁的问题,他们是可以共存的,我们的系统中既有对象的存在,也有服务的存在,面向什么的设计,编程都是一个分析,实现者的哲学观的问题。

 

好了,我们知道OO不会被淘汰,后果不严重,大家很欣慰。

 

那么,“SO能够解决OO解决不了的问题吗?”

对于这个问题,让我们来了解一下SO的基本原则,这就是 边界强制性、自制性、契约性以及Policy-based兼容性。接下来逐一解释。

 

边界强制性

在服务的世界中,每个服务之间的边界是清晰的,并且是强制的。对于一个系统,你一眼看过去,有多少个服务在那里都很清楚。而且,服务边界是通过消息来勾连的。我们可以把消息看成水,把服务看成鱼,把系统看成鱼缸。每条鱼都是独立存在的,通过水来组合成一个鱼缸。

SO系统中,跨过每个服务的边界进行调用是有成本的,我们会很清楚;但是在OO的分布式系统中,我们很容易把一个远程的对象当作本地对象来对待,很可能导致远程对象被过度使用。这就好比你到超市最好列个购物清单,以免超过预算;而到一般的便利店则不必担心这个问题。

 

自制性

每个服务内部都是自制的。也就是说,系统中的某个服务被部署,升级和修改,都不会影响到整个系统被重新建立。

而在OO建立的分布式系统中,我们可以知道,某个对象库往往是以原子级别单位被部署,升级和修改的,那么由于耦合的程度高,并且对象库之间的调用没有明确的边界强制性,就会导致整个系统需要重新建立。

大家有多少次觉得,维护一个现有的系统比重新写一个同样的系统要来得困难呢?

 

契约性

服务之间通过议定的纲要来传递数据通过契约来特定化行为。那么OO的世界里呢?那是通过类型和类来传递的。

某个服务对外交换信息的时候,仅仅告诉别的服务,“我能够做到什么”,“我仅能够做那些我已经声明过的事情”;也就是说,服务是根据自身的能力来暴露数据和契约的。

OO则要求整个系统类型的同一化, 而这个同一化的过程是通过类型和类来恒定的。

 

Policy-based兼容性

Policy干了什么? 呵呵, 它抽象了一下。 (记得C++沉思录中说过一句经典的话,那就是OO真正的威力在于抽象。)那么它抽象了什么?它把服务与交互之间的约束抽象了出来。难理解?这么想,举个例子,服务为什么能够和传统的Web服务交互?就是因为大家都基于相同的策略。

 

那么,SO又有些什么优势呢?

最大的好处就是系统松耦合,那就有了弹性和适应性。我们可以这么想,把SO想象成一个巨大的架构模式,它有一些规则,它把原有的在被反复使用的模式融合起来,让我们在架构系统的时候基于一个准确的大前提和一套简单的规则,而自由发挥。

 

现在可以来回答这个问题了,SO能够解决OO不能够解决的问题,从宏观上说,SO给与架构系统更简单的规则,大家都知道,简单意味着更不容易出错,而OO给与我们过于自由的尺度,这也是为什么现有多数系统糟糕、杂乱的原因;从微观上说,SO甚至比OO提供给我们更多的设计自由,我们能够将现存所有的技术,基础结构统统放到我们的方案中,而不必关注技术和基础结构的实现细节。

posted on 2006-10-28 14:42  cp  阅读(4945)  评论(3编辑  收藏