每当重要的新技术出现时，各个企业的态度主要有以下两种。一些企业认为重要的技术可以解决目前的实际问题，可以更有利于他们今后的发展。另外一些公司并没有采取行动，而是抱着观望的态度，看看这种新技术是否经受得住考验。不可避免地，这些公司将不得不扮演追随者的角色，这样他们在设计和实施程序的过程中就很可能被迫采取一些折衷的方式，从而缩短采用周期。虽然对一个公司来说，不同技术的重要程度不同，但是延迟对一种重要技术的采用就可能失去很有价值的市场份额，或者失去一些机会，这种损失是不可估量的。

　　Web services就是一个恰当的例子，一些公司已经把自己放在一个追随者的位置上了。考虑到目前的Web services并不成熟，这种说法听起来似乎有些操之过急了。但毕竟现在已有少数的有意义的Web services是可以用的，而且人们也不断地为此做着努力。在本文中，我将讲述为什么现在开始采用Web services很重要，重点讲述Web应用程序和Web services之间的重要不同，并论述在企业采用Web services的过程中常见的两个困难。然后，我将略述一个采用模式，你可以用它来克服这些困难，聪明地将有用的Web services用于你的企业中。

　　首先，我讲一下相关的背景。业界大肆宣传Web services已经有近三年了，但它们似乎仍没有很强的吸引力。的确，许多供应商在他们的工具和应用程序服务器中都构建了对Web services的支持，但他们并不清楚是谁在运用这些Web services。甚至Microsoft都已经紧缩了它对.NET My Services的供应。如果Microsoft都没有准备好，那么其它人如何做好准备提供Web services呢?虽然看上去似乎在Web services开始被采用前就失去了动力，但实际上，它们只是在广泛普及上所花的时间比许多人的期望要长了些。虽然Microsoft在公布HailStorm(aka My Services)上似乎有些行动过早了，但它正采取措施提供诸如MapPoint.NET这样的有用的Web services(见资源)。有些公司采取观望态度的理由是Web services的采用率很慢，在此他们犯了一个错误。正确地理解Web services技术和市场情况可以反映出你在采用Web services上是等不起的。

　　20世纪90年代中期的Internet革命使人们对技术的采用率的期望越来越高，甚至到了一种可笑的程度。在六个月的时间内，人们可以公布、开发、运用、批评以及放弃一种技术。(还记得推技术(push technology)吗?)应用程序技术的稳步的、快速的进步不仅有助于为Internet革命定下基调，而且为一个企业在运用Web方面提供了一个明显的途径。

　　由于Web应用程序变得日益复杂了，它们已经从简单的、静态的行销站点转变成了客户交互的工具(见图1)。随着企业在运用Web应用程序上不断的进步，这些应用程序就从吸引用户的手段发展成提高公司内部人员工作效率的一种方式了。一旦公司对用于内部的Web应用程序感到满意，那么他们开始将这些程序用于与合作伙伴的合作就只会是个时间问题了。

　　差别

　　虽然许多人承认Web services和Web应用程序之间是有差别的，但他们常忽视一个重要的不同点——有意义的Web应用程序可以是独立的实体，而有意义的Web services则不可以。这种差别会导致两个因素，一些企业认为这两个因素会对Web services的采用带来障碍。

　　第一个因素就是复杂性-风险方面。Web services在本质上比Web站点更复杂，不是因为其技术特别复杂，而是因为Web services必须与企业关键的系统和过程结合起来。任何值得提供的Web services都包含动态的数据和与关键系统的交互。Web services的作用并不等同于 “行销小册子”似的站点，而许多企业早期涉足的都是Web站点。运用Web services，你才真正进入Web的领域，其复杂性为部署Web services带来了更高的风险。如果你的公司提供了一个用做计算器的Web service，那么等其它人开发一个更好的服务，使你的服务商品化，就只是个时间的问题了。企业不会为这种Web services提供更多的价值，也不会从这种Web services中得到更多价值，它们只会受益于与它们的私有数据或过程结合在一起的Web services;因此就存在本质的风险和复杂性。

