用SOAP实现数据通讯、Web Service

8  用SOAP实现数据通讯
        长期以来我们使用超文本传输协议 HTTP 来提供 Web 页面以及往来的内容。但当我们将 HTTP 或一些其它 Internet 传输协议 同 XML 结合起来，并指定 XML 文档自身的格式时，你得到了简单对象访问协议 SOAP。至少在开始构想它时，SOAP是被设计为从本地系统向远程系统传递远端方法调用的。基于 SOAP 的结构与同时代的其它远程结构—DCOM、CORBA 和 RMI 等等—所不同的，SOAP 协议可以穿越任何团体的防火墙，并且 SOAP 数据包中包含着以 XML 编码的数据。而且，它们易于分析和使用。SOAP 还有很好的伸缩性，这使得我们能同时为非常多的用户服务。
SOAP 模型最初的构想是使用请求-响应模型，同我们今天所用的 Internet 计算模型很相似。随后，SOAP 发展到包含了消息模型。两者的不同之处是 SOAP 在对远端系统上的方法参数进行编码时，有获得结果的特殊目的。它并不请求 Web 站点提供一个感兴趣的数据表格，相反，比如说，在同样的系统上我能调用一个假想称为 CalculatePayment() 的远程调用，并收到一个个人付款数值。是的，今天你能用一个表单做到这些，但关键是在调用服务和提交表单之间存在着差别。服务调用是功能更强的概念。
        我们正在进入计算机发展的下一个阶段——基于Internet的阶段，特别是基于Internet核心技术——XML扩充标记语言。尽管多层应用程序开发将焦点集中在建造大型企业级应用程序上，但现在XML使得能够创建可用于任何人、任何场所的大型应用程序。它扩大了应用程序的使用范围。这样，软件就不是只能从CD上安装的某种东西，而是一种服务——就像呼叫服务或者计费电视一样，可以通过通信媒体来预订。
        这一切，是通过将紧密联接的、高效的n层计算技术与面向消息的、松散联接的Web概念相结合来实现的。我们将这种计算风格称为Web Service（Web服务），它的出现标志着人类已经迈入应用程序开发技术的新纪元。Web服务是一种应用程序，它可以使用标准的互联网协议，像超文本传输协议(HTTP)和XML，将功能纲领性地体现在互联网和企业内部网上。我们也可将Web服务视作Web上的组件编程。
        从理论上讲，开发人员通过调用Web应用编程接口（API），将Web服务集成进他们的应用程序，就像调用本地服务一样。两者区别在于前者能够通过Internet发送到某个远程系统的服务上。例如，像微软护照（Microsoft Passport）这样的服务，可以给开发人员提供应用程序身份确认的功能。通过对护照服务编程，开发人员就可以利用护照服务的基础体系，实现维护用户数据库，确信服务开启和运行以及正确地备份等等功能。

8.1  松散联接
        跨越网络的分布应用程序逻辑的概念并不是一个新名词，但跨越Web的分布和集成应用程序逻辑的概念却是。
        此前，像微软的DCOM (Distributed Component Object Model )、Object Management Group公司的CORBA （Common Object Request Broker Architecture ）以及Sun公司的RMI(Remote Method Invocation )这些分布式对象模型被称为分布应用程序逻辑。运用这些系统结构，虽然服务放在远程系统上，开发人员仍然可以像原来本机编程那样维护和丰富应用程序的功能。
        但这种系统的问题是不能扩展到Internet。因为该体系的基础是服务器上的客户端和服务器的紧密联结。这意味着两者必须是同质的基础体系，但也就常常意味着这种系统是非常脆弱的，如果有任何一端接口发生变化，另一端程序必然就会被中断。举个例子，如果服务器应用程序的接口改变了，那么客户端也将会失效。
        开发中要求有一个紧密联接的系统这本身没有错，而且许多应用程序也一直就是建立在这些系统上的。但最终，随着时间的流逝，这种模型是不会扩展的。因为众多公司企业要求相互沟通，这很难保证会有一个统一的系统，同样也很难保证，你的客户的服务器会有你所需要的完全一致的系统，你甚至都不可能猜想到它所用的是什么操作系统、什么对象模型和什么编程语言。
        相反，Web服务的联接非常松散。这就意味者你可以在联接的任何一端任意改变接口，而应用程序可以不受影响地照常工作。从技术上说，这主要是由于使用了拥有稳固性能的基于消息的异步技术，如像HTTP、SMTP等Web标准协议。而且最重要的是，XML可以帮助实现其通用性。

