我们所使用的技术在源数据中不会出现并发更新的时候效果很好。话句话说，在任何时候都必须只有一个用户对数据库表中特定的行进行读写操作。但是，在许多应用程序中都会出现并发操作的情况。因此，如果没有准备的话，就会产生各种各样的问题。当有多个用户对数据进行更新时（通常将这个问题称为并发）所出现的一些情况，利用下面的例子我们很容易看出出现这种问题的原因。

例如，会计收到一个顾客的传真表明他的地址已经改变。于是她打开浏览器上的顾客记录对地址栏的值进行修改。于此同时，外送（他收到了传真的复印件）决定对这个顾客的送货路径代码进行更新，他打开浏览器上的顾客记录以修改路径代码栏的值。在外送进行操作的时候，会计完成了对地址的编辑，并将记录保存到了数据库中。不久后，外送也将他的更新记录保存到数据库中。

DataSet的表中的每一行都有一个RowState属性，该属性表明自从该表被填充后，或是自从AcceptChanges方法或RejectChanges方法最后一次被调用后这一行是否被修改过。因此，为了获得被修改过的行所组成的列表，只需迭代表来查看他们的RowState属性，并将所需的行提取到一个数组中或是其他的表中。

将数据收集到一起并将它们转移到其他的地方的过程通常称为调度。我们希望将修改的行从一个表中调度到另外一个表中，.NET的数据访问类使得我们能够通过DataSet对象的GetChanges方法很容易达到目的。它返回一个只包含被修改的行的DataSet对象。GetChanges方法利用方式有两种：1、没有参数，返回一个带有默认表的DataSet对象，这个表中包含所有被修改的记录，也就是所有被修改、删除和插入的行。2、以一个DataRowState值作为参数，返回一个带有默认表的DataSet对象，这个表被具有RowState属性的值的被修改的记录所填充，也就是说那些被修改的或是被删除的或是被插入的行所填充。

我们一开始加载的模式包含了后面加载的XML数据结构的定义，但是，我们可能不想使用模式，或者没有模式可用。如果该XML结构不是一直固定，这种情况就会经常出现。为了避免必须不断地动态生成XML数据创建新模式，我们可以完全省略模式，只有ReadXml方法来加载XML数据。该DataSet会从XML文档结构自动推断出数据的结构。但是，如果因为某种原因（通常是由于文档结构不一致），它不能做出自动推断，这时我们可能就取不出该DataSet中的数据。

所以请记住，如果没有模式，DataSet就可能对关于是什么结构的问题，从我们那里得出完全不同的结论——因此，只要可能的话都要包含模式才是明智的做法。当XML文档格式正确时，他就会被加载——但是结果可能并不是我们想要的。通过将合适的数据加载到DataSet中，然后调用WriteXmlSchema方法，我们就可以创建模式。另外，我们也可以将模式包含到XML数据文件或文档中，而不是将它作为一个单独的文件。在这种情况下，当我们加载文档时，数据的结构就被自动指定了，而且不需要执行ReadXmlSchema.

我们还要重复一个最先在数据库管理中学习的问题，我们以前曾经做过用新的XslTransform对象对XML或XSLT转换时很容易的。但是，那是我们用的是很基本的方法——通过制定这些文件的路径来将转换应用到两个磁盘文件（XML文档和样式表）。

当文档并不是一个磁盘文件时，我们可以用XslTransform对象来执行转换。这种情况在处理XML的应用程序中很可能出现，例如XML可能别一个XmlTextReader引用，或者可能存储在由web服务或业务组件返回的XmlDocument对象中，甚至可能有一个现有的XPathNavigator指向该XML的指针。另外，我们可能不需要将结果写成磁盘文件——而是要将他们作为一个String或StringBuilder对象。

要通过XML和HTTP解决显示应用程序逻辑或细节信息的问题并不困难。过去，我们使用诸如ASP、JAVA或Perl这样的语言编写一个简单的应用程序，此程序可以通过XML显示数据。例如，可以使用ASP编写简单的应用程序，接受查询字符串的值，并生成代表具体数据库表的XML返回文档。应用程序可以简单地调用终点（比如，显示数据库表的URL），并从文档中获取、分析和派生值。

但是这种设计方式是与其他因素紧密联系的。客户机希望得到高度结构化的XML文档，如果提供这种文档的应用程序发生了变化，则客户机实现就很有可能中断。在大多数情况下，可以通过使用公共XML模式解决这个问题，但是为不同的应用程序分别维护和管理不同的模式国语麻烦。而且，XML文档还依赖于服务器的实现方式。

