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

第1章:蓝月亮

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

注释:The moon is Blue,月亮是蓝色的:这个话需要了解西方国家的文化背景,这个表示千载难逢或者百年一遇的事情。通常是极少有的影响巨大的事情,具有化时代的疑义,比如相对论的提出。人类第一次登月等等。作者使用这个标题来强调WCF的出现具有深远的意义。详细参才文章末尾文章的解释。

普遍需求:

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

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

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

连接很显然有两种方式:应用-应用和应用-企业。只不过,应用-应用是连接两个应用,比如应收账款系统和运输系统。一个应用-企业的例子就是航线想发布每次一个飞机起飞和降落信息给所有关心它的应用系统。这些信息都会深远地影响企业,包括运营,员工调度,和质量保证。人、市场和商业现在的需求关键点就是他们系统之间的连接,这已经非常普遍。不管你为软件厂商还是公司内部IT部门工作,你很可能已经看过这种系统互联的要求。如果这个是你第一次听说,只需要读一些这些主流软件公司的评论,然后记下他们关于未来如软件产品和服务的发布的话。几乎没有例外,你至少会听到和看到关于集成、互联和互操作这些词语。这些都暗示着连接。简而言之,连接时新的普遍需求。

时间: 2024-12-03 03:55:54

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

《WCF技术内幕》翻译15:第1部分_第3章_消息交换模式、拓扑与编排:消息拓扑

<WCF技术内幕>翻译15:第1部分_第3章_消息交换模式.拓扑与编排:消息拓扑.消息编排和本章小结 消息拓扑 消息拓扑描述的是在一个或多个发送者和接受者之间消息如何发送的.消息拓扑可以描述简单的应用-应用的连接关系,但是它同样可以描述复杂的应用-企业的连接.在后续文章里,面向服务的应用的作用会显现出来.概括地说,这些可能存在的拓扑结构比面向组件的应用系统能够涉及到的情况会更加多.更加复杂. 某种层次上,一个消息拓扑是一个或者多个消息交换模式(MEP)的组合.实际上可能存在有无数种拓扑结构,但

《WCF技术内幕》翻译14:第1部分_第3章_消息交换模式、拓扑与编排…

<WCF技术内幕>翻译14:第1部分_第3章_消息交换模式.拓扑与编排:消息交换模式(MEP) 第3章:消息交换模式.拓扑和编排 当设计消息应用系统的时候,有必要考虑一下消息是怎样在发送者.中介者 和接受者(前面章节介绍了这些消息参与者)流转的.系统中消息交换可能性的 波动的值可以被不同程度地详细描述.这些不同级别的细节就是总所周知的消息 交换模式(MEPS).消息拓扑和消息编排[老徐备注1].当从总体来看时,这 三个级别的细节让我们抽象地描述任何消息场景.本章会详细剖析消息交换模式 (MEP

《WCF技术内幕》翻译6:第1部分_第2章_面向服务:概述、快速定义…

<WCF技术内幕>翻译6:第1部分_第2章_面向服务:概述.快速定义面向服务.理解消息 概述 互联网上充斥着面向服务(SO)的对话,大部分会话都是抽象地描述为面向 服务.这一章我们会一些不同的方法.下面一些章页,我们会站在需求的角度看 一下面向服务.更具体地说,我们将看一下一般的消息应用和需要什么才能使他 们运转.通过这个过程,我们将发掘几个理解面向服务必需的几个概念.本章的 最后几段会给出面向服务的比较正式的定义,并且会讨论一下为什么当今世界里 面向服务对于分布式计算意义重大. 如果你问10

《WCF技术内幕》翻译1:《WCF技术内幕》目录和作者简介

翻译序言: 我现在推荐一本很好的WCF学习书籍:<Inside Microsoft Windows Communication Foundation>.Justin Smith先生所著.2007年出版至今,在亚 马逊网站上评价也比较高.综合评价4星半.是一本不错的深入学习WCF的书籍. 我在搜索了很久以后,发现这本书目前还没有中文译本.随计划翻译.分享给国 内的WCF技术爱好者.翻译工作对我个人也是一次新的尝试,希望这本书的翻译 能给大家的学习带来帮助.另外如有技术问题或翻译不当,都可以留言交

《WCF技术内幕》翻译2:《WCF技术内幕》绪论

总述 服务是现代软件架构的一个主要部分,WCF是构建基于Microsoft Windows系 统的服务程序平台.WCF编写的服务可以与其它供应商的服务交互(例如, IBM, BEA, and Novell),WCF为行业标准的演化提供了足够的空间.对于传输,WCF 支持TCP/IP.HTTP. Microsoft消息队列 (MSMQ).命名管道.WCF同样支持一系 列WS-*规范(读作WS-星)协议,比如WS-Addressing, WS-ReliableMessaging (WS-RM), W

WCF技术内幕

<WCF技术内幕>39:第2部分_第7章_通道管理器:通道工厂和本章 <WCF技术内幕>38:第2部分_第7章_通道管理器:通道侦听器 <WCF技术内幕>37:第2部分_第7章_通道管理器:概述和通道管理 <WCF技术内幕>36:第2部分_第6章_通道:创建自定义通道和本章 <WCF技术内幕>35:第2部分_第6章_通道:通道功能 <WCF技术内幕>34:第2部分_第6章_通道:通道接口和基本类型 <WCF技术内幕>33:

《WCF技术内幕》26

<WCF技术内幕>26:第2部分_第5章_消息:Buffered vs Streamed.序列化和反序列化消息 Buffered vs. Streamed消息 当我们在终结点之间流动的消息时,我们会本能地想到缓存.换个方式来说 ,我们假设程序接收到一个Message时,它已经知道整个Message.这种方式称作 缓存模式(buffering).与之相对的就是流处理模式(streaming),并且有2种 流处理模式(streaming).第一种是推模型(push model),发送者按照自己 的

《WCF技术内幕》23

<WCF技术内幕>23:第2部分_第5章_消息:XmlDictionaryReader和回到Message XmlDictionaryReader类型 XmlDictionaryReader抽象类型继承自System.Xml.XmlReader,因此继承了很 多XmlReader的特性.和XmlReader 一样,XmlDictionaryReader定义了几个工厂 方法,他们返回的是XmlDictionaryReader的子类型的实例.更确切地说, XmlDictionaryReader包装

《WCF技术内幕》翻译5:第1部分_第1章_蓝月亮:WCF介绍和本章小结

WCF介绍 在上世纪90年代微软和其他公司看到了互联的普遍需求和面向服务的普遍概 念.那时,还没有被普遍接受的消息标准,结果,就没有平台.应用程序编程接 口 API.或者能够让开发者轻易创建面向服务的应用系统的运行时环境.技术上 说,是可以创建面向服务的应用,但是开发工具和运行时环境的功能使得这一切 看来相当困难.幸运的是,微软和其他厂商开始定义一个可以产生统一消息结构 的基础架构.最终努力的结果就是WS-*规范.于此同时,微软也在制定可以给开 发者提供他们开发支持WS-*规范的面向服务应用的开