8.2  消息系统
        消息系统将通信的基本单元打包进自描述的、运用于网络通信层的包（被称做消息）。消息系统和分布式对象系统的关键区别在于，发送者需要对接收者的系统了解多少。使用分布式的对象系统，发送者需要帮助接收者考虑许多问题，比如应用程序将如何激活和卸载、调用的是什么接口等等。
        另一方面，消息系统在通讯层上达成协议。发送者只需考虑的是接收者能够知道信息正被发送。发送方不需要了解一旦消息被收到后将会如何处理，也不需要对发送方和接收方之间作任何考虑。
        在通讯层上达成协议的优势是显而易见的。例如，协议能够使接收方随时作修改而无须中断发送方，只要该协议始终明白是同一条消息。接收方不用中断任何当前应用程序，可以自由升级和改进。更进一步说，就是发送方不用要求任何特殊的软件就可以和接收方交谈，只要他发送的是符合格式的信息，接收方就可以作出应答。

8.3  XML的通讯基础：SOAP
        建造跨越Web的 Web服务的工作和异步系统的关键是使用统一的数据说明格式，这就是XML。特别说明的是，Web服务器在三方面需要XML来实现：基础语言、服务说明以及服务发现。
 SOAP：系统在底层需要有统一语言，特别地，应用程序相互通讯需要建立一套规则来说明如何表示不同数据类型（如整数和数组），如何表示命令（如进行数据处理）。同时，应用程序在需要时还可以扩充这种语言。简单对象存取协议SOAP（Simple Object Access Protocol），这是XML的一种实现，代表了一组如何表示和扩充数据和命令的规则集。
        WDSL(Web Services描述语言) ：一旦应用程序有了如何表述数据和命令的基本规则，他们就需要如何描述可以接收的特定数据和命令。应用程序只是声明如何接收整数是不够的，他们必须用明确的方法声明。如给你两个整数，把它们相乘。WDSL是一种XML语法，开发人员和开发工具可以用它来表示Web服务的功能。
        ● SOAP Discovery：最后需要一组规则来定位服务的描述——对于开发者和开发工具在什么地方可以发现一个Web服务。SOAP Discovery规范提供了一组规则让开发者和开发工具可以自动发现Web服务的描述。
        一旦这些准备好了，开发者可以方便地发现Web 服务,把它作为一个对象集成进他们的应用程序，并使应用程序和Web服务相互通讯。

8.4  .NET框架:Web服务引擎
        很显然，许多基本结构都需实现上述进程对开发人员和用户的透明化。.NET框架（.NET Framework）提供此基本结构。从.NET框架角度看，所有组件都可以是Web服务，而Web服务也仅是一种组件。实际上，.NET框架提取出微软组件对象模型(COM)的精华，将它们与松散联接计算的精华有机地结合在一起，生成了强大、高效的Web组件系统：简化程序员的“管道”操作，深入地集成了安全性，引进了基于互联网的操作系统，极大地改善应用程序的可靠性和可扩展性。
.NET框架由三个主要部分组成：通用语言运行库、一套层次结构的统一类库和一个被称为ASP+的高级ASP版本。
        1．通用语言运行库
除了通用语言运行库的字面含义外，在开发阶段和运行过程中它还扮演着另一个角色。在组件运行时，运行库负责管理内存分配、启动和中止线程和进程、强化安全系数，同时还调整任何该组件涉及到的其他组件的附件配置。在开发阶段，运行库的角色稍微有点变化：因为很多方面可以自动实现（例如内存管理等）。运行库可以使开发过程变得非常简单，特别是同今天的COM编程相比更是如此。特别典型的是，像Reflection这样的特性可以极大地缩小开发人员将商业逻辑转化成一个可重复使用的组件而不得不编写的代码数量。
        2．统一编程类