　　这种风险与提供 Web应用程序相关的风险是类似的，但减轻这两种风险的策略没有必要是一样的。许多公司在第三区域(demilitarized zone(DMZ))隔离Web系统，不直接与重要的后端系统结合。作为替代，他们运用一个批处理来定期地传递必要的数据。虽然这种方法有时侯可以用于一个应用程序，但对于有意义的Web services，它却是不可接受的。它们需要与你不能转移到DMZ的系统交互。如果你以这种方式创建一个Web service，你就不得不置疑它对其他人的价值。同Web应用程序一样，我们可以用一些方法安全地提供Web services并连接到内部系统，许多企业需要更新他们的独立的安全策略来与Web services保持同步。

　　第二个因素就是Web services的合作方面。运用Web应用程序，你可以控制整个过程和用户经验。只有客户端浏览器是你不能控制的，它在任何Web应用程序中的作用都是最小的。近年来，浏览器已经成为几乎所有计算机的一个共同的组件，这就给了开发人员和设计人员一个相当一致的交付工具，使应用程序的部署更简单了。相反，至少要有两个既定方要参预对一个Web service的使用。对Web services来说，不存在浏览器型的客户端。作为替代，一个中间方(应用程序)管理Web services和最终用户之间的交互。一些Web services的交互可能不包含最终用户，它只是两个系统在没有任何人参预的情况下的沟通。

　　应用程序使用真正的Web Services

　　这并不是说你不能像操作Visual Studio .NET(VS.NET)中的一个.asmx页面那样运用一个浏览器来测试Web services或与Web services交互。然而，一个真正的Web service是由一个应用程序使用的，而不是被运用一个浏览器的人使用的。虽然你可以构建一个普通的Web services的使用者，甚至通过UDDI(Universal Discovery, description, and Integration)和WSDL(Web Services Description Language)动态地使用Web services，但无论如何关键的企业进程是不能很快地以这种方式使用Web services的。Web services是关于集成应用程序过程的。如果你的目的是在Web上将任何过程直接呈现给最终用户，你就选错了方法。多年以来，Web应用程序已经提供了那个功能。

　　这两个因素就使得采用Web services的途径与许多人期望的途径有所不同。虽然采用Web services的道路是不同的，但这并不是说你不能吸取Web应用程序发展过程中的经验;你只需要识别这两条道路在哪里会有不同。

　　通过选择我前面提到过的对新技术采用的两种方法的一种，你就可以管理这些因素。一些企业正在等待第三方供应商来设计出细节，减轻大部分(如果不是全部)与提供Web services的复杂性相关的风险。他们知道Web services需要是安全的，来保护他们的信息和资产，但他们既不能保证、也不确信Web services的安全性。因此，他们选择等待完全的“取出即可用(out-of-the-box)”的解决方案。这种方法就使企业进入观望的境地，因为Web services完全生命周期“标准”的许多组件都仍在开发中。如我前面所讲的，这种态度可能是很危险的。第二个因素可能会使一个企业决定不提供Web services，因为没有人要求它这么做，而且它也看不到竞争。这种态度也会使企业陷入不利，因为大多数Web services项目都没有完全公布。不能因为你没有随处看到Web services，就认为你的客户正在运用的Web services中不存在竞争。

　　拥有这样想法的企业已经把这两个因素变成了他们采用Web services过程中的障碍。幸运的是，一些企业已经意识到Web services的复杂性-风险方面和合作方面只是小的困难，而不是大的障碍。下面，我将略述你的企业如今可以实现的一个Web services采用模式来保证你不会落伍。

　　你可以先在内部提供Web services来连接完全不同的应用程序。因为现有的所有中间件解决方案，如果在看第一眼时，你认为Web services在你的企业中没有用，那就再细看一下。甚至小一些的公司在系统访问上都会有局限，现有的解决方案不能解决这个问题，而Web services则会有帮助。

　　回想一下你的公司开始将Web应用程序结合到你的后端系统的时候。后端系统可能是个连接到主客户数据服务器的在线注册系统，或者是个发送定单到一个执行系统的电子商务系统。你总是会遇到一个系统，它的所有者或者不相信你的Web应用程序，要求权限，或者不给本地API调用提供一个好的方法，你只能采用一个批处理来接受或抛弃陈旧的数据。这样的情况就给Web services提供了很好的机会来为双方都需要的受控权限提供帮助。系统的所有者有机会在系统中定义接口，你不用再得到陈旧的数据，或运用一个不稳定的、低水平的协议了。

