| 出版日期：2002-03-11 总期号：1099 本年期号：16 |
|
 |
2002年网络服务来敲门
邓侃 曾有一篇题为“2002：.Net 年”的文章写道：微软观察家们料想2002年或许会成为.Net年。因为微软准备推出一批产品使它的“软件就是网络服务”的远见变成现实。 微软的竞争者们不会同意这样的提法。原因有两条，首先，.Net只是微软的战略，微软以外的世界远没有认同。即便有产品，未必有市场。其次，“软件就是网络服务”并不是微软的独家远见，而是许多公司和研究机构的共识。 网络服务将取代应用程序 网络服务的对立面是安装在各台计算机上的应用程序。比如说，如果用户需要查询从A地到B地如何开车，他有两个办法，第一，他可以买一套地图软件，安装在他的计算机上，然后查询开车路线。或者，他也可以用浏览器访问http://maps.yahoo.com，然后输入A地址和B地址，http://maps.yahoo.com 会显示相应的路线。第一个办法用的地图软件就是一个应用程序，而第二个办法访问的http://maps.yahoo.com 则是一个网络服务。 “软件就是网络服务”强调的是，当今的许多应用程序将来会被网络服务替代。这是因为，相对于应用程序，网络服务有很多好处。首先，网络服务不需要用户安装应用程序，而安装调试往往是容易出错的。第二，当地图系统需要更新时，网络服务通常只需要更新一次，即把服务器端的系统更新。相反，如果不用网络服务，每个应用程序的用户都必须更新他的安装。第三，为了提高质量或者其他目的，无论网络服务或应用程序的开发商都希望收集用户的使用情况，这对网络服务来说比较容易，而对应用程序就很困难。比如某些系统为了收集用户使用情况，而设计了后门，结果引起用户极大反感。第四，如何防范盗版是每个应用程序开发商的心病，而对网络服务开发商则不是问题。网络服务比应用程序不足的是，通常网络服务比应用程序反应慢，原因在于信息在互联网上的传输速度，以及多个用户同时使用一个服务器造成的压力。所以，如何提高网络服务的运行效率是对网络服务技术的挑战。 网络服务已经深入人心，成为日常生活不可或缺的一部分。既然网络服务已经红火多年，为什么2002会是网络服务年呢？原因很简单，因为网络服务技术有新发展。 网络服务是可编程的 新一代网络服务的特点在于，它是可编程的。 前面提到地图网络服务可以查询开车路线。这个路线可能是距离最短路径，但是现有的诸个地图网络服务中还没有能查询时间最短开车路线的，因为交通监控是个很复杂的系统。但是已经有一些交通监控的网络服务了，如 http://www.traffic.com，它可以告诉你一些重要路段的现时平均车速。怎样把 http://www.traffic.com 和 http://maps.yahoo.com 结合到一起呢？当然我们可以试图说服两个网络服务商携起手来造福人民。但是由于商业或其他原因，这种固定的结合并不是永远可行。更重要的是，很多网络服务在不同时间，根据不同需求，以不同方式，需要协作。固定的结合不能满足这种动态协作的要求。新一代网络服务技术的任务是使网络服务协作 (Collaboration) 可行，而且使用简便。 新一代网络服务的精髓在于协作，什么是协作呢？简单来说，一台计算机上的程序通过互联网调用其他计算机上的程序，就形成了协作。 网络协作带动电子商务/政务 网络服务协作不仅使日常生活更加简便，而且将导致电子商务与电子政务发生革命性的发展。试想一下，如果企业内各部门，从设计、采购、生产、市场、营销、售后服务，到行政、财务、仓储、人事，都实现了网络服务化，这就使得企业ERP和CRM更加易于更新维护，也有利于各部门的网络服务相互协作，并形成范围更广、功能更强的企业管理系统。更进一步，如果企业与企业间，行业与行业间，企业与政府和个人间，都以网络服务作为手段相互协作，企业可以更自动化、更全球化，政府可以更准确地了解社会，更有效率地服务社会。当然，最先得益的是软件业，就像淘金热中最先发财的是卖工具的。 熟悉分布式计算（Distributed Computing）的朋友会问，现有的远程过程调用（Remote Procedure Call，RPC）技术如CORBA、RMI和DCOM，不就是协作吗？ 远程调用为什么步履维艰？ 其实，远程过程调用虽然是一种协作的实现方式，比较网络服务的协作，远程过程调用有很多不足。 远程过程调用的概念比网络服务先出现好几年，而且颇风光过一阵。尤其是CORBA，设想一提出，立刻走红。CORBA的基本目标是，跨操作系统，跨语言，实现远程过程调用。比如一台UNIX计算机上的C程序，可以远程调用一台Windows计算机上的Java Object。为了在互联网上传输功能块，CORBA使用IIOP协议。可惜的是，CORBA的产品还没有成熟，微软抢先推出DCOM。不过，DCOM不是跨操作系统的，远程调用双方都必须用Windows操作系统。另外，DCOM虽然可以说是跨语言的，但仅限于微软的语言，如Visual Basic、Visual C++等。随后，Sun推出了RMI，供远程Java调用，虽然不跨语言，但因为Java的缘故，RMI是跨操作系统的。 尽管热闹，远程过程调用技术也存在一些缺陷，第一，远程过程调用编程复杂，用过CORBA、RMI或DCOM的朋友也许会有体会。第二，目前的IT世界是两极世界，微软与非微软。DCOM只能用于微软世界，使得DCOM无法与CORBA接轨。第三，CORBA为了传输功能块，使用IIOP网络协议，而IIOP又引发其他技术问题，如IIOP不能穿越防火墙。当然我们也许可以改进网络服务器，解决以上问题。但是既然CORBA没有展现广阔的市场前景，就不会有很多厂家愿意投入资源改进网络服务器。反过来，网络服务器没有改进，也限制了CORBA的广泛使用。这两者谁是因，谁是果，就像是鸡与蛋的因果关系一样，难以说清。 基于CORBA和DCOM，人们发展了EAI（Enterprise Application Integration，企业应用整合）技术。它能使企业内一些部门之间、一个行业内一些企业之间，更方便更迅速地传递信息。EAI的开发者们历尽CORBA和DCOM编程的艰辛，但是收获的成果却有很大缺陷：首先，EAI远程协作只限于一对一；其次，各家开发的EAI系统很难相互替代，一旦用了A家的系统，难以把其中一部分成分用B家的产品替代。更为难办的是，为了传输EAI信息，人们编制了很多EDI标准、EDI代表电子数据交换(Electronic Data Interchange)，每个行业各行一套，相互难以融合。 形象实例 网络服务下，看病、就诊的过程会是怎样？ ● 敲敲键盘，告诉网络服务你的需求，得到门诊日程安排； ● 核对双方日程安排，并预约门诊； ● 如果日程安排有变化，网络服务会用你认可的方式通知你，例如，通过手机； ● 就诊，同时网络服务提供哪些药品可以报销的实时信息； ● 就诊后，网络服务会处理医疗费用； ● 你可以随时更换就医医院或者保险公司。 |
||||||||||||||||||||||||||