.NET框架类为开发人员提供了一套可以使用的统一的面向对象、异步、层次结构的可扩展类库。现在，C++的使用者使用Microsoft Foundation Classes，Java程序员使用Windows Foundation Classes，Visual Basic的用户使用Visual Basic APIs。微软用.NET框架统一了这些不同的框架。
        3．ASP+
        ASP+是使用 .NET框架提供的类库构建而成的，它提供了一个Web应用程序模型，该模型由一组控件和一个基本结构组成。有了它，Web应用程序的构建变得非常容易。开发人员可以直接使用ASP+控件集，该控件集封装了公共的、用于超文本标识语言(HTML)用户界面的各种小组件（诸如文本框、下拉选单等等）。实际上，这些控件运行在Web服务器上，它们将用户界面转换成HTML格式后再发送给浏览器。在服务器上，控件负责将面向对象的编程模型呈现给Web开发人员，这种编程模型能提供面向对象的编程技术拥有的丰富功能。ASP+还提供一些基本结构服务（诸如会话状态管理和进程循环），这些服务进一步减少了开发人员要编写的代码量，并使应用程序的可靠性得到了大幅度提高。ASP+还允许开发人员将软件作为一项服务进行传送。通过使用ASP+ Web服务功能，ASP+开发人员只需进行简单的业务逻辑编程，而由ASP+基本结构负责通过SOAP传送服务。

8.5  .NET框架的核心部分
        .NET框架有几个要素值得一提。首先是它的安全系统和配置系统。这两个系统协同工作，有力地遏止了运行不安全代码的可能性，并大幅度减少了号称“DLL Hell”的对应用程序进行配置时所面临的挑战。
        安全系统是一个高度细化、基于事实的系统，它赋予开发人员和管理员多种代码处理权限（而不仅仅是“on”或“off”）。将来，还会根据代码本身的核心要素来决定如何实施上述权限。
        例如，当.NET框架应用程序被下载到某一系统中时，它会申请一组权限（诸如对临时目录的写入权限）。运行时将收集有关应用程序的事实信息（诸如：它是从何处下载的、是否用了有效签名、甚至它访问系统的准确程度），并按管理策略决定是否允许应用程序运行。运行时甚至还可告之应用程序它无法授权申请的所有权限，并允许应用程序自行决定是否继续运行。
        有这种安全系统作保障，许多应用程序配置问题便会迎刃而解。开发人员和管理员（最终是用户）所面临的最大挑战之一是版本的管理问题。如果在您新装了某个应用程序之后，一切都陷于瘫痪状态，而在这之前系统一直运行得非常良好，那么最大的可能是新安装的应用程序重写了一些共享库，并极有可能修正了现有应用程序正使用的程序错误。这种情况出现的频率很高，以致人们将它称为：“DLL Hell”。
        .NET框架拥有的几项高级功能可以彻底消除“DLL Hell”现象。首先，它有一个非常强大的内部命名系统，能够有效地防止两个库因互相重名而被错当为对方的情况发生。除此之外，它还提供一项被称作“side by side”配置的新功能。如果前例中新安装的应用程序确实重写了共享库，现有应用程序可对该库进行修复。等现有应用程序再次启动时，它会检查所有的共享文件。如果发现文件被更改，同时这些更改又是不兼容的，则它可以请求运行时提取一个它可以使用的版本。得益于强大的安全系统，运行时可以安全地执行该操作，这样应用程序就完成了本身的修复工作。

9  Web Service
        网络服务是基于网络的分布式应用程序的基本构造模块，而这些程序是以平台、对象模板和多语言方式构建的。
网络服务是建立在象HTTP和XML之类的开放的Internet 标准之上的，并且由此形成了可编程网络理念的基础。
        现在开发中最紧迫的问题是应用程序的集成化：运行在不同操作系统上的不同的应用程序，通常是由不同编程语言对象模板建立的，获取这些程序然后把它们转化为易于使用的网络应用程序。建立在象HTTP和XML之类开放的网络标准之上的网络服务接受了这项挑战。
下面笔者将介绍网络服务及Microsft.NET框架的组件，包括通用运行语言（Common Language Runtime）、服务框架和用于建立、集成网络服务的程序模板。
9.1  网络服务一览
        网络服务只是一个作为服务发行的简单应用程序。换句话说，它是可通过URL定位的自动将信息返回到需要它的客户端那里的一种资源。网络服务一个重要的特点是客户不需要知道一种服务是怎样实现的。在本文中，笔者将向你解释网络及网络服务如何把基于组件技术的最好的方面结合在一起，并且介绍与网络服务通信所需的基本框架。
