《WCF技术内幕》翻译3：第1部分_第1章_蓝月亮:普遍需求和普遍概念

第一部分：WCF介绍
   章节目录：
   第1章：蓝月亮
   第2章：面向服务
   第3章：消息交换模式、拓扑和编排
   第4章：WCF 101

第1章：蓝月亮

   商业和市场对软件系统新的功能性需求看起来无比贪婪。我曾经听到一个产品经理在一个产品发布会后河我说：“这个产品可以做客户想做的任何事情；下一个版本没什么可设计的。我们都会老家吧”。发布日期到来的时候，你最可能听到的就是，“不，这个版本不干不了这个，我们或许可以再下一个版本之后加上这个功能。”在软件的世界里，这些功能性需求偶然的集中到一起，远处看来就貌似一个通用的需求。有时候，其中一个普通的需求就产生了一个携带满足这个通用需求诺言的新的通用概念。一旦时机到来，对新技术的兴趣会推动一个新技术的发展，这个新技术可以使得开发者把这个概念应用到他们的应用中，因此进而可以满足那个通用需求。每次这种百年一遇的时机，通用需求，通用概念和随之而来的新技术如此巨大和重要，迫使我们不得不重新考虑软件的设计。我不确定你是否注意到这些，但是微软WCF的发布影意义重大。是我们应该重新思考如何设计和构造分布式应用的时候了。

普遍需求：
    绝大大部分来说，商业不再去寻求能够解决他们所有计算问题的神奇应用系统。随着时间推移，许多软件厂商，比如打的企业资源规划（ERP）和中间件厂商已经不同程度地成功卖出了这种系统。商业，然而，提出了如此多的需求，以至于没有那个软件厂商的产品可以满足全部需求。此外，随着商业的发展，它们经常需要概念自己的基础结构和流程去适应成长。软件可以在公司100人规模的时候运行，然后却不一定能在1000个员工的时候正常工作。当考虑并购和收购的时候问题会更加复杂。迁移一个收购的公司去使用总公司的软件系统式非常痛苦、乏味和代价昂贵的。

    结果是大部分公司的计算架构包含的是一个既能满足部门级又能满足企业级需求的应用混合系统。这个混合经常被称作非主流架构。最可能是就是这些系统是由内部或者外部的供应商开发，去解决特定的业务问题，并且每个系统都经常管理隔离的信息。偶尔这些非主流架构也被标准化运行在特定的硬件、操作系统和平台上，但是这种标准化通常难以推广。更多的是，这些企业内的计算系统经常由独立的、隔离的应用系统组成，它们运行在不同的硬件，操作系统和平台，为了改进企业的业务（但愿）。如果你看到右边的图片，就也许会记起 M. C. Escher的绘画。

    从商业角度来看，应用系统很少会独立存在，正如他们之间紧密的联系，在某些形态和样子上去帮助商业更加高效地运转。结果，一些人免不了要求，以削减成本、增加销售、或者变相的要求：“我想在应用系统A里知道系统B的一些东西。”这种需求的变现说法就是连接。

    连接很显然有两种方式：应用-应用和应用-企业。只不过，应用-应用是连接两个应用，比如应收账款系统和运输系统。一个应用-企业的例子就是航线想发布每次一个飞机起飞和降落信息给所有关心它的应用系统。这些信息都会深远地影响企业，包括运营，员工调度，和质量保证。人、市场和商业现在的需求关键点就是他们系统之间的连接，这已经非常普遍。不管你为软件厂商还是公司内部IT部门工作，你很可能已经看过这种系统互联的要求。如果这个是你第一次听说，只需要读一些这些主流软件公司的评论，然后记下他们关于未来如软件产品和服务的发布的话。几乎没有例外，你至少会听到和看到关于集成、互联和互操作这些词语。这些都暗示着连接。简而言之，连接时新的普遍需求。