当希望构建web服务时，在大多数情况下，可以使用UDDI、DISCO和WSDL作为在设计时的解决方案。设计步骤如下：1、要么通过UDDI的公共web服务，或者通过浏览器，我们可以将申请信用卡web服务的意向传递给UDDI节点（节点维护可以使用的服务）。2、UDDI给出信用卡服务列表。3、有UDDI返回的服务列表向我们提供URI，可以映射DISCO文档或WSDL文档。在此我们使用DISCO文档。除了UDDI提供的编程细节之外，我们还可以在一个UDDI.org节点发现用于服务的文档。一般服务的提供者会告诉我们服务可以提供的内容的细节信息。4、我们跟踪DISCO文档的URI。在DISCO文档之内，我们发现一个WSDL文档列表的位置。5、在分析了DISCO文档之后，我们可以跟踪WSDL文档的UR了,该文档与信用卡验证相关，并可以发送web服务。6、分析WSDL文档，并基于在WSDL内所提供的详细信息构建代理对象。

正如ASP.NET可以选择代码后置一样，ASP.NET Web服务也可以选择代码后置选项。代码后置是使用Visual Studio.NET创建的ASP.NET web服务的默认行为。应用程序逻辑不是存在于.asmx文件内，而是存在于外部CLR装配件之中。为了应用外部装配件，装配件必须驻留在ASP.NET应用程序的bin目录中。Bin目录是ASP.NET应用程序使用的特殊目录，在其中可以部署并自动注册装配件。

为了可以使用代码后置选项，可以通过一行简单的实现代码生成一个小型ASP.NET web服务.asmx文件。然后需要在单独的装配件中实现Fibonacci类，该装配件在ASP.NET应用程序的bin目录中编译和部署，或者也可以在配置文件直接命名的装配件中实现。

Web服务依靠XML和HTTP编码和传输串行化的应用程序数据。在网站建设编码中联合使用这两种技术为跨平台分布式应用程序提供了强大的功能，并具备通过代理推送应用程序的能力。但是，此技术也有一些缺点。在描述两个应用程序之间本来很简单的数据交换时，这种方法却非常繁琐，而且它是无状态的。所推荐的网站设计模式是，应该尽可能地降低对web服务的网络调用的次数。

HTTP是一个无状态的协议，这一点对于使用HTTP传输SOAP消息的ASP.NET Web服务来说仍然相同。ASP.NET为这种无状态的障碍提供了交通 ，但是这种变通办法依赖于回话符号，回话符号可以存储在HTTP cookie中，也可以潜入在URL中。
当构建web应用程序时，当然应该考虑HTTP的无状态本质。

Web服务代理默认使用internet explore配置的设置访问internet。如果本地网络依靠代理服务器访问外部internet（这是大多数公司的处理办法），而且如果还没有配置IE来使用这个代理——或者如果希望使用不同的代理服务器——则可以通过Proxy属性使用web服务代理中的这个选项。

代码将URL属性设置为WSDL中location的值。尽管在代理中值是预先配置的，但是可以在运行时使用代理的URL属性，清楚此设置或重新设置属性值。因为可以重新设置代理使用的URL，所以这就意味着可以动态地选择要使用的web服务，或为多个web服务使用公用的代理。例如，如ugowomen构建电子商务站点，并希望使用信用卡web服务，用于验证信用卡，则我们可以联合使用Timeout和URL属性。如果对服务的给定调用超时，例如对信用卡web服务的调用，则我们可以编写代码，将URL改变为由另一个供应商提供的web服务的URL，并调用备用服务。这当然是先假设要么是代理支持所有的服务，要么是所有的服务实现公用的web服务API。

显然，VS.NET在后台完成了许多工作，如创建代理，发送和接收SOAP请求和响应。我们可以访问、修改VS.NET为代理编译的源代码。我们无法默认获得这些源代码，但是如果在Solution Explorer中的工程上右击，并选择Add Existing Item，就会打开一个文件选择对话框。文件选择对话框当前正在访问的位置是工程的根目录。可以看到localhost文件夹（如果重新命名了web reference，则是其他名称）。如果打开此文件夹，就可以发现代理的源代码。

代理以工程所使用的语言创建，使用VB.NET，因为它是ASP.NET web应用程序。文件包含代理的源代码。如果打开它，则它就会添加到当前的工程中，我们就可以查看或修改它的源代码。使用VS.NET创建代理比较简单。只要有WSDL的URI，VS.NET就会自动完成剩下的工作。我们可以编写代码，并调用方法，我们以为只是在调用一个本地类，而事实上，代理在与web服务交换SOAP消息。