同组件一样，网络服务提供“黑匣子”函数，它可以被多次用而不用关心此服务是怎样实现的。网络服务还提供被称为契约的精确定义的接口，此接口描绘了所提供的服务。开发人员可以将远程服务、本地服务和定制代码组合在一起集成到应用程序中。例如，某公司可以使用如下服务组建一个在线商店：微软护照（Passport）服务用来验证用户身份、第三方个人化服务用来使网页匹配每一个用户的参数、信用卡处理服务、销售税服务、对每个运输公司的包裹跟踪服务，链接公司内部库存管理程序的内部目录服务以及少量定制代码，以使他们的商店能脱颖而出。
        然而，网络服务与现在的组件技术并不相同，它不使用需要在服务器和客户机有明确的、同类型基本构架的具体对象模型协议，例如DCOM、RMI或IIOP。尽管与具体组件技术紧密结合的实现在一个受控的环境中能很好地被接受，但它们在网络环境中变得不切实际。因为一个集成商业程序的参与者会发生变化，随着时间的推移，技术也在变化，所以在所有参与者间确保一个单一的、统一的体系架构就变得十分困难。网络服务采取了另外一种途径，它使用普便存在的网络协议和数据格式进行通信，如HTTP和XML。支持这些网络标准的任何系统都支持网络服务。
        而且，网络服务契约描述的是以术语报文形式提供的服务，这些服务是由网络服务生成和接受的，而并不描述服务是如何实现的。通过把重点放在报文上，网络服务模板对语言、平台和对象模板变得完全透明。这样，用任何一套编程语言、对象模型和平台的完全特性集，都可实现网络服务。网络服务可以在任何平台上，被任何应用程序所使用。只要用于解释服务容量、报文序列和所期望协议的契约得到认同，那么所实现的网络服务及网络服务用户就可相互不同，而不会影响会话另一端的应用程序。
        网络服务模板对最小体系架构的要求很低，目的是确保网络服务在使用任何技术和编程语言的平台上实现和访问。对网络服务互用性的解决可以只依靠网络标准。然而，为了使应用程序更容易使用网络服务，简单地通过标准网络协议访问网络服务是不够的。当网络服务和网络服务使用者依靠标准的方式（如XML）表示数据和命令、表示网络服务契约、算出网络服务所提供的容量时，网络服务才会更加容易使用。
        XML是定义一个标准的、可扩展的用于提供命令和典型数据的语言的明智选择。虽然为表示命令和典型数据可以定义使用其它技巧（比如编码为一种查询字符串）的规则，但XML被专门设计为描述数据的标准元语言。简单对象存取协议（SOAP）是以一种可扩展的方式使用XML表示数据和命令的工业标准。网络服务可选择用SOAP决定报文的格式。
        XML是网络服务契约的一种常用技术。服务契约语言(SCL)是记录网络服务契约的XML语法。由于SCL是基于XML的，所以对开发者和开发工具来说，它更容易生成并解释契约。
        Disco规范为服务提供者发布网络服务契约和相应的机制描述了一个标准方式，这将使开发者或开发工具可找到契约文献。
象SOAP、SCL和Disco这样的标准有助于开发者，因为它们不需要明白和实现所使用的每一个网络服务的访问方式。支持这些标准的更好的、已充分测试的、高性能的体系架构将由开发平台提供，这会大大简化整个开发过程。

9.2  Microsoft.NET Framework
        Microsoft.NET框架的目的是使你更容易建立网络应用程序和网络服务。建立在操作系统最上层的服务，是管理运行代码需求的Common Language Runtime，这些代码可以用任何现代编程语言所编写。Runtime提供了许多服务，这些服务有助于简化代码开发和应用程序的开发，同时也将提高应用程序的可靠性。.NET Framework包括一套可被开发者用于任何编程语言的类库。在此之上是许多应用程序模板，这些模板为开发网络站点和网络服务提供了高级组件和服务。
        9.3  Common Language Runtime
