xml
XML、Web服务和.NET框架
应用程序开发技术正发生着一次质的飞跃，从根本上大幅度提高开发人员的生产效率，它开启了一道通向全新概念的应用程序的大门。
在过去，开发人员一直通过集成本地系统服务来构建应用程序。在这种模式下，开发人员可以访问丰富的开发资源并能严格控制应用程序的行为。
如今，开发人员在很大程度上已挣脱了这种模式的束缚，致力于构建具有复杂结构的n层系统，这种系统能将网络中各处的众多的应用程序进行集成，并大大提升应用程序的价值。这样，开发人员便可集中精力挖掘软件独特的商业价值，而不必日夜为如何构建基本结构伤脑筋了。令人欣喜的局面将应运而生：软件投放市场的时间大大缩短、开发人员的编程效率明显提高，最为根本的是开发出质量上乘的软件。
我们正在进入一个崭新的计算时代，一个互联网时代，其核心技术是“可扩展标记语言”，即XML。XML创建出可供任何人从任何地方访问和使用的功能强大的应用程序。它极大地扩展了应用程序的功能，并实现了软件的不间断传输。在这种大环境中，软件已不完全是指那些从CD进行安装的程序，而是已经演变成了一种服务：类似于调用者的ID验证或按观看次数进行收费的电视，人们可通过通信媒体预定此类服务。
这一切，是通过将紧密耦合的、高效的n层计算技术与面向消息的、松散耦合的Web概念相结合来实现的。我们将这种计算风格称为Web服务，它的出现标志着人类已经迈入应用程序开发技术的新纪元。Web服务是一种应用程序，它可以使用标准的互联网协议，像超文本传输协议(HTTP)和XML，将功能纲领性地体现在互联网和企业内部网上。可将Web服务视作Web上的组件编程。
从理论上讲，开发人员可通过调用Web应用编程接口(API)（就像调用本地服务一样），将Web服务集成到应用程序中，不同的是Web API调用可通过互联网发送给位于远程系统中的某一服务。例如，Microsoft Passport服务使得开发人员能够对某应用程序进行验证。通过Passport服务编程，开发人员可以充分利用Passport的基本结构，通过运行Passport来维护用户数据库，以确保它的正常运行、定期备份等等。
松散耦合
在某个网络中分发应用程序逻辑，并不是一个全新的概念，在Web中分发并集成应用程序逻辑才是一个崭新的概念。
从前，分布式的应用程序逻辑需要使用分布式的对象模型，诸如：微软的分布式组件对象模型(DCOM)、对象管理集团的公用对象请求代理程序体系结构(CORBA)或Sun的远程方法调用(RMI)。通过使用这种基本结构，开发人员仍可拥有使用本地模型所提供的丰富资源和精确性，并可将服务置于远程系统中。
这些系统有一个共同的缺陷，那就是它们无法扩展到互联网上：它们要求服务客户端与系统提供的服务本身之间必须进行紧密耦合，即要求一个同类基本结构。这样的系统往往十分脆弱：如果一端的执行机制发生变化，那么另一端便会崩溃。例如，如果服务器应用程序的接口发生更改，那么客户端便会崩溃。
要求提供紧密耦合的基本结构，无可厚非，许多应用程序均是基于这种系统构建而成的。但是，当各个公司需要相互合作、或信息技术提供商扩大业务范围时，便很难实现单一而统一的基本结构。您根本无法保证您希望与之进行远程通信的管道的另一端，具备所有您需要的基本结构：对于它使用的操作系统、对象模型或编程语言，您可能一无所知。
相反，Web服务彼此是松散偶合的。连接中的任何一方均可更改执行机制，却不影响应用程序的正常运行。从技术角度讲，人们已转向使用一种基于消息的异步技术来实现高可靠性的系统性能，通过使用诸如HTTP、简单邮件传输协议(SMTP)以及至为重要的XML来实现统一的连接。
消息传递系统将通信的基本单元打包成自我描述型的数据包（又称作消息），并将其放到网络缆线中。消息传递系统与分布式对象系统之间的本质区别在于：要求发送方辨识接收方的基本结构的程度有所不同。在分布式系统中，发送方需对接收方的情况作出种种猜测：应用程序是如何激活或拆包的，调用的是什么样的界面，等等。
另一方面，消息传递系统会在缆线格式级上创建合同。发送方既不需考虑消息被接收后的情况，也不需考虑接发双方之间的通信情况，唯一需要考虑的是接收方是否能辩识发送的消息内容。
在缆线格式级上创建合同的优势不言而喻。例如，接收方可在任何时刻进行更改，而不会干扰发送方的消息发送，只要它仍可辩识原有消息的内容。另外，发送方无需任何特殊的软件即可与接收方通信：只要它发出正确格式的消息，接收方就可以响应。
缆线级的XML：SOAP
实现Web服务的异类基本结构以及在整个Web中实现Web服务的关键，是实现支持简单数据描述格式的技术。这种格式就是XML。Web服务必须使用XML来完成三件事情：基本的缆线格式、服务描述以及“服务发现”。
SOAP：在通信的最低级别，系统需要使用同一语言。特别，作为通信双方的应用程序需要遵守同一套通信规则：如何表示不同的数据类型（例如：是整数还是数组），以及如何表示命令（即：需要对数据进行何种操作）。另外，在必要的时候应用程序还需对该语言适当的扩展。简单对象访问协议(SOAP)是XML的实施工具，它提供了一套公共规则集，该规则集说明了如何表示并扩展数据和命令。
Web服务描述语言(WSDL)。双方应用程序在得到了如何表示数据类型和命令的规则后，需要对所接收的特定数据和命令进行有效的描述。仅仅说已接收到整数是不够的；比如，在接收到两个整数后，应用程序必须明确表述它可以对这两个整数执行乘法运算操作。Web服务描述语言(WSDL)是一种XML语法，开发人员和开发工具可使用它来表述Web服务的具体功能。
“SOAP发现”：在最高层，还需制定一套如何定位服务描述的规则：默认情况下，用户或工具能在什么地方找到服务的功能描述？依据“SOAP发现”规格说明中提供的规则集，用户或开发工具可以自动找到服务的SCL描述。
一旦实现了这三种功能层，开发人员便可容易地找到Web服务，将它例示成一个对象后再集成进应用程序中，继而构建出一个具有丰富功能的基本结构。这样，得到的应用程序便能与Web服务进行反向通信了。
.NET框架：Web服务引擎
很显然，许多基本结构都需实现上述进程对开发人员和用户的透明化。.NET框架提供此基本结构。从.NET框架角度看，所有组件都可以是Web服务，而Web服务也仅是一种组件。实际上，.NET框架提取出微软组件对象模型(COM)的精华，将它们与松散耦合计算的精华有机地结合在一起，生成了强大、高效的Web组件系统：简化程序员的“管道”操作、深入地集成了安全性，引进了基于互联网的操作系统，极大地改善应用程序的可靠性和可扩展性。
.NET框架包含三个主要部分：公共语言运行时、具有多层次结构的统一的类库集合和高级版“活动服务器页面”（又名ASP+）
公共语言运行时
此名称不能准确反映它的全部功能。实际上，公共语言运行时在组件的开发过程中以及软件的运行过程中，都扮演着非常重要的角色。在组件运行过程中，运行时负责管理内存分配、启动或取消线程和进程、实施安全性策略、同时满足当前组件对其它组件的需求。在开发阶段，运行时的作用有些变化：与现今的COM相比，运行时的自动化程度大为提高（比如可自动执行内存管理），因而开发人员的工作变得非常轻松。尤其是，映射功能将使代码编写量锐减，这些代码是开发人员在将业务逻辑转化成可复用的组件进行编程时所需的。
对编程语言而言，运行时这个概念并不新奇：实际上每种编程语言都有自己的运行时。Visual Basic开发系统具有最为明显的运行时（名为VBRUN），Visual C++跟Visual FoxPro、Jscript、SmallTalk、Perl、Python和Java一样，有一个运行时MSVCRT。NET框架的关键作用是它提供了一个跨编程语言的统一的编程环境，这也是它能独树一帜的根本原因所在。
统一的编程类
.NET框架中的类为开发人员提供了一个统一的、面向对象的、层次化的、可扩展的类库集(API)。现今，C++开发人员使用的是微软基础类库，Java开发人员使用的是Windows基础类库，而Visual Basic用户使用的又是Visual Basic API集。简而言之，.NET框架统一了微软当前各种不同的框架。这样，开发人员不再需要学习多种框架就能顺利编程。远不止于此的是，通过创建一个公共的跨编程语言的API集，.NET框架可实现跨语言继承性、错误处理功能和调试功能。实际上，从Jscript到C++的所有编程语言，都是相互等同的，开发人员可以自由选择理想的编程语言。
高级版“活动服务器页面”(ASP+)
ASP+是使用 .NET框架提供的类库构建而成的，它提供了一个Web应用程序模型，该模型由一组控件和一个基本结构组成。有了它，Web应用程序的构建变得非常容易。开发人员可以直接使用ASP+控件集，该控件集封装了公共的、用于超文本标识语言(HTML)用户界面的各种小组件（诸如文本框、下拉菜单等等）。实际上，这些控件运行在Web服务器上，它们将用户界面转换成HTML格式后再发送给浏览器。在服务器上，控件负责将面向对象的编程模型呈现给Web开发人员，这种编程模型能提供面向对象的编程技术拥有的丰富功能。ASP+还提供一些基本结构服务（诸如会话状态管理和进程循环），这些服务进一步减少了开发人员要编写的代码量，并使应用程序的可靠性得到了大幅度提高。ASP+还允许开发人员将软件作为一项服务进行传送。通过使用ASP+ Web服务功能，ASP+开发人员只需进行简单的业务逻辑编程，而由ASP+基本结构负责通过SOAP传送服务。
尽管ASP+还未正式发行，但它已在改进应用程序功能方面创造出令人难以置信的奇迹：在现有基于ASP的应用程序性能基础上，性能优化了三倍之多，更为激动人心的是生产效率再度攀升。
.NET框架的核心要素
.NET框架有几个要素值得一提。首先是它的安全系统和配置系统。这两个系统协同工作，有力地遏止了运行不安全代码的可能性，并大幅度减少了号称“DLL Hell”的对应用程序进行配置时所面临的挑战。
安全系统是一个高度细化、基于事实的系统，它赋予开发人员和管理员多种代码处理权限（而不仅仅是“on”或“off”）。将来，还会根据代码本身的核心要素来决定如何实施上述权限。
例如，当.NET框架应用程序被下载到某一系统中时，它会申请一组权限（诸如对临时目录的写入权限）。运行时将收集有关应用程序的事实信息（诸如：它是从何处下载的、是否用了有效签名、甚至它访问系统的准确程度），并按管理策略决定是否允许应用程序运行。运行时甚至还可告之应用程序它无法授权申请的所有权限，并允许应用程序自行决定是否继续运行。
有这种安全系统作保障，许多应用程序配置问题便会迎刃而解。开发人员和管理员（最终是用户）所面临的最大挑战之一是版本的管理问题。如果在您新装了某个应用程序之后，一切都限于瘫痪状态，而在这之前系统一直运行得非常良好，那么最大的可能是新安装的应用程序重写了一些共享库，并极有可能修正了现有应用程序正使用的程序错误。这种情况出现的频率很高，以致人们将它称为：“DLL Hell”。
.NET框架拥有的几项高级功能可以彻底消除“DLL Hell”现象。首先，它有一个非常强大的内部命名系统，能够有效地防止两个库因互相重名而被错当为对方的情况发生。除此之外，它还提供一项被称作“并行”配置的新功能。如果前例中新安装的应用程序确实重写了共享库，现有应用程序可对该库进行修复。等现有应用程序再次启动时，它会检查所有的共享文件。如果发现文件被更改，同时这些更改又是不兼容的，则它可以请求运行时提取一个它可以使用的版本。得益于强大的安全系统，运行时可以安全地执行该操作，这样应用程序就完成了本身的修复工作。
结论
人们总是喜欢不厌其烦地发表诸如“互联网改变了一切”的陈词滥调。同样地，在谈论互联网给人类带来的影响时，总是情不自禁地使用广告式的夸张语，以表达对互联网的推崇。不过，互联网的确彻底改变了应用程序的开发模式和配置方式。将传输软件演变成一种服务还有待人们的共同努力，XML是实现这个梦想的重要手段。.NET框架是微软开发人员战略的核心内容，它旨在帮助开发人员轻松地构建、配置和运行Web服务。