《WCF教程7》.doc

[原创]我的WCF之旅（7）：面向服务架构（SOA）和面向对象编程（OOP）的结合——如何实现Service Contract的继承 当今的IT领域，SOA已经成为了一个非常时髦的词，对SOA风靡的程度已经让很多人对SOA，对面向服务产生误解。其中很大一部分人甚至认为面向服务将是面向对象的终结，现在的面向对象将会被面向服务完全代替。在开始本Blog之前，我先来谈谈我对SOA和OO的区别，首先申明，这只是一家之言，欢迎大家批评指正，并且关于SO的谈论不是本Blog的主题，只是主题的引子，在这里只是简单讨论而已 。 OO和SO之间具有共同的部分，在运用的领域上存在交集，只有在基于他们交集层面上谈论谁是谁非才有意义，下面是我对SO和OO的区别。 OO关注的是如何通过对实体属性和行为的封装来重塑模拟软件环境的真实实体。对SO关注的则是对现实生活的某个任务、功能的实现，说得通俗点，就是如果做好一件事情。所以对象是对Data和Behavior的封装，而Service则只是体现了一个Functionality。Service是粗粒度的，这样才能导致Contract的稳定；Service一般是Stateless的，给定什么样的输入，就会有对应的确定的输出；Service是Autonomous，基本上的实现封装在Service本身之中，这样可以使它对其它的Service产生最小的依赖。所以对Service建模是一件不太容易的事情：Service不能太大，否则实现起来不容易，还会增加对外界的依赖；也不能太小，否则整合这个Service的成本会令你望而却步。 Service是可组合的（Composable），通过整合相关的单独的，完成某个单个Task或者Activity的小的Service，可以很容易产生一个大的Service，这个Service可以完成一个Functionality的整个流程。比如我们现在把一个Task描述成一个Work flow，如果采用SO的原理来建模，我们可以把组成这个Workflow的单个Activity设计成一个service, 然后根据具体Workflow的特点（比如可能是一个简单的Sequential workflow，也可能是一个基于State machine的workflow）加上相关的条件很容易的把这些Service整合起来，实际上通过整合集成，我们生成一个新的Service。对OO，由于他面对的是一个的Object，具体在分布式中是一个个的Distributed object，要建立一个Composable object则很难（实际上这样也没有什么意义）。 在OO的概念中，一个Object的属性往往就是另一个Object，一个Function的实现往往要调用另一个Object的方法，而且这种层次结构可以无限延伸。这样就会导致真个Object体系变得异常脆弱，经常造成牵一发动全身的状况。用一个很时髦的词语来表达的，就是紧耦合（Tightly couple），Object之间的强依赖关系促成了这种紧耦合的、脆弱的体系结构。而OS则不一样，由于 构成Service体系的单个Service是自治的，Service之间的调用（调用的这个词语容易让人联想到RPC，如果找一个比较贴切的词语来代替，我觉得consume比较合适）是基于Contract的，Service之间Communication是通过Message的（Message不仅仅是Data的封装，还是对整个调用的描述，同时基于XML的Message描述和Message的传递都是符合一个开放的标准的），所有这些成就了SO的松耦合（Loosely couple）。 说了这么多，可能大家都觉得我都是在赞扬SO，都贬低OO。其实不然，上面所说的3个方面都是在讲应用的构建，而不是具体的编程模式。我想表达的是，曾经盛行的基于OO的理论，在企业应用构架方面，已经不能满足我们的需要了，我们迫切希望一种全新的理论来指导我们进行企业应用的构架和集成，而这个理论非SO不可。 而在编程模型层面，OO仍然是不可替代的编程模式。所以OO应用于Programming，而SO则更多地运用在Architecture。既然是这样，我们必须有一种调和剂来调和这两个运用不同原理的两个层面的差异，实现他们之间的无缝的结合。比如如何来对继承，多态，重载等基于OO行为的支持。在这方面，WCF为我们提供了很好的解决方案。所以我说WCF不但是为基于SOA的应用架构提供了技术支持，还通过相关的机制完成我们提出的这个“调和剂”的使命。 在上一篇文章[原创]我的WCF之旅（5）：面向服务架构（SOA）对面向对象编程（OOP）的支持——如何实现Service Contract的重载（Overloading）中，我们谈