运行语言(Runtime)可以调用并运行任何编程语言所写的代码。以运行为目标的代码被称为受控（Managed）代码，受控代码只是意味着在内部可执行代码与自身代码存在已经定义好的合作契约。对于生成对象、调用方法等这样的任务，被委托给了运行语言，这使得运行语言能为可执行代码增加额外的服务。
        运行语言具有交叉语言集成、自描述组件、简单配制、版本化以及集成安全服务等特点。
        运行语言使用一种能表达大部分现代编程语言语义的通用类型系统，该通用类型系统定义了一套标准类型及生成新标准的规则。运行语言知道怎样生成、执行这些类型。编译器和解释器使用运行语言服务来定义类型、管理对象、进行方法调用。
        类型系统的主要设计目的是使多种语言能深度集成。用一种语言所写的代码能继承用另一种语言所写的类，用一种语言所写的代码抛出的异常能被用另一种语言写的代码所捕获，象调试之类的操作会在完全封闭下进行，而不用考虑代码编写所用的语言。这就意味着编写可重用类库的开发者，不再需要为每一种编程语言或编译器生成一个版本，并且使用类库的开发者也将不再受到他们所使用的编程语言开发库的限制。
        自描述组件简化了开发和配制，并提高了系统的可靠性。许多由运行语言提供的服务是由元数据及用于补充可执行代码的信息所驱动。因为所有的信息都储存在一起，只有可执行的代码才被称为自描述组件。
        自描述组件的一个主要优点是，使用它们并不需要其它文件。类的定义不需要单独的头文件；通过检查元数据对类的定义可以从组件自身获得。跨语言或过程边界访问组件并不需要各自的IDL文件、类型文件或proxy/stubs；所必需的信息已存在于元数据之中。最主要的是，由于元数据是在编译过程中由源代码生成，并与可执行代码储存在一起，因此，它将永远和可执行部分同步。
        除了改善对单个组件的配置，Microsft .NET框架定义了一个应用程序配置模板，以解决定制应用程序安装和DLL版本化（通常被称为“DLL Hell”）这一复杂过程的问题，运行语言提供了支持这个模板的服务。
Microsft.NET框架引入了组合体的概念。一个组合体是一组资源和类型，并包括有关这些资源和类型的元数据，也就是被作为一个单元配置的。元数据被称为组合体的名单，它包含象类型和资源表之类能被组合体外看得见的信息，这个名单也包括有关从属关系之类的信息，例如组合体建立时的版本号。开发人员可以指定版本策略，以指示运行语言是否装入系统上已安装的依赖于组合体的最新版本，装入一指定版本，或在编译时使用的版本。
        某软件组件的多个拷贝可以存在于同样的操作系统上，然而，通常只有其中的一个拷贝能被操作系统注册、调入内存并执行。对系统来说，定位和调入内存的策略是全局性的。.NET Framework Common Language Runtime增加了所必须的体系架构以支持管理组件定位和调入的每个应用程序策略，这通常被称为并行配置。
        组合体可以被一个应用程序私有，或被多个应用程序共享。一个组合体的多个版本可以同时配置在同一台机器上。应用程序的配置信息定义了应到何处去查找组合体，这样，Runtime就能为同时运行的两个不同的应用程序装入到同一组合体的不同版本中，消除了由组件版本的不兼容性引起的问题，提高了系统整体的稳定性。如果必要，管理员可以为配置时的组合体增加配置信息。
        因为组合体是自描述的，所以并不需要在系统上进行注册。应用程序的配置简单到了只需将文件拷贝到目录中即可（如果为了使应用程序能够运行，必须安装未经组织过的组件的话，情况会稍微复杂一点）。配置信息保存在可被任何文本编辑器编辑的XML文件中。
        最后，运行语言也提供完整的、普遍深入的安全服务，以确保未经授权的用户不能访问机器上的资源，并且代码不会执行未经允许的动作。这就提高了系统整体的安全性和可靠性。由于运行语言用于装入代码、生成对象、执行方法调用，所以当受控代码装入内存并执行时，运行语言能进行安全检查，从而强化安全策略。
        Microsft.NET框架不仅规定代码访问安全机制，还规定基于角色的安全机制。通过代码访问安全机制，开发人员能为应用程序指定完成工作所必需的权限。例如，程序或许需要写文件或访问环境变量的权力。这类信息和有关代码标志的信息一起存储在配置级上。当代码装入内存并执行方法调用时，运行语言将验证是否能给予代码所要求的权限。如果不能，将记录一条安全冲突信息。给予权限的策略，被称之为信任策略，是由系统管理员建立的，并且是建立在关于代码的证据基础之上。比如：代码是谁发布的，是从什么地方获得的，以及在组合体中找到的代码标志和它要求的权限。开发人员可以指定他们具体的权限，以防止其它人恶意使用他们的代码。如果所需要的权限依赖直到运行时刻才会知道的信息，那么就可写入纲领性的安全检查。
        除了代码访问安全机制，运行语言还支持基于角色的安全机制。基于角色的安全机制建立同代码访问安全机制一样的权限模板，只是这些权限是建立在用户的身份之上，而不是建立在代码的标志之上。角色表明了用户所属的类，并且可以在开发和配置阶段定义。给予权限的策略被分配到每个预定义的角色。在运行时刻，用户的身份被确定，代码将代表这个身份运行。运行语言决定用户是哪个角色的成员，然后给予基于这个角色的权限。

