|
.NET 初 级 读 本(2) 要为这些程序设计和实现一套图形用户接口（GUI）库需要做相当多的工作。特别痛苦的是在这些不同的实现中几乎没有任何共同点。要完全实现一个真正强大的GUI，需要从操作系统级做起。所以到后来，apple，microsoft和其他公司开发出了图形界面的操作系统，这些系统不仅支持开发GUI的应用程序，还极大地扩展了这些程序的能力，其提供的库不单单是支持窗口和菜单的绘制，还提供了丰富的的系统服务，以使开发者工作更加流畅。这些服务包括与设备无关的打印模式，甚至是系统剪贴板等等，这些都是对开发者非常有用的资源。 我希望我对这段历史得还算清楚，我们将从这里开始。 回到现在
现在我们跳回到现在。想象一下Internet正扮演着80年代初个人电脑的角色，Web站点就是当初的程序。如果这个Web站点只是包括一些超链或者是一些文本文档，那它就像是过去的一个文本模式的程序，如果这个站点提供交互式的服务的话，那它就可以被比作是当时的GUI的程序了。在交互式的服务下，用户提供信息给Web站点，这些信息在Web站点中被交给应用程序逻辑来处理然后产生一个结果。这样的例子有购物车、AltaVista提供的翻译服务和UPS提供的包裹跟踪服务等等。 首先来看看购物车这个例子。几乎所有的购物车都将支持输入信用卡信息。很多时候这些信息只是作为交易信息的一部分而被记录下来，一个好的购物车将应该能够快速而且精确的向信用卡的发卡公司校验信用卡信息，如果用户输入了错误的信息，就应当给用户一个提醒。但当这个Web站点想支持一种新的信用卡类型时它该怎么办呢？这个站点的开发者必须联系那个信用卡公司，找出他们支持的(如果有的话)电子校验服务，然后根据那个公司的电子校验的实现写自己的代码与其配合。 翻译服务又会怎么样呢？如果我们正在写一个e-mail 的程序，难道你不觉得在你的程序中加入即时翻译功能会非常有用吗？AltaVista就有提供了这种服务的站点，你可以悄悄的启动一个隐藏的浏览器控件，给它一些必要的信息，然后查看它返回的信息，在返回的页面上定位翻译好了的信息的位置，最后把它提取出来提供给用户。这和有些图形界面的应用程序从文本模式的程序或者是大型计算机终端中获取信息的方式有些类似。这就是广为所知的屏幕截取，这种方式比较复杂而且相当脆弱，因为目标屏幕的布局发生变化，即使是很细微的变化将会带来很严重的问题，而且在有些情况下这种实现显得并不道德。 现在我们来讨论讨论包裹跟踪服务，想象一下如果你的站点允许你的用户查询他们所定购的货物的当前状态会是会多么棒呀。通过UPS的追踪编号来提供这些信息将会是非常有效的，或者是把这些信息做成到UPS站点的链接，然后你的用户就会得到关于他们包裹目前状态的详细报告了，也许这个时候这些包裹还正在漂洋过海呢。但你觉不觉得这样会更方便，那就是你的站点和UPS的站点交互工作，然后在你自己的网站上提供这些信息？这样的话，这些信息就会和你的站点的其它部分一样共享相同的用户界面，而且不用担心用户不小心迷失在UPS站点后不知道怎样回到你的站点了。 为了给用户提供集成服务的体验，上面的例子或者需要你从其他公司找到以编程方式得到他们的服务的方法，然后为这些服务开发自己的用户界面；或者是写一个屏幕截取程序来截取相应的信息，如果已有公司通过Web 提供了的相同服务的话。
非常明显，无论是那种实现方式，代码量和耦合度都太大，而且还存在很多潜在的问题和失灵的可能。这些途径在本质上很象80年代时强迫文本模式的程序与操作系统还不能直接支持的设备进行交互一样。 标准协议
一种比较好的解决方案应该是一套通用的、能够和远程服务交互的途径，这种途径不仅仅连接能够某个公司的服务，而且能够发现这个公司提供什么样的服务，就象XML、SOAP和UDDI的目标那样。XML(扩展的标记语言)将信息表示成一种易于按你的需要进行编程获取或处理的格式，SOAP(Simple Object Access Protocol)基于XML，特别的被设计来提供远程服务的接口信息。而UDDI(Universal Description, Discovery, and Intergration)是业界倡导的，具有对Internet服务和资源的探测能力的一套标准。
| 
