Web Services何时才能更具意义?-.NET教程,Web Service研发
目前web services还是一门相当新的技术，而且不是每个人都知道该怎么充分利用他们。以我的经验（我曾在web services底层架构上构建了一个完整的企业软件产品），我发现web services有这样两个主要用途：将多个系统整合到一起，及将功能函数(function)作为组件提供给远程调用。本文我将介绍在使用后一种方法时需要注意的问题。
当你想要用web service来提交一个新的函数或service给可能要远程调用的客户端时，你需要考虑到许多因素。不论这个函数是用于内部还是用于外部的客户或合作者，在visual studio .net中开始一个新的web service项目之前先设计一个大纲会帮你节省不少时间。比如，在需求访问专属数据库时及/或在非常难实现本地部署或造价太高时，将一个功能函数作为一个web service来提供就会非常有意义。用于执行简单计算的函数不需求访问专属数据，同时在进行本地部署或维护方面也没那么复杂。
当功能函数需要一个复杂的安装过程或一个复杂的、昂贵的硬件设置时，使用web services或许是你的最佳选择。在这种情况下，将功能函数作为一个web service来提供会为你的客户解决非常多麻烦事，因为他们不用在本地部署他。如果你经常需要发布一个功能函数的新版本，那么你也该考虑用web services。一个web service会提供一种简便的方法给所有使用该功能函数的客户发布升级版本，而无需在每次发布新版本时让他们重新部署一遍。公众所期望的通过web service接口提供需要访问专属数据的功能函数是不容易得到的。不管怎样，客户端需要能够得到数据，而web service显然是个比传送普通文件（flat file）数据更好的方法。最后，最佳能将依赖于经常改动数据的功能函数作为web services来提供。在更新数据速度和更改数据大小方面的提高会使远程访问专属数据的优势更为明显。
在你决定是否将一个功能函数作为一个web service来提供时，部署问题是个最重要的因素。web services会使软件的部署更简单。比如，如果你在构建一个指导驾驶的应用程式，你就不必担心怎么安装地图软件。或如果你有一个需要经常升级的功能函数，你就不必每几个月就回到公司让他们帮你部署更新。
明智地选择web services
然而，你要了解并非web services的所有方面都是好的，他们也有好处和缺点。当然，在开始你的项目之前你得确认其好处是多于缺点的。否则你唯一需要用到新的web service的地方就是在你的简历中了。
比如说，一个运行于其他架构中的web service肯定不如在你自己的服务器中运行的那么可靠。即便是保护最完善的和维护得最佳的网络在某些方面也并不是完全牢靠的。你必须能够向你的客户证实，无论是在内部还是外部，在service的部署和维护方面有非常大优势来弥补本身固有的在一个易出错的网络中远程访问功能函数所带了的不足之处。
我最喜欢用平方根功能函数来说明一个典型的“错误”使用web service的例子（见表1）。虽然这个场景有点夸张，但却非常能说明问题。平方根功能函数没有体现所有web service所提供的优势，相反却体现了其所有的缺陷。对他进行部署并非难事，而且他没有（至少最近没有）因为发生了变化而需要进行重新部署，这样一来就使web services部署优势不能够体现出来了。而且，他不必访问所有数据库或专属数据来实现计算功能。然而他的确需要将功能函数请求发送到web服务器，这会致使web service因为其本身固有的缓慢或无网络链接问题而执行地非常慢。在这种情况下，一个象平方根这样的小函数会导致一个非常大的应用程式的机能完全停止。在你首次尝试web services时，他会试图将一些应用函数（utility function）作为web services来发布――一些将位图（bitmap）转化为jpeg的函数或压缩位图数据的函数。这些功能函数或许是非常便利的，但他们并不适合用web services提供。
当数据可能会对其他部门有用时，内部的department-to-department (d2d) web services可能会适用于所有功能函数，甚至是一些非常难部署的功能函数。web services提供了一种非常棒的方法能够快速高效地在企业内部实现对软件部署和维护，而无需去访问防火墙以外的web services。因为d2d web services是在你的网络内部运行的，这样就减少了由于网络问题而导致程式中断的可能性，而且volume的层级也更容易预测。
通常在一个部门构建需要访问其他部门管制的数据的程式时，持有这些数据的部门会设置一个数据输出程式（data export procedure）将一个包含该数据的普通文件传输到所需要的部门，这样他们便能将数据导入数据库中了。遗憾的是这种极不方便的共享数据方法还是非常普遍的。web services提供了一种更好的方法为内部部门数据共享加载普通文件数据。web services不是将原始数据传送过去让客户端程式自己进行数据处理，而是更多地让你来控制，他们会提供计算功能而不是用来计算的数据。这不仅是一种更稳定的信息共享的方法，而且他还提供了一种机制来增强和数据有关的商业规则。
尽管采用了同样的方法，对需要通过web services来提供给外部的功能函数的评估还是非常重要的。使用一个外部企业提供的web service的危险性更大一些。然而，这种危险性会被他们能充分利用分布程式跨防火墙而无需在本地部署service的优势所抵消（见表2）。
考虑以下问题
在你向公司建议将某一功能函数作为一个web service 提供给你的商业伙伴或用户时，你需要说明其优势是否大于劣势。先考虑下面这些问题的答案会对你有所帮助：
对使用的程式而言，该功能的紧急性有多高？
传入或输出web service 的数据有多敏感?
数据源是什么? 他多长时间更新一次?是否是公开的?
你多久参和一次该功能新版本的发布？
谁在控制web service所处的架构? 该架构是否可靠?
web services在大多数it企业都具有利用潜力，尤其是在软件部署方面，但你也不能将他随意使用到所有地方。你要避免毫无意义地将功能函数或服务用做web services。有时在本地部署是非常有必要的。
当你想要用web service来提交一个新的函数或service给可能要远程调用的客户端时，你需要考虑到许多因素。不论这个函数是用于内部还是用于外部的客户或合作者，在visual studio .net中开始一个新的web service项目之前先设计一个大纲会帮你节省不少时间。比如，在需求访问专属数据库时及/或在非常难实现本地部署或造价太高时，将一个功能函数作为一个web service来提供就会非常有意义。用于执行简单计算的函数不需求访问专属数据，同时在进行本地部署或维护方面也没那么复杂。
当功能函数需要一个复杂的安装过程或一个复杂的、昂贵的硬件设置时，使用web services或许是你的最佳选择。在这种情况下，将功能函数作为一个web service来提供会为你的客户解决非常多麻烦事，因为他们不用在本地部署他。如果你经常需要发布一个功能函数的新版本，那么你也该考虑用web services。一个web service会提供一种简便的方法给所有使用该功能函数的客户发布升级版本，而无需在每次发布新版本时让他们重新部署一遍。公众所期望的通过web service接口提供需要访问专属数据的功能函数是不容易得到的。不管怎样，客户端需要能够得到数据，而web service显然是个比传送普通文件（flat file）数据更好的方法。最后，最佳能将依赖于经常改动数据的功能函数作为web services来提供。在更新数据速度和更改数据大小方面的提高会使远程访问专属数据的优势更为明显。
在你决定是否将一个功能函数作为一个web service来提供时，部署问题是个最重要的因素。web services会使软件的部署更简单。比如，如果你在构建一个指导驾驶的应用程式，你就不必担心怎么安装地图软件。或如果你有一个需要经常升级的功能函数，你就不必每几个月就回到公司让他们帮你部署更新。
明智地选择web services
然而，你要了解并非web services的所有方面都是好的，他们也有好处和缺点。当然，在开始你的项目之前你得确认其好处是多于缺点的。否则你唯一需要用到新的web service的地方就是在你的简历中了。
比如说，一个运行于其他架构中的web service肯定不如在你自己的服务器中运行的那么可靠。即便是保护最完善的和维护得最佳的网络在某些方面也并不是完全牢靠的。你必须能够向你的客户证实，无论是在内部还是外部，在service的部署和维护方面有非常大优势来弥补本身固有的在一个易出错的网络中远程访问功能函数所带了的不足之处。
我最喜欢用平方根功能函数来说明一个典型的“错误”使用web service的例子（见表1）。虽然这个场景有点夸张，但却非常能说明问题。平方根功能函数没有体现所有web service所提供的优势，相反却体现了其所有的缺陷。对他进行部署并非难事，而且他没有（至少最近没有）因为发生了变化而需要进行重新部署，这样一来就使web services部署优势不能够体现出来了。而且，他不必访问所有数据库或专属数据来实现计算功能。然而他的确需要将功能函数请求发送到web服务器，这会致使web service因为其本身固有的缓慢或无网络链接问题而执行地非常慢。在这种情况下，一个象平方根这样的小函数会导致一个非常大的应用程式的机能完全停止。在你首次尝试web services时，他会试图将一些应用函数（utility function）作为web services来发布――一些将位图（bitmap）转化为jpeg的函数或压缩位图数据的函数。这些功能函数或许是非常便利的，但他们并不适合用web services提供。
当数据可能会对其他部门有用时，内部的department-to-department (d2d) web services可能会适用于所有功能函数，甚至是一些非常难部署的功能函数。web services提供了一种非常棒的方法能够快速高效地在企业内部实现对软件部署和维护，而无需去访问防火墙以外的web services。因为d2d web services是在你的网络内部运行的，这样就减少了由于网络问题而导致程式中断的可能性，而且volume的层级也更容易预测。
通常在一个部门构建需要访问其他部门管制的数据的程式时，持有这些数据的部门会设置一个数据输出程式（data export procedure）将一个包含该数据的普通文件传输到所需要的部门，这样他们便能将数据导入数据库中了。遗憾的是这种极不方便的共享数据方法还是非常普遍的。web services提供了一种更好的方法为内部部门数据共享加载普通文件数据。web services不是将原始数据传送过去让客户端程式自己进行数据处理，而是更多地让你来控制，他们会提供计算功能而不是用来计算的数据。这不仅是一种更稳定的信息共享的方法，而且他还提供了一种机制来增强和数据有关的商业规则。
尽管采用了同样的方法，对需要通过web services来提供给外部的功能函数的评估还是非常重要的。使用一个外部企业提供的web service的危险性更大一些。然而，这种危险性会被他们能充分利用分布程式跨防火墙而无需在本地部署service的优势所抵消（见表2）。
考虑以下问题
在你向公司建议将某一功能函数作为一个web service 提供给你的商业伙伴或用户时，你需要说明其优势是否大于劣势。先考虑下面这些问题的答案会对你有所帮助：
对使用的程式而言，该功能的紧急性有多高？
传入或输出web service 的数据有多敏感?
数据源是什么? 他多长时间更新一次?是否是公开的?
你多久参和一次该功能新版本的发布？
谁在控制web service所处的架构? 该架构是否可靠?
web services在大多数it企业都具有利用潜力，尤其是在软件部署方面，但你也不能将他随意使用到所有地方。你要避免毫无意义地将功能函数或服务用做web services。有时在本地部署是非常有必要的。