9.4  服务框架
        正如我们从图2所看到的那样，在Common Language Runtime之上是服务框架（Services Framework），此框架提供能被任何现代编程语言所调用的类。所有的类都遵循一套命名和设计方针，从而大大减小了开发人员学习过程中的难度。

9.5  数据访问服务
        几乎所有的网络服务都需要查询和更新永久性数据，不论是以简单文件，还是以相关数据库，或是以其它的存储类型存在。为了提供对数据的访问，服务框架包括ActiveX Data Objects+ (ADO+)类库。ADO+为基于网络的应用程序和服务提供数据访问服务。由ADO+的体系结构可知，任何数据，不论这些数据实际上如何存储的，都以XML或相关数据的格式被操作。
        ADO+定义了那些链接数据仓库、对数据仓库发送命令及从中获取结果的类。这些类由受控数据提供者（managed data provider）实现。ADO+中链接和命令对象看上去和ADO中的是一样的，并且一个名为DataReader的新类提供了通过高性能API流获取结果的能力。DataReader在功能上与ADO的记录集（Recordset）是相似的，但是DataReader被设计用来最小化内存中生成的对象的数量，用以提高性能、避免垃圾积累。在.NET Framework中包含了针对Microsoft SQL Server的受控数据提供者以及可通过OLE DB访问的任何数据仓库。
        ADO+的一个主要创新是引入了数据集（Dataset）。一个数据集是内存中提供数据关系图的高速缓冲区。数据集对数据源一无所知，它们可以由程序或通过从数据仓库中调入数据而被生成、填充。不论数据从何处获取，数据集都是通过使用同样的程序模板而被操作的，并且它使用相同的数据缓冲区。使用.NET平台的开发人员能够用数据集代替传统ADO中无连接的记录集。
        受控数据提供者为数据仓库和数据集公开的、名为DataSetCommand的接口对象。DataSetCommand使用ADO+链接和命令从数据仓库中提取数据集，并把在数据集中发生的变化解析到数据仓库中。
        就像DataReaders显示了对于相关数据的有效的流访问一样，XmlReaders显示了对XML数据的流访问。开发人员使用DataNavigator可以滚动和编辑内存中的XML文档。DataNavigator在功能上和Document Object Model (DOM)是一样的，但它更有效，并提供了能很好映射关系数据表的对象模板。ADO+为那些希望继续使用DOM作为XML对象模板而不是使用更有效的DataNavigator模板的开发人员提供了一个XMLDocument类。

9.6  表单应用模板
从概念上讲，在服务框架的最上面是两个应用程序模板：Windows表单应用模板和网络应用程序模板。尽管本文把重点放在把Microsft.NET框架用作开发网络服务和网络应用程序的一种途径上，但框架也可用于开发较传统的基于Windows的应用程序（当然，这些应用程序也能使用网络服务）。
        编写Windows客户应用程序的开发人员可使用Win表单应用程序模板以利用Windows丰富的用户接口特点，包括现在的ActiveX控件和Windows 2000的新特点，如透明的、分层的浮动窗口。开发人员会发现Win表单可编程模板和对设计阶段的支持非常直观。
        Win表单利用了Microsft.NET框架 runtime以减少基于Windows的客户应用程序的开销。只要应用程序和组件是用于Win表单应用程序的，那么它们就能被框架安全模板在客户机上安全地执行。