　　为其它应用程序需要的系统实现Web services也为缓解第二个因素——合作方面——提供了基础。你最初决定运用Web services是想利用现有的对交互的需求，这种交互会给你带来成功。你不用担心你构建的一个Web service没有人用，你的Web service失去了动力或者你的努力是不成功的。

　　控制共享过程

　　你可以控制享用过程的双方，因为你的Web services是在内部提供和使用的。它不仅会降低你首次尝试Web services的整体风险，而且会给你提供机会，使你对.NET Web services中可用的安全选项感到满意，它们有些类似于用于Web应用程序的Secure Sockets Layer证书，Kerberos和Simple Object Access Protocol headers。

　　一些企业已经采用了这种方法，逐步超越了他们的局限性来实现并运用Web services。为了控制住复杂性-风险和合作方面的困难，企业需要将他们最初的Web services推广到一个单一的合作伙伴或有限的几个合作伙伴中。这就可以使你进一步监控并解决任何初步的问题。它还可以让你针对作为你的服务使用者的主要的候选人，有助于你收集需求或确定你的最初的Web services的价值。合作伙伴应该是你们公司已经与之建立了稳固关系的人，你可以信任他们，提供对服务的完全测试，他们不会利用可能的(不一定与安全相关，而是与过程相关的)“漏洞”。

　　在做了这些初步的努力后，你的企业在将Web services部署给更多的合适的合作伙伴时就会更得心应手，不用再担心那两个困难了。在这个方法中，UDDI以及WSDL(VS.NET自动提供)可能为你的Web services解决方案作出更重要的贡献。

　　到目前为止，我已经略述了Web services的一些情况，其相互之间直接联系的用户人数很有限。虽然WSDL有助于通过VS.NET来使用一个Web service，但你最初的努力可能会有一个快速的构建周期，你和你的用户通过通信和XML文件手动地沟通所有的变化。当你准备将你的服务公开给大量的用户时，UDDI和WSDL在保证你的Web service实现时间上是关键。手动地解决每个新用户的问题最终会导致你和你的潜在用户间的瓶颈问题，它会阻碍你的Web services的采用率。

　　一旦你大规模地将一些Web services部署给已确定的合作伙伴了，你就做好准备公开它们了。我指的并不是最终用户，因为我们从Web应用程序已经认识了他们。你将你的Web service提供给你可能知道或者不知道的合作伙伴，他们需要你的Web service。如果你遵循前面的采用步骤，你应该有信心你提供的Web service给系统带来的风险很小，底层框架支持它，同样很重要的还有你所呈现的商业过程的可靠性。现在你已经公开了你的Web service，你可能会认为你已经成功了，但你只是刚刚开始。

　　你已经提供了一个Web service，它的支持系统很有限。即使你运用一种标准的方法来验证用户，你仍然没有任何自动的过程来注册新用户。你可能已经与合作伙伴建立了协议，但你没有对你的Web service收费(至少不是以对它的使用为基础)。你也可能需要跟踪输入的Web services请求，并考虑你如何可以跨多个步骤管理事务或过程。

　　这些类型的服务都是一些附加的功能，它们可以用来创建一个强大的Web service，但是它们在我所讲述的最初的Web services采用道路中不一定是个必要条件。它们应该在适当的时候结合到我们的Web services中，在使我们的Web services变得更成熟上很有必要。但是，他们都不是重点，因此缺少这些东西不会成为你在采用Web services过程中的另一个障碍。

　　当你的企业决定了如何、何时采用Web services后，你不应该等到所有的Web services问题都得到解决。你应该意识到在Web services领域中，你的企业有很大的机会成为一个驱动者，而不是追随者。如今，VS.NET为你提供了平台来安全地构建Web services。如果你了解了你的企业提供的或维持的主要服务，并确认了你可以通过内部或外部Web services提供服务的候选人，那么你的竞争力就会有飞跃。