12,166
社区成员
发帖
与我相关
我的任务
分享[翻译] Web服务的过去、现状和展望(上部）part1
Web Services的过去、现状和展望 (上部)
原文出处: http://webservices.org/article/articleprint/663/-1/24/
原文标题: The Past, Present and Future of Web Services, part 1
作者：Uche Ogbuji 原文发表日期：2002年9月28日
翻译者：陈剑(jchen@263.net) 译文发表日期：2002年10月10日
版权申明：
本文的英文版版权归原文作者Uche Ogbuji和WebServices.org所有
本文的中文翻译版版权归陈剑所有
未经版权人允许，禁止将本文用于任何商业性质的场合。
***** 欢迎转载，但请保持本文的完整性 *****
Note: 需要本文PDF版本的朋友，请通过jchen@263.net和我联系。
[简介]
对Web services的大肆宣传(hype)已经接近顶峰，它成为了当前流行媒体最喜欢的炒作对象。这种宣传攻势同其它技术在全面开发和走向成熟前的状况没什么两样。不管媒体的兴趣如何，Web services毫无疑问是一项发展前景颇为看好的重要技术。那些对Web Services出现的动机、某些特定技术胜于竞争者的原因以及Web Services可能的技术成熟途径有透彻理解的公司和开发人员将在Web Services的使用方面获得成功。
正是基于这样的原因，我将以Web Services的历史作为开篇。这并非出于怀旧的目的，Web Services得以孕育的商业和技术环境以及在其发展历程中盛衰无常的参与者（公司或者组织）都将对Web Services的未来产生重要的影响。你也许已经注意到了这一趋势，比如类似结构化信息标准推进组织（OASIS）这样的团体正在扮演为Web Services制定安全、工作流和事务处理等协议标准的角色。有趣的是，OASIS曾经被看成是Web Services主流技术的反对者。
[Web Services的表演舞台]
分布式应用的开发在传统计算技术由集中式的主机计算向对等的小型计算机和工作站网络过渡阶段开始就成为了重要的发展领域。在这一趋势的发展过程中，IT经理仍旧是其所在领域的专家。分布式开发的战略被限制在IT经理接受必要的输入并向管理层提交必要的报告。运行和维护一个良好集成的数据中心才是关键，而对异步平台和环境的支持显得并不那么重要。在这种状况下，诸如电子数据交换(EDI)这样的部门在企业中通常是作为一个完全独立的实体而存在。
虽然几乎所有的Web Services的技术基础都是从小型机时代发展起来的，但是由于某些原因，在分布式计算的历史上，小型机时代却经常被人忽略。这大概是因为在同一时期PC的革命性崛起掩盖了小型机时代的光芒。但是直到Internet投入广泛商业应用之前，PC并未对分布式计算领域做出什么突出的贡献。为了组织并提高数据中心的可伸缩性，服务被分散到多台工作站上，这就要求一系列包括同步和异步方式在内的通讯机制和底层应用集成机制。结果，这一时期流行的体系架构和操作系统（比如，DEC VMS、Tandem、HP以及Sun的Unix系统）开发出的分布式消息通讯(distributed messaging)技术，其复杂程度即使在今天看来也让人咂舌。
IBM携MQSeries进入分布式消息通讯领域的时间稍晚。在看到要求应用能运行在从小型机直到其大型主机上的需求之后，IBM收购了当时流行的ezBridge软件，并在其基础上开发出了MQSeries。MQSeries从那个时代起就独领风骚，直到现在。然而，消息通讯技术要求已经习惯了过程化编程语言的程序员们以全新的思路看待和解决问题。程序员却希望以自己熟悉的简单的函数调用方式来访问远程的过程。在80年代末期，分布式计算环境(DCE)的推出试图将多个相互竞争的远程过程调用技术标准化。这一努力有意忽略了消息通讯技术，并且主要由于政治方面的原因，DCE并未获得业界的广泛支持。此时，新一代（但并不一定更好）的分布式计算技术开始涌现。
这个时期，IT经理们开始跻身公司管理高层，信息系统也成为公司战略的基础，在投资预算中所占的比例日渐增长。组织中的现实意味着大部分公司的计算技术重点不再局限于单一的数据中心，与此相反，各类部门级的系统呈爆炸性增长。系统集成代替单一平台标准成为技术选择中最重要的考虑因素。IT经理们现在寻求的是网络技术的标准化。因为面向对象技术许诺的可管理性、代码重用、降低成本以及提高投资回报率等等好处，IT公司们开始采用对象系统作为软件开发的标准。由此带来的结果是，这一阶段涌现的分布式技术都打上了深深的对象技术的印记。
和DCE一样，CORBA(通用对象请求代理体系架构)也是业界联盟试图对分布式过程技术进行标准化的产物。这一次，规模庞大的对象管理集团（OMG）将重点集中在跨平台应用中远程对象的访问请求之上。由于CORBA试图使对象状态和生命周期的管理透明化，因此在可伸缩性上不如消息机制和DCE理想。同样的问题也困扰Microsoft推出的与CORBA竞争的远程对象协议：组件对象模型(COM)和分布式组件对象模型（DCOM）。与此同时，e-mail和Web被证明是有史以来最成功的分布式体系架构，其设计者采用的分布式开发技术充分利用了消息通讯技术和Internet的普遍连通性。各大厂商出于降低风险的目的，普遍支持这些标准。
在同一时期，其它专业化的分布式技术也相继出现。Java的流行导致了RMI(远程方法调用)协议的出现。在MQSeries获得成功后，Microsoft和Java也推出了自己的消息通讯技术。
在新千年来临之际，基于信息系统的需求和网络技术的经验积累，新一代的分布式计算技术呼之欲出。人们对于分布式计算技术的要求包括：
*适合单一应用中的分布式操作以及不同应用间通用服务的调用。换句话说就是能够同时支持开发人员和系统集成商。
*适合组织内部以及组织间的信息交换，要求跨平台支持和数据驱动（data-driven）。
*尽可能与现存的Internet基础设施和谐共处。
*在节点数、异构节点数以及节点复杂度增加时，具有良好的可扩展性。
*有力的国际化支持。
*容错性。节点紧耦合的网络通常存在单点失效的问题，在分布式系统中这一问题更加严重。
*对来自流行厂商的通用软件开发和商业流程管理工具的有力支持。
*在支持最简单的请求/响应机制的同时，在必要的时候也提供对复杂的流程协作、事务和安全性支持。
原文出处: http://webservices.org/article/articleprint/663/-1/24/
原文标题: The Past, Present and Future of Web Services, part 1
作者：Uche Ogbuji 原文发表日期：2002年9月28日
翻译者：陈剑(jchen@263.net) 译文发表日期：2002年10月10日
版权申明：
本文的英文版版权归原文作者Uche Ogbuji和WebServices.org所有
本文的中文翻译版版权归陈剑所有
未经版权人允许，禁止将本文用于任何商业性质的场合。
***** 欢迎转载，但请保持本文的完整性 *****
Note: 需要本文PDF版本的朋友，请通过jchen@263.net和我联系。
[简介]
对Web services的大肆宣传(hype)已经接近顶峰，它成为了当前流行媒体最喜欢的炒作对象。这种宣传攻势同其它技术在全面开发和走向成熟前的状况没什么两样。不管媒体的兴趣如何，Web services毫无疑问是一项发展前景颇为看好的重要技术。那些对Web Services出现的动机、某些特定技术胜于竞争者的原因以及Web Services可能的技术成熟途径有透彻理解的公司和开发人员将在Web Services的使用方面获得成功。
正是基于这样的原因，我将以Web Services的历史作为开篇。这并非出于怀旧的目的，Web Services得以孕育的商业和技术环境以及在其发展历程中盛衰无常的参与者（公司或者组织）都将对Web Services的未来产生重要的影响。你也许已经注意到了这一趋势，比如类似结构化信息标准推进组织（OASIS）这样的团体正在扮演为Web Services制定安全、工作流和事务处理等协议标准的角色。有趣的是，OASIS曾经被看成是Web Services主流技术的反对者。
[Web Services的表演舞台]
分布式应用的开发在传统计算技术由集中式的主机计算向对等的小型计算机和工作站网络过渡阶段开始就成为了重要的发展领域。在这一趋势的发展过程中，IT经理仍旧是其所在领域的专家。分布式开发的战略被限制在IT经理接受必要的输入并向管理层提交必要的报告。运行和维护一个良好集成的数据中心才是关键，而对异步平台和环境的支持显得并不那么重要。在这种状况下，诸如电子数据交换(EDI)这样的部门在企业中通常是作为一个完全独立的实体而存在。
虽然几乎所有的Web Services的技术基础都是从小型机时代发展起来的，但是由于某些原因，在分布式计算的历史上，小型机时代却经常被人忽略。这大概是因为在同一时期PC的革命性崛起掩盖了小型机时代的光芒。但是直到Internet投入广泛商业应用之前，PC并未对分布式计算领域做出什么突出的贡献。为了组织并提高数据中心的可伸缩性，服务被分散到多台工作站上，这就要求一系列包括同步和异步方式在内的通讯机制和底层应用集成机制。结果，这一时期流行的体系架构和操作系统（比如，DEC VMS、Tandem、HP以及Sun的Unix系统）开发出的分布式消息通讯(distributed messaging)技术，其复杂程度即使在今天看来也让人咂舌。
IBM携MQSeries进入分布式消息通讯领域的时间稍晚。在看到要求应用能运行在从小型机直到其大型主机上的需求之后，IBM收购了当时流行的ezBridge软件，并在其基础上开发出了MQSeries。MQSeries从那个时代起就独领风骚，直到现在。然而，消息通讯技术要求已经习惯了过程化编程语言的程序员们以全新的思路看待和解决问题。程序员却希望以自己熟悉的简单的函数调用方式来访问远程的过程。在80年代末期，分布式计算环境(DCE)的推出试图将多个相互竞争的远程过程调用技术标准化。这一努力有意忽略了消息通讯技术，并且主要由于政治方面的原因，DCE并未获得业界的广泛支持。此时，新一代（但并不一定更好）的分布式计算技术开始涌现。
这个时期，IT经理们开始跻身公司管理高层，信息系统也成为公司战略的基础，在投资预算中所占的比例日渐增长。组织中的现实意味着大部分公司的计算技术重点不再局限于单一的数据中心，与此相反，各类部门级的系统呈爆炸性增长。系统集成代替单一平台标准成为技术选择中最重要的考虑因素。IT经理们现在寻求的是网络技术的标准化。因为面向对象技术许诺的可管理性、代码重用、降低成本以及提高投资回报率等等好处，IT公司们开始采用对象系统作为软件开发的标准。由此带来的结果是，这一阶段涌现的分布式技术都打上了深深的对象技术的印记。
和DCE一样，CORBA(通用对象请求代理体系架构)也是业界联盟试图对分布式过程技术进行标准化的产物。这一次，规模庞大的对象管理集团（OMG）将重点集中在跨平台应用中远程对象的访问请求之上。由于CORBA试图使对象状态和生命周期的管理透明化，因此在可伸缩性上不如消息机制和DCE理想。同样的问题也困扰Microsoft推出的与CORBA竞争的远程对象协议：组件对象模型(COM)和分布式组件对象模型（DCOM）。与此同时，e-mail和Web被证明是有史以来最成功的分布式体系架构，其设计者采用的分布式开发技术充分利用了消息通讯技术和Internet的普遍连通性。各大厂商出于降低风险的目的，普遍支持这些标准。
在同一时期，其它专业化的分布式技术也相继出现。Java的流行导致了RMI(远程方法调用)协议的出现。在MQSeries获得成功后，Microsoft和Java也推出了自己的消息通讯技术。
在新千年来临之际，基于信息系统的需求和网络技术的经验积累，新一代的分布式计算技术呼之欲出。人们对于分布式计算技术的要求包括：
*适合单一应用中的分布式操作以及不同应用间通用服务的调用。换句话说就是能够同时支持开发人员和系统集成商。
*适合组织内部以及组织间的信息交换，要求跨平台支持和数据驱动（data-driven）。
*尽可能与现存的Internet基础设施和谐共处。
*在节点数、异构节点数以及节点复杂度增加时，具有良好的可扩展性。
*有力的国际化支持。
*容错性。节点紧耦合的网络通常存在单点失效的问题，在分布式系统中这一问题更加严重。
*对来自流行厂商的通用软件开发和商业流程管理工具的有力支持。
*在支持最简单的请求/响应机制的同时，在必要的时候也提供对复杂的流程协作、事务和安全性支持。
...全文
请发表友善的回复…
发表回复