Microsft.NET框架装配模板简化了应用程序的配制和版本化。应用程序可被配制为使用它们在编译和测试中所用的共享组件，而不是使用恰好在客户机器上安装的随便什么版本的组件，这就提高了应用程序的可靠性，减少了应用程序所支持调用的主要因素：用户接口控件和其它共享组件版本的不兼容性。

9.7  网络应用程序模板
        建立在Microsft.NET框架上网络应用程序共享一个通用应用程序模板。包含用于生成在浏览器中观看的网页的网络应用程序和网络服务。下面，笔者将详细介绍Active Server Pages+ (ASP+)的网络应用程序可编程模板。
        ASP+是由活动服务器页面（ASP）发展而来。ASP+利用common language runtime和服务框架网络应用程序提供了一个可靠的、自动化的、可扩展的主机环境。ASP+也受益于common language runtime集成模板，简化了应用程序的配制。另外，它提供简化应用程序开发的服务（如状态管理服务）以及高水平的编程模板（如ASP+网络表单和ASP+网络服务）。
        ASP+的核心是HTTP运行语言，一个高性能的用于处理基于低级结构的HTTP请求的运行语言,而基于的结构与Microsoft Internet Information Services (IIS)所提供的ISAPI结构相似。HTTP运行语言（HTTP runtime）负责处理引入的所有HTTP请求，并对每个请求应用程序的URL进行解析，然后把请求分配到应用程序以进行进一步的处理。HTTP 运行语言是多线程的，并异步处理请求，因此劣质的应用程序代码阻碍不了它对新请求的处理。而且HTTP运行语言假定失败必会发生，因此它通常可以自动地从访问冲突、内存泄漏、死锁等事故中恢复过来。
        ASP+使用基于构件的Microsft .NET框架配制模板，因此它获得了如XCOPY配制、构件并行配制、基于XML配制等优点。ASP+另一个主要优点是，它支持应用程序的实时更新。管理员不必关掉网络服务器，甚至不用停止应用程序的运行就可以更新应用文件。应用程序文件永远不会被加锁，甚至在程序运行时文件就可以被覆盖。当文件更新后，系统会检测到文件变化，并用新的应用程序代码建立一个新的应用程序实例，然后将引入的请求传递到应用程序。当所有被现存的应用程序实例处理的未完成的请求处理完后，该实例就被销毁。
        在应用程序中，HTTP请求（HTTP Request）通过HTTP模块的管道路由，最终到达请求处理程序。HTTP模块和请求处理程序是一些实现特殊接口的受控类，而这些接口是由ASP+定义的。这种管道结构使得为应用程序增加服务非常方便：只需补充一个HTTP模块。例如安全、状态管理及跟踪都被实现为HTTP模块。高级可编程模块，如网络服务和网络表单，通常被用于请求处理程序。一个应用程序能链接多个请求处理程序，每个处理程序对应一个URL，但是所有的HTTP请求都要通过同样的管道路由。
        网络基本上是一个无状态模型，并且在HTTP请求间没有联系，这使得编写网络应用程序很困难，因为应用程序通常需要维护跨多个请求的状态。ASP+增强了由ASP引入的状态管理服务，以便为网络应用程序提供三种类型的状态：应用程序、会话和用户。就像在ASP中一样，应用程序状态特定于一个应用程序实例，并且不会持久。会话状态是特定于一个用户与应用程序间的会话的。与ASP会话状态不同，ASP+会话状态储存在一个独立的过程中，并且可把它配制成可以储存到一个独立的机器上。这使得会话状态当应用程序在网络群（Web farm）扩展时非常有用。用户状态类似于会话状态，但通常它不会超时，并且是永久性的。因此，用户状态对储存用户参数和其它个性化的信息是有用的。所有状态管理服务都被实现为HTTP模块，因此它们容易增加到应用程序管道中，或从中删除。
        如果除了由ASP+提供的服务外，还需要额外的状态管理服务，那么可由第三方的模块提供。
ASP+同样提供高速缓冲服务，以改善性能。输出缓冲可完全节省网页翻译，段缓冲储存部分的网页。由于提供了相应的类，所以只要需要，应用程序、HTTP模块以及请求处理程序就可以在高速缓存中储存任意数量的对象。