普遍概念
   满足这个普遍需求的任务有点艰巨，特别是当我们想要连接的应用运行在不同的硬件、操作系统和平台的时候。毕竟每个硬件、操作系统和平台有自己的系统、内存管理模式、传输和协议。当深入内部研究大部分组织的非主流架构时，我们需要一种厂商中立的方式。随着时间的过去，工业已经几次试图标准化跨越硬件、操作系统和平台边界的类型系统、内存管理模式、传输和协议。这些包括CORBA, DCE / RPC, RMI, COM+ and DCOM。大部分程度上，从长远来说，每次努力都没有能够获取行业范围内广泛的接受。

    然而，工业已经普遍接受了Internet 极其标准。无一例外，现在的硬件、操作系统和平台能够通过Internet通信。对于Internet标准的接受来自于HTTP, HTML,XML的本来属性。本质上说，基于Internet的通信需要依赖这些标准发送和接受数据而不需要类型系统、内存管理模式或者内部协议。简单来说，Internet 通信关注与传输的数据而不是特定的类型系统、操作系统或者平台。

    底层协议可以抽象化为应用-应用和应用-企业连接提供概念模型。这个名字就是面向服务。面向服务的普遍概念肩负着实现两种形式的普遍需求互联的承诺。面向服务的应用系统关注的是使用特定的结构来发送和接受消息，很像一个网站如何通过Http发送和接受html.那些接受这些消息的应用系统通常被称为服务。

    从商业角度来看,面向服务的普遍需求承诺要简化和提高这些需要连接、版本化和取代应用系统工作的效率。可以通过复用现在系统的功能暴露出来的服务而减少内部开发工作量。此外，服务可以被更新（带有一些约束）而不会被调用它的应用系统察觉这些变化，或者必须更新它本身。例如，一个应用系统要求制定出完成计划，是完全开发一个一样的系统还是使用现有像虚拟地球的服务更便宜呢？可以确定一些特定的情形给出了这个答案，但对于大多数商业应用系统而言，我断言使用像虚拟地球这样的服务会更加廉价，更实用和可靠的选择。理论上说，内部重用别人已经开发、测试和暴露的服务比重新开发和测试相同功能的服务会更加容易、廉价和可靠。此外，只要消息和契约兼容，服务可以更新而不需要关注调用它的服务的变化。这些好处，然而，会需要依赖这个服务。一个服务调用者为了功能需要对服务承担一些责任。如果服务提供者停止或者中断，那些功能都不能够被调用者使用。此外，一些服务提供者限制了调用服务的方式。

    公平地讲，这个故事和组件刚出现的时的情形有些相似。与之前的技术相比组件发展迅猛，但是组件架构也有不足，特别是满足连接行的普遍需求，例如，组件架构需要一个公共平台和操作系统，并且根据组件架构构建的分布式应用系统需要同时更新。这种紧密耦合使得更新组件和底层平台非常艰难。但是这种模型可以工作在应用-应用的连接。但是却不能在应用-企业平台之间的连接。正如你将在本书里看到的一样，面向服务的应用能够使用更加灵活的方式进行版本化，而且是满足两种不同形式连接的普遍需求很好的选择。

    从开发者角度来看，面向服务的概念与实现、平台或者服务本身的运行时相比专注的是消息。发送一个消息从一个应用系统到另外一个应用系统或许看起来没什么大不了的，并且咋一看，并不是连接普遍需求的答案。毕竟，不同外形和大小的应用系统已经穿越大型机的边界发送消息到其它系统。这个概念推广的最大阻碍就是缺少消息框架的共识。软件厂商传统上为自己的工具集合范围里开发它们自己的消息框架，但是这些消息架构从来不会被广泛采纳，结果，互操作性实际上是遥不可及。但是就认为的普遍结构来说什么样子的消息结构是广泛接受的？如果一个消息架构被全世界采用，任何采纳它的应用系统可以与任何其它别的支持此消息结构的应用通信。连接普遍需求的关键在于开发出标准的消息架构和这个架构被广泛采纳。

   那么怎么才能达成消息结构的共识呢？一个可能性就是，像 Microsoft, IBM, BEA, Sun Microsystems还有其它的软件厂商一起工作创建可以互操作的消息结构。考虑到眼前工作的复杂性，它们可能几年时间来研究，几个会议，并且我个人喜欢不停地开会。经过充分的研究，会议讨论（当然，不停地开会），一个标准的消息结构应该被合并或者战斗爆发了，任何一个结果看上去都是非常有趣的。

   最近你或许听说过这个术语： WS-*（读着WS-星）。 WS-*是个规范家族，它定义了不同系统，普遍的消息架构和消息编排。这个规范家族 WS-Addressing, WS-Security, WS-Trust, WS-SecureConversation, WS-Federation, WS-ReliableMessaging, WS-AtomicTransaction, WS-Coordination, WS-MetadataExchange, WS-Policy, and WS-PolicyAttachment。整体上来说，它们代表一种独立与厂商的可以使得应用系统可以进行可靠、安全和事务的通信的方式。这些规范使用基于XML和SOAP的消息结构；它们是由大多数厂商的代表共同撰写而成，并且是很多年经过专家会议讨论的结果。这些规范被广泛采纳，因为许多主流软件厂商已经加入到这些规范的制定中。实际上说，那些主流的软件厂商已经认可了这个标准的消息格式。

   基于SOAP的规范还未制定完成，其它的消息结构已经出现，JavaScript 对象标记（JSON）久是最著名的的例子。JSON大量用于异步JavaScript和XML (AJAX）的Web应用程序，一种浏览器可以回发消息给服务器而不需要刷新整个页面的机制。JSON 与基于XML的消息格式分道扬镳，它是基于javascript eval函数调用，不符合WS-*规范。纯正意义上说，JASON在浏览器和服务器之间的交互是面向服务的。重点就是服务必须认可消息格式。随着时间的流逝，应用系统中的消息格式毫无疑义的会演化以适应不同时代的需求。

参考文章：

The Moon is blue: http://www.chinadaily.com.cn/language_tips/2006-07/18/content_643134.htm