企业应用中WebServices的冲击
[摘要] 本文介绍了WebServices的起源和基本原理，分析了在企业应用中WebServices带来的冲击和变革，指出了WebServices的一些优缺点以及如何正确地应用WebServices.
[关键字] WebServices 应用
[关键字] WebServices 应用
本文介绍了WebServices的起源和基本原理，分析了在企业应用中WebServices带来的冲击和变革，指出了WebServices的一些优缺点以及如何正确地应用WebServices.
无论是在计算机杂志还是在Internet上，目前最热门的话题莫过于“WebServices”。各个平台之间的锋争，各个新产品的发布，众多新标准的制订，大都和WebServices有关。
我的一些朋友是这样的一些人，他们总是用着最新的平台，尝试着最新的技术，他们喜欢变化，喜欢流行，用他们自己的话说，新技术创造新生活！可是，当我的一个朋友，带领他们一个部门的开发人员，花了两个月的，将他们内部的管理系统用WebServices重新设计和实现了一遍，却发现在实际使用的情况下，系统性能非常糟糕。他提出了这样一个问题：是不是WebServices现在还处于实验和市场炒作时期，根本没有进入实用的阶段？简单的回答是：WebServices不是万能的，它有它的应用范围和优势劣势。
WebServices的起源
Web应用的巨大成功和不断发展，使其渗透到商业领域和个人生活的各个方面。人们只要使用浏览器，就可以享受到各种各样的Web服务，例如网上购物，网上交易，网络游戏，预定车票，网上聊天和交友等等。与此同时，由于Web技术所带来的优势（统一的客户端和较好的维护性），使一些传统的应用纷纷转型到BS结构上。
然而，在发展中，逐步暴露了一些问题。所有这些Web页面都是为人准备的，是让人去阅读，去输入，去判断。因此各种反映视觉效果的内容占用了大量的网络带宽，例如各种图片，字体信息，文字排版样式等。而真正含有高价值的一些信息，被深深埋在这些显示信息中，很难被其他应用和程序所使用。更重要的是，各种web服务之间缺少交互和通讯的机制。
程序之间的互相通讯很重要吗？简单举一个例子。
假设你经常去国外出差，在你回国以后，第一件事就是费用报销了。而你们公司有这样的财务规定，所有的报销款，都按报销当天的外汇比价进行结算。因此在你填写报销单的时候必须先填写每一笔在各个国家的花消，然后上网查出当天的外汇比价，填写到报销单上。剩下的事情也许不用你做了，你的报销单填写工具会自动进行换算和统计。
觉得有什么不妥吗？作为IT公司的员工，也许都有一个特点，计算机能做的事情，尽量要计算机去做。外汇比价的查询可以让计算机自动去做嘛！然而，让你的程序自动去网页上查找指定的外汇比价可不是一件容易的事。因为这些网页是给人阅读的，人眼和大脑的反应速度有多快，它们可以从一整页信息中快速定位到你所要的内容，而且无论网页怎样变化和改版都不会带来太大的影响。而应用程序想要做同样的事就差得太远了。因此，现在需要的是专门为应用程序制定的Web服务。
随着应用程序之间通讯的需求越来越大，这就需要制定统一的标准和协议。HP公司是最先提出这个观点的公司，他们制定了有关“e-Speak”的标准来保证应用程序之间的交互，并声称将成为下一代Internet信息交互的标准。而随后，MicroSoft意识到此计划的美好前景，便推出了.Net战略；IBM很快就发布了WebServicesToolkit(WSTK)，和WebServicesDevelopmentEnvironment(WSDE)，申明对WebServices的全力支持。与此同时，Oracle也开发出自己的DynamicServices，并和Oracle8iRelease2集成在一起。在这以后，W3C统一制定了WebServices的各种标准。而SUN公司在宣布了自己的WebServices的框架以后，将WebServices的标准溶入J2EE的环境，使WebServices有了广泛支持的基础和平台。
WebServices的基本原理
WebServices是通过一系列标准和协议来保证程序之间的动态连接。其中最基本的协议包括：SOAP,WSDL,UDDI
SOAP:是“SimpleObjectAccessProtocol”的缩写，SOAP是消息传递的协议，它规定了WebServices之间是怎样传递信息的。简单的说，SOAP规定了：
1.传递信息的格式为XML。这就使WebServices能够在任何平台上，用任何语言进行实现。
2.远程对象方法调用的格式。规定了怎样表示被调用对象以及调用的方法名称和参数类型等。
3.参数类型和XML格式之间的映射。这是因为，被调用的方法有时候需要传递一个复杂的参数，例如，一个Person对象。怎样用XML来表示一个对象参数，也是SOAP所定义的范围。
4.异常处理以及其他的相关信息.
WSDL:是“WebServicesDescriptionLanguage”的缩写.意如其名,WSDL是WebServices的定义语言。当你实现了某种服务的时候(如,股票查询服务),为了让别的程序调用,你必须告诉大家你的服务的接口.例如,服务名称，服务所在的机器名称，监听端口号，传递参数的类型,个数和顺序,返回结果的类型等等.这样别的应用程序才能调用你的服务。WSDL协议就是规定了有关WebServices描述的标准。
UDDI:是UniversalDescription,Discovery,andIntegration的缩写。简单说，UDDI用于集中存放和查找WSDL描述文件，起着目录服务器的作用。
实现一个WebServices，使其能够接受和响应SOAP消息（现在有很多工具都可以帮助实现）。
撰写一个WSDL文件用于描述此WebServices。（现在有很多工具可以自动生成WSDL文件）。
将此WSDL发布到UDDI上。
其他的应用程序（客户端）从UDDI上搜索到你的WSDL。
根据你的WSDL，客户端可以编写程序（现在有很多工具可以自动生成调用程序）调用你的WebServices。
WebServices的缺点
由于是基于XML的应用，WebServices与生俱来地在拥有XML带来的一切优势的同时，不可避免地继承了XML所带来的一些限制。
WebServices通常需要大量的CPU资源。因为XML数据要经过多步处理才能被系统使用。首先是效验（validate），检查它的格式是否符合XML的规范，以及根据应用程序定义（DTD或Schema）检查是否符合语义上的规范；然后还要进行解析（parse），从XML文档分解出单个的元素；最后还要转换成应用程序所需要的二进制表达（例如，把“12”转换成整型12的二进制表示）。
WebServices还意味着占用较多的内存资源。在进行XML解析的时候，会产生大量的临时内存对象。特别是在处理DOM对象的时候。这些大量的临时对象对于象JAVA这类自动回收内存的语言和系统其实是一种负担，大量的临时对象将会使系统每隔一段时间就会进行内存回收，从而降低系统的性能。当然，现在有的WebServices的产品（如axis）采用了SAX技术，大大减少了内存的占用量。详细信息请参考：（WebServices应用的一些限制。因为基于XML数据的传递通常数据量要比二进制的协议（如RMI/IIOP）要大的多。这种额外的消耗在网络资源比较紧张或网络传输比较频繁的应用中会产生一定的影响。
除了XML带来的限制，WebServices本身也具有一些缺点：
到目前为止，WebServices还可以说是一种无状态（stateless）的服务。
所谓stateless就意味着不保存客户端服务调用者的任何信息。这是由WebServices的本质所决定的。WebServices在本质上是要为应用程序之间提供数据通讯的标准，为企业应用之间动态地提供大颗粒度的服务，所以WebServices并不适合于非常精细的基于会话的方法调用以及复杂的事务（transaction）处理之中。
也许有人会对我这点提出异议！因为，现在有很多WebServices的产品（如WASD），不但可以保存session的信息，使服务成为有状态（stateful）的服务，而且还实现了remoteinterface，可以在WebServices的会话中传递远程对象的句柄，让客户端可以操纵递远程对象（详细信息请参考：XML数据中，可以互相传送任何数据，包括sessionID和transactionID，有了这些ID，从技术角度上说，实现有状态（stateful）的服务和事务处理并不复杂。但是，这样功能缺少标准的支持，当前版本的WSDL还无法表示这些复杂的服务。在企业内部，你可以任意使用这些特殊的功能，可以自己定义会话状态的交互协议，因为服务者和服务调用者之间的通讯都在你的控制之中；然而要将这些服务发布到Internet上，其他的应用程序是无法根据标准去识别这些特殊功能。
数据绑定也存在一些不足。
因为所有的数据传递都用XML格式，因此，需要在二进制数据和XML数据之间有个转换。但是，并不是所有的二进制数据都能方便地用XML来表示，并不是所有的JAVA对象都能被XML所表示。因此，经常在转换过程中会出现语义丢失的情况。
技术要求高，学习曲线较长。
每一个WebServices的产品，都有丰富的工具，能够根据WebServices的定义（如WSDL文件）方便地生成客户端的程序；能够将一般的服务程序，很容易就包装成WebServices服务。因此，各个WebServices的产品都声称自己的平台容易使用，根本不需要了解XML，也不需要了解什么WSDL，UDDI，SOAP就能使用发布WebServices。特别是一个朋友告诉我，他在什么都不了解的情况下，用.NET花了15分钟就发布了一个WebServices！
千万不要醉心于这种简便，这对于简单的Demo也许是对的，可是对于真正意义上严肃的应用，一定要了解WebServices的各个方面，设计整体结构和解决方案，还要根据具体的应用调整性能。所有这些都需要对WebServices知识的全面掌握。
什么应用适合WebServices
WebServices这么多的缺点是不是让你很泄气？其实，已经有很多成功的WebServices的应用和越来越多的开发商的加盟，证明WebServices一定会成为新一代WEB信息通讯的主流。经过不断的发展，WebServices一定能克服自身的弱点，得到更广泛的应用。但就目前来说，WebServices比较适合用于下列形式的应用：
基于WAN和Internet的应用
要在Internet上创建基于二进制协议的RMI/IIOP的应用，一般都会遇上一个大麻烦--防火墙。客户端浏览器极大可能在ISP防火墙后，大多数防火墙都只能允许和外部的HTTP连接，因此想要ISP防火墙后的客户端能和防火墙外的RMI/IIOP的应用端口进行连接的话，就要改变ISP的安全策略，让客户端能够连接除了80以外的其他端口。可是当运行RMI/IIOP的应用的服务器为了安全也在防火墙之后的DMZ中的话，那这个连接就更加复杂了，要跨越两个防火墙。
而WebServices由于使用的是HTTP协议，传递的是纯文本的XML数据，因此拥有穿透防火墙的良好性能。
基于异构平台的应用
XML语言本身就是跨平台、跨语言的数据表示方法，在加上通用的HTTP等协议，使得WebServices天生就适用于基于异构平台的应用。如果你的客户端包含了各种不同的平台，例如，你希望你的服务即可以被JAVA程序所调用，又可以由VB和COM程序所调用。你有两种选择：一种是为不同的平台提供相应的API，还要为不同的语言提供API；如果提供WebServices，所有平台和语言都可以调用了！
需要强安全特性的应用
很多人都认为，安全性是WebServices的弱项。其实不然，经过不断的完善和各种新的协议的出台，WebServices完全可以用于安全性很强的应用环境下。并且，由于WebServices使用HTTP协议进行传输，所以可以和容易就使用已经很成熟的基于HTTP的各种安全技术。
EAI（企业应用集成）
这是目前WebServices应用最看好的方向之一。大多数企业内部都有着各种各样的应用系统，它们是在不同的领导在任期间，由不同的软件开发商开发，因此运行在不同的平台和系统上，系统的开发语言也各不相同。由于现代企业信息自动化要求的提高，各个系统之间的互动和相互通讯便提到日程上。因此，保护原有投资，重用遗留系统是当前很多中大型企业的重要任务。
由于遗留系统的运行平台是异构环境，因此企业应用集成的代价一般来说是很高的。但如果使用WebServices作为应用集成的手段，将会大大降低集成的消耗。WebServices与平台和语言无关的特性，以及各种平台和环境下的开发工具都是企业应用集成的利器。
另外，在开发新的应用系统的时候，仍然需要考虑和其他系统的集成，需要考虑调用其他系统的功能，和被其他系统所调用。使用WebServices作为系统与外部交流的接口，能够使新的系统和别的系统之间保持松耦合的关系，保持较高的可扩展性。
行业内部B2B应用
行业内部的应用是WebServices的另外一个方向。因为在一个行业中，商业业务是很相似的，因此在行业内部很容易形成服务的标准，使所有的业内企业共同遵守；但怎样实现服务和使用什么样的系统，决定权在于各个企业自己。例如，电信运营商之间的结算服务，银行之间的转帐服务等都可以形成行业标准，以WSDL的形式公布出来。各个企业之间可以选择不同的平台进行服务的实现。
提高WebServices的性能
要想提高WebServices应用的性能，需要对整个系统做全盘的考虑。一般来说，有以下几点需要注意：
WebServices的颗粒度
选择WebServices的颗粒度是提高WebServices应用的性能的主要手段。因为WebServices使用的传输协议为HTTP或SMTP等，这些协议都是面向无状态的连接协议，每一个请求都要建立一个新的连接。因此WebServices的调用不能象数据库JDBC（ODBC）接口一样可以进行精细而复杂的方法调用（例如，先获得Connection，再获得结果集，然后一行一行获取结果）。WebServices比较适用于大颗粒度的应用，在一个调用中便获得所有的信息（比如说银行之间的转帐，在一次调用中就将包括金额和认证等所有的信息都传输过去）。
谨慎使用XML接口
系统之间的接口可以使用XML，这样可以增加系统的灵活性；但不要使用XML作为系统内部的接口，因为这不会带来任何好处，尽量使用二进制作为系统内部的接口，避免不必要的XML文档的解析和效验；在处理XML的时候，尽快将XML转换成内部对象，XML的传递只会增加系统的开销。
最大可能性使用CACHE
当有些信息是只读的，或者在一段时间内保持不变，就可以使用CACHE。无论是客户端的CACHE还是服务器端的CACHE，都能大大提高系统的性能
总结
一旦WebServices得到更加广泛的应用，使得各种服务可以动态查找和定位，这样就提供了不同设备之间各种各样的信息交互方式，将会大大改变商业运做的模式和信息交流的风格。
你可以使用别人已经成熟的功能来使自己提供更好的服务，例如google，它的搜索引擎可以通过WebServices来访问。这就意味着在你的系统中可以方便的嵌入使用google的强大搜索功能，而不论你的系统是运行在什么平台上，使google的搜索引擎成为你系统的一部分，（请参考http://www.google.com/apis/）。站在别人的肩膀上，毕竟要看得远些！
面对WebServices，你现在可以不行动，但你一定要准备好！
无论是在计算机杂志还是在Internet上，目前最热门的话题莫过于“WebServices”。各个平台之间的锋争，各个新产品的发布，众多新标准的制订，大都和WebServices有关。
我的一些朋友是这样的一些人，他们总是用着最新的平台，尝试着最新的技术，他们喜欢变化，喜欢流行，用他们自己的话说，新技术创造新生活！可是，当我的一个朋友，带领他们一个部门的开发人员，花了两个月的，将他们内部的管理系统用WebServices重新设计和实现了一遍，却发现在实际使用的情况下，系统性能非常糟糕。他提出了这样一个问题：是不是WebServices现在还处于实验和市场炒作时期，根本没有进入实用的阶段？简单的回答是：WebServices不是万能的，它有它的应用范围和优势劣势。
WebServices的起源
Web应用的巨大成功和不断发展，使其渗透到商业领域和个人生活的各个方面。人们只要使用浏览器，就可以享受到各种各样的Web服务，例如网上购物，网上交易，网络游戏，预定车票，网上聊天和交友等等。与此同时，由于Web技术所带来的优势（统一的客户端和较好的维护性），使一些传统的应用纷纷转型到BS结构上。
然而，在发展中，逐步暴露了一些问题。所有这些Web页面都是为人准备的，是让人去阅读，去输入，去判断。因此各种反映视觉效果的内容占用了大量的网络带宽，例如各种图片，字体信息，文字排版样式等。而真正含有高价值的一些信息，被深深埋在这些显示信息中，很难被其他应用和程序所使用。更重要的是，各种web服务之间缺少交互和通讯的机制。
程序之间的互相通讯很重要吗？简单举一个例子。
假设你经常去国外出差，在你回国以后，第一件事就是费用报销了。而你们公司有这样的财务规定，所有的报销款，都按报销当天的外汇比价进行结算。因此在你填写报销单的时候必须先填写每一笔在各个国家的花消，然后上网查出当天的外汇比价，填写到报销单上。剩下的事情也许不用你做了，你的报销单填写工具会自动进行换算和统计。
觉得有什么不妥吗？作为IT公司的员工，也许都有一个特点，计算机能做的事情，尽量要计算机去做。外汇比价的查询可以让计算机自动去做嘛！然而，让你的程序自动去网页上查找指定的外汇比价可不是一件容易的事。因为这些网页是给人阅读的，人眼和大脑的反应速度有多快，它们可以从一整页信息中快速定位到你所要的内容，而且无论网页怎样变化和改版都不会带来太大的影响。而应用程序想要做同样的事就差得太远了。因此，现在需要的是专门为应用程序制定的Web服务。
随着应用程序之间通讯的需求越来越大，这就需要制定统一的标准和协议。HP公司是最先提出这个观点的公司，他们制定了有关“e-Speak”的标准来保证应用程序之间的交互，并声称将成为下一代Internet信息交互的标准。而随后，MicroSoft意识到此计划的美好前景，便推出了.Net战略；IBM很快就发布了WebServicesToolkit(WSTK)，和WebServicesDevelopmentEnvironment(WSDE)，申明对WebServices的全力支持。与此同时，Oracle也开发出自己的DynamicServices，并和Oracle8iRelease2集成在一起。在这以后，W3C统一制定了WebServices的各种标准。而SUN公司在宣布了自己的WebServices的框架以后，将WebServices的标准溶入J2EE的环境，使WebServices有了广泛支持的基础和平台。
WebServices的基本原理
WebServices是通过一系列标准和协议来保证程序之间的动态连接。其中最基本的协议包括：SOAP,WSDL,UDDI
SOAP:是“SimpleObjectAccessProtocol”的缩写，SOAP是消息传递的协议，它规定了WebServices之间是怎样传递信息的。简单的说，SOAP规定了：
1.传递信息的格式为XML。这就使WebServices能够在任何平台上，用任何语言进行实现。
2.远程对象方法调用的格式。规定了怎样表示被调用对象以及调用的方法名称和参数类型等。
3.参数类型和XML格式之间的映射。这是因为，被调用的方法有时候需要传递一个复杂的参数，例如，一个Person对象。怎样用XML来表示一个对象参数，也是SOAP所定义的范围。
4.异常处理以及其他的相关信息.
WSDL:是“WebServicesDescriptionLanguage”的缩写.意如其名,WSDL是WebServices的定义语言。当你实现了某种服务的时候(如,股票查询服务),为了让别的程序调用,你必须告诉大家你的服务的接口.例如,服务名称，服务所在的机器名称，监听端口号，传递参数的类型,个数和顺序,返回结果的类型等等.这样别的应用程序才能调用你的服务。WSDL协议就是规定了有关WebServices描述的标准。
UDDI:是UniversalDescription,Discovery,andIntegration的缩写。简单说，UDDI用于集中存放和查找WSDL描述文件，起着目录服务器的作用。
实现一个WebServices，使其能够接受和响应SOAP消息（现在有很多工具都可以帮助实现）。
撰写一个WSDL文件用于描述此WebServices。（现在有很多工具可以自动生成WSDL文件）。
将此WSDL发布到UDDI上。
其他的应用程序（客户端）从UDDI上搜索到你的WSDL。
根据你的WSDL，客户端可以编写程序（现在有很多工具可以自动生成调用程序）调用你的WebServices。
WebServices的缺点
由于是基于XML的应用，WebServices与生俱来地在拥有XML带来的一切优势的同时，不可避免地继承了XML所带来的一些限制。
WebServices通常需要大量的CPU资源。因为XML数据要经过多步处理才能被系统使用。首先是效验（validate），检查它的格式是否符合XML的规范，以及根据应用程序定义（DTD或Schema）检查是否符合语义上的规范；然后还要进行解析（parse），从XML文档分解出单个的元素；最后还要转换成应用程序所需要的二进制表达（例如，把“12”转换成整型12的二进制表示）。
WebServices还意味着占用较多的内存资源。在进行XML解析的时候，会产生大量的临时内存对象。特别是在处理DOM对象的时候。这些大量的临时对象对于象JAVA这类自动回收内存的语言和系统其实是一种负担，大量的临时对象将会使系统每隔一段时间就会进行内存回收，从而降低系统的性能。当然，现在有的WebServices的产品（如axis）采用了SAX技术，大大减少了内存的占用量。详细信息请参考：（WebServices应用的一些限制。因为基于XML数据的传递通常数据量要比二进制的协议（如RMI/IIOP）要大的多。这种额外的消耗在网络资源比较紧张或网络传输比较频繁的应用中会产生一定的影响。
除了XML带来的限制，WebServices本身也具有一些缺点：
到目前为止，WebServices还可以说是一种无状态（stateless）的服务。
所谓stateless就意味着不保存客户端服务调用者的任何信息。这是由WebServices的本质所决定的。WebServices在本质上是要为应用程序之间提供数据通讯的标准，为企业应用之间动态地提供大颗粒度的服务，所以WebServices并不适合于非常精细的基于会话的方法调用以及复杂的事务（transaction）处理之中。
也许有人会对我这点提出异议！因为，现在有很多WebServices的产品（如WASD），不但可以保存session的信息，使服务成为有状态（stateful）的服务，而且还实现了remoteinterface，可以在WebServices的会话中传递远程对象的句柄，让客户端可以操纵递远程对象（详细信息请参考：XML数据中，可以互相传送任何数据，包括sessionID和transactionID，有了这些ID，从技术角度上说，实现有状态（stateful）的服务和事务处理并不复杂。但是，这样功能缺少标准的支持，当前版本的WSDL还无法表示这些复杂的服务。在企业内部，你可以任意使用这些特殊的功能，可以自己定义会话状态的交互协议，因为服务者和服务调用者之间的通讯都在你的控制之中；然而要将这些服务发布到Internet上，其他的应用程序是无法根据标准去识别这些特殊功能。
数据绑定也存在一些不足。
因为所有的数据传递都用XML格式，因此，需要在二进制数据和XML数据之间有个转换。但是，并不是所有的二进制数据都能方便地用XML来表示，并不是所有的JAVA对象都能被XML所表示。因此，经常在转换过程中会出现语义丢失的情况。
技术要求高，学习曲线较长。
每一个WebServices的产品，都有丰富的工具，能够根据WebServices的定义（如WSDL文件）方便地生成客户端的程序；能够将一般的服务程序，很容易就包装成WebServices服务。因此，各个WebServices的产品都声称自己的平台容易使用，根本不需要了解XML，也不需要了解什么WSDL，UDDI，SOAP就能使用发布WebServices。特别是一个朋友告诉我，他在什么都不了解的情况下，用.NET花了15分钟就发布了一个WebServices！
千万不要醉心于这种简便，这对于简单的Demo也许是对的，可是对于真正意义上严肃的应用，一定要了解WebServices的各个方面，设计整体结构和解决方案，还要根据具体的应用调整性能。所有这些都需要对WebServices知识的全面掌握。
什么应用适合WebServices
WebServices这么多的缺点是不是让你很泄气？其实，已经有很多成功的WebServices的应用和越来越多的开发商的加盟，证明WebServices一定会成为新一代WEB信息通讯的主流。经过不断的发展，WebServices一定能克服自身的弱点，得到更广泛的应用。但就目前来说，WebServices比较适合用于下列形式的应用：
基于WAN和Internet的应用
要在Internet上创建基于二进制协议的RMI/IIOP的应用，一般都会遇上一个大麻烦--防火墙。客户端浏览器极大可能在ISP防火墙后，大多数防火墙都只能允许和外部的HTTP连接，因此想要ISP防火墙后的客户端能和防火墙外的RMI/IIOP的应用端口进行连接的话，就要改变ISP的安全策略，让客户端能够连接除了80以外的其他端口。可是当运行RMI/IIOP的应用的服务器为了安全也在防火墙之后的DMZ中的话，那这个连接就更加复杂了，要跨越两个防火墙。
而WebServices由于使用的是HTTP协议，传递的是纯文本的XML数据，因此拥有穿透防火墙的良好性能。
基于异构平台的应用
XML语言本身就是跨平台、跨语言的数据表示方法，在加上通用的HTTP等协议，使得WebServices天生就适用于基于异构平台的应用。如果你的客户端包含了各种不同的平台，例如，你希望你的服务即可以被JAVA程序所调用，又可以由VB和COM程序所调用。你有两种选择：一种是为不同的平台提供相应的API，还要为不同的语言提供API；如果提供WebServices，所有平台和语言都可以调用了！
需要强安全特性的应用
很多人都认为，安全性是WebServices的弱项。其实不然，经过不断的完善和各种新的协议的出台，WebServices完全可以用于安全性很强的应用环境下。并且，由于WebServices使用HTTP协议进行传输，所以可以和容易就使用已经很成熟的基于HTTP的各种安全技术。
EAI（企业应用集成）
这是目前WebServices应用最看好的方向之一。大多数企业内部都有着各种各样的应用系统，它们是在不同的领导在任期间，由不同的软件开发商开发，因此运行在不同的平台和系统上，系统的开发语言也各不相同。由于现代企业信息自动化要求的提高，各个系统之间的互动和相互通讯便提到日程上。因此，保护原有投资，重用遗留系统是当前很多中大型企业的重要任务。
由于遗留系统的运行平台是异构环境，因此企业应用集成的代价一般来说是很高的。但如果使用WebServices作为应用集成的手段，将会大大降低集成的消耗。WebServices与平台和语言无关的特性，以及各种平台和环境下的开发工具都是企业应用集成的利器。
另外，在开发新的应用系统的时候，仍然需要考虑和其他系统的集成，需要考虑调用其他系统的功能，和被其他系统所调用。使用WebServices作为系统与外部交流的接口，能够使新的系统和别的系统之间保持松耦合的关系，保持较高的可扩展性。
行业内部B2B应用
行业内部的应用是WebServices的另外一个方向。因为在一个行业中，商业业务是很相似的，因此在行业内部很容易形成服务的标准，使所有的业内企业共同遵守；但怎样实现服务和使用什么样的系统，决定权在于各个企业自己。例如，电信运营商之间的结算服务，银行之间的转帐服务等都可以形成行业标准，以WSDL的形式公布出来。各个企业之间可以选择不同的平台进行服务的实现。
提高WebServices的性能
要想提高WebServices应用的性能，需要对整个系统做全盘的考虑。一般来说，有以下几点需要注意：
WebServices的颗粒度
选择WebServices的颗粒度是提高WebServices应用的性能的主要手段。因为WebServices使用的传输协议为HTTP或SMTP等，这些协议都是面向无状态的连接协议，每一个请求都要建立一个新的连接。因此WebServices的调用不能象数据库JDBC（ODBC）接口一样可以进行精细而复杂的方法调用（例如，先获得Connection，再获得结果集，然后一行一行获取结果）。WebServices比较适用于大颗粒度的应用，在一个调用中便获得所有的信息（比如说银行之间的转帐，在一次调用中就将包括金额和认证等所有的信息都传输过去）。
谨慎使用XML接口
系统之间的接口可以使用XML，这样可以增加系统的灵活性；但不要使用XML作为系统内部的接口，因为这不会带来任何好处，尽量使用二进制作为系统内部的接口，避免不必要的XML文档的解析和效验；在处理XML的时候，尽快将XML转换成内部对象，XML的传递只会增加系统的开销。
最大可能性使用CACHE
当有些信息是只读的，或者在一段时间内保持不变，就可以使用CACHE。无论是客户端的CACHE还是服务器端的CACHE，都能大大提高系统的性能
总结
一旦WebServices得到更加广泛的应用，使得各种服务可以动态查找和定位，这样就提供了不同设备之间各种各样的信息交互方式，将会大大改变商业运做的模式和信息交流的风格。
你可以使用别人已经成熟的功能来使自己提供更好的服务，例如google，它的搜索引擎可以通过WebServices来访问。这就意味着在你的系统中可以方便的嵌入使用google的强大搜索功能，而不论你的系统是运行在什么平台上，使google的搜索引擎成为你系统的一部分，（请参考http://www.google.com/apis/）。站在别人的肩膀上，毕竟要看得远些！
面对WebServices，你现在可以不行动，但你一定要准备好！