9.8  ASP+网络表单
        网络表单把基于Visual Basic表单的高生产性优点带到了网络应用程序的开发中来。网络表单支持传统的将HTML内容与脚本代码混合的ASP语法，但是它提出了一种将应用程序代码和用户接口内容分离的更加结构化的方法。引入的网络表单控件用于为封装通用用户接口元素提供了一种机制。这些新的特点使得开发工具在支持VB小应用程序的同时，也支持设计模块。
        网络表单控件负责生成用户接口，典型情况是在HTML表单中。ASP+提供了一套映射传统的HTML用户接口小部件（包括列表框，文本框和按钮）的网络表单控件和一套附加的网络控件（如日历和广告转板）。这些控件的一个重要特点是，它们可以被编写以适应客户端的能力；同一网页把大范围的客户端平台和表单因素作为目标。换句话说，网络表单控件能“嗅”到正在查找表单的客户，然后返回合适的用户经验——可能是适合低级浏览器的HTML3.2或是适于IE5.0的动态HTML。
        考虑到网络是一种无状态的联接模型，网络应用程序开发人员所面临的一个很复杂的问题是，他们要对用户与基于网络的接口的交互作用作出反应。网络利用ASP+的体系架构提供了一套丰富的服务，以帮助开发人员建立交互式网页。用户与网页交互作用的状态管理的复杂性被ASP+网络表单和网络表单控件隐藏起来了。对开发人员来说，提供的丰富数据绑定服务使得显示通过数据访问服务得到的数据变得非常容易。
代码与内容的分离使ASP+网页能动态地编译到受控类中，用以提高性能。每个引入的HTTP请求都被传递到一个新的网页实例中，因此开发人员不需要关心代码中的线程安全性问题。

9.9  ASP+网络服务
        ASP+网络服务体系架构为用ASP+建立网络服务提供了一个高级可编程模板。虽然建立网络服务并不需要使用网络服务平台，但是它提供许多的优点将简化应用程序的开发过程，并且它使用的编程模型对用ASP或VB工作的开发人员来说是很熟悉的。使用这个可编程模型，开发人员可以不需要理解HTTP、SOAP或其它任何网络服务规范。
开发人员用ASP+生成一个扩展名为 .ASMX的文件，并把此文件配制为网络应用程序的一部分，就建立起了一个网络服务。ASMX文件包含受控类的引用，或这个类的定义。这个类是由ASP+提供的WebService类所派生的。公有的类方法在标记上WebMethod属性后，就会成为网络服务方法，把HTTP请求发送到ASMX文件中的URL后，这些方法就会被调用。你不必手工为你的网络服务建立一个契约。当被调用者发出请求时，ASP+会检查类的元数据，从而自动生成SCL文件。
客户可通过SOAP、HTTP GET和HTTP POST提交请求。对方法和参数进行编码的约定是：HTTP GET，将被编译为查询字符串；HTTP POST，将被编译为表单数据。HTTP GET和HTTP POST 的机制不如SOAP有力，但是它们使得客户在访问网络服务时不必支持SOAP。
        ASP+网络服务模型假定了一个无状态服务结构。无状态结构通常比有状态结构更具可扩展性。每次收到一个服务请求后，就生成一个新对象，请求被转化为一个方法调用，当方法调用返回时对象被销毁。如果这些服务需要跨请求维护状态，那么它们将使用ASP+状态管理服务。基于ASP+的网络服务在网络应用程序模型中运行，因此它们得到了该模型的所有安全、配制和其它优点。
        ASP+网络服务还提供了一个为在SCL文件中描述的网络服务生成分类的受控代理工具。代理生成器把SCL文件中描述的消息映射成受控类中的方法。代理对应用程序代码隐藏了所有的网络和引导设备，因此使用网络服务看起来就象使用其它受控代码一样。代理将优先使用SOAP链接网络服务，但是它同样支持HTTP GET和HTTP POST机制。
结论
        网络服务为在Internet上绑定应用程序提供了简单的、灵活的、基于多标准的模型，同时，最大可能地重用现存体系架构和应用程序。网络应用程序可以很容易地与本地开发的服务或已存在的服务集成在一起，而不用考虑开发平台、开发语言或使用的对象模型，以用于实现任何组成的服务或应用程序。
Microsft.NET框架为开发人员提供了一个极为方便的开发环境，从而简化了安全、可靠、可扩展、高可用性的网络服务的建立、部署和不断的发展。