Web Services的基本原理
Web Services 是通过一系列标准和协议来保证程序之间的动态连接。其中最基本的协议包括：SOAP, WSDL, UDDI
SOAP: 是“Simple Object Access Protocol”的缩写，SOAP是消息传递的协议，它规定了Web Services之间是怎样传递信息的。简单的说，SOAP规定了：
1. 传递信息的格式为XML。这就使Web Services能够在任何平台上，用任何语言进行实现。
2. 远程对象方法调用的格式。规定了怎样表示被调用对象以及调用的方法名称和参数类型等。
3. 参数类型和XML格式之间的映射。这是因为，被调用的方法有时候需要传递一个复杂的参数，例如，一个Person对象。怎样用XML来表示一个对象参数，也是SOAP所定义的范围。
4. 异常处理以及其他的相关信息.
WSDL:是“Web Services Description Language”的缩写.意如其名,WSDL是Web Services的定义语言。当你实现了某种服务的时候(如,股票查询服务),为了让别的程序调用,你必须告诉大家你的服务的接口.例如,服务名称，服务所在的机器名称，监听端口号，传递参数的类型,个数和顺序,返回结果的类型等等.这样别的应用程序才能调用你的服务。WSDL协议就是规定了有关Web Services描述的标准。
UDDI: 是Universal Description, Discovery, and Integration的缩写。简单说，UDDI用于集中存放和查找WSDL描述文件，起着目录服务器的作用。
实现一个Web Services，使其能够接受和响应SOAP消息（现在有很多工具都可以帮助实现）。
撰写一个WSDL文件用于描述此Web Services。（现在有很多工具可以自动生成WSDL文件）。
将此WSDL发布到UDDI上。
其他的应用程序（客户端）从UDDI上搜索到你的WSDL。
根据你的WSDL，客户端可以编写程序（现在有很多工具可以自动生成调用程序）调用你的Web Services。
Web Services的缺点
由于是基于XML的应用，Web Services与生俱来地在拥有XML带来的一切优势的同时，不可避免地继承了XML所带来的一些限制。
Web Services通常需要大量的CPU资源。因为XML数据要经过多步处理才能被系统使用。首先是效验（validate），检查它的格式是否符合XML的规范，以及根据应用程序定义（DTD或Schema）检查是否符合语义上的规范；然后还要进行解析（parse），从XML文档分解出单个的元素；最后还要转换成应用程序所需要的二进制表达（例如，把“12” 转换成整型12的二进制表示）。
Web Services还意味着占用较多的内存资源。在进行XML解析的时候，会产生大量的临时内存对象。特别是在处理DOM对象的时候。这些大量的临时对象对于象JAVA这类自动回收内存的语言和系统其实是一种负担，大量的临时对象将会使系统每隔一段时间就会进行内存回收，从而降低系统的性能。当然，现在有的Web Services的产品（如axis）采用了SAX技术，大大减少了内存的占用量。详细信息请参考：（http://xml.apache.org/axis/index.html）。
网络资源的消耗也是Web Services应用的一些限制。因为基于XML数据的传递通常数据量要比二进制的协议（如RMI/IIOP）要大的多。这种额外的消耗在网络资源比较紧张或网络传输比较频繁的应用中会产生一定的影响。
除了XML带来的限制，Web Services本身也具有一些缺点：
到目前为止，Web Services还可以说是一种无状态（stateless）的服务。
所谓stateless就意味着不保存客户端服务调用者的任何信息。这是由Web Services的本质所决定的。Web Services在本质上是要为应用程序之间提供数据通讯的标准，为企业应用之间动态地提供大颗粒度的服务，所以Web Services并不适合于非常精细的基于会话的方法调用以及复杂的事务（transaction）处理之中。
也许有人会对我这点提出异议！因为，现在有很多Web Services的产品（如WASD），不但可以保存session的信息，使服务成为有状态（stateful）的服务，而且还实现了remote interface，可以在Web Services的会话中传递远程对象的句柄，让客户端可以操纵递远程对象（详细信息请参考：http://www.systinet.com ）。原理上说，这并不难实现，因为在XML数据中，可以互相传送任何数据，包括sessionID和transactionID，有了这些ID，从技术角度上说，实现有状态（stateful）的服务和事务处理并不复杂。但是，这样功能缺少标准的支持，当前版本的WSDL还无法表示这些复杂的服务。在企业内部，你可以任意使用这些特殊的功能，可以自己定义会话状态的交互协议，因为服务者和服务调用者之间的通讯都在你的控制之中；然而要将这些服务发布到Internet上，其他的应用程序是无法根据标准去识别这些特殊功能。
数据绑定也存在一些不足。
因为所有的数据传递都用XML格式，因此，需要在二进制数据和XML数据之间有个转换。但是，并不是所有的二进制数据都能方便地用XML来表示，并不是所有的JAVA对象都能被XML所表示。因此，经常在转换过程中会出现语义丢失的情况。
技术要求高，学习曲线较长。
每一个Web Services的产品，都有丰富的工具，能够根据Web Services的定义（如WSDL文件）方便地生成客户端的程序；能够将一般的服务程序，很容易就包装成Web Services服务。因此，各个Web Services的产品都声称自己的平台容易使用，根本不需要了解XML，也不需要了解什么WSDL，UDDI，SOAP就能使用发布Web Services。特别是一个朋友告诉我，他在什么都不了解的情况下，用.NET花了15分钟就发布了一个Web Services！
千万不要醉心于这种简便，这对于简单的Demo也许是对的，可是对于真正意义上严肃的应用，一定要了解Web Services的各个方面，设计整体结构和解决方案，还要根据具体的应用调整性能。所有这些都需要对Web Services知识的全面掌握。
Web Services 是通过一系列标准和协议来保证程序之间的动态连接。其中最基本的协议包括：SOAP, WSDL, UDDI
SOAP: 是“Simple Object Access Protocol”的缩写，SOAP是消息传递的协议，它规定了Web Services之间是怎样传递信息的。简单的说，SOAP规定了：
1. 传递信息的格式为XML。这就使Web Services能够在任何平台上，用任何语言进行实现。
2. 远程对象方法调用的格式。规定了怎样表示被调用对象以及调用的方法名称和参数类型等。
3. 参数类型和XML格式之间的映射。这是因为，被调用的方法有时候需要传递一个复杂的参数，例如，一个Person对象。怎样用XML来表示一个对象参数，也是SOAP所定义的范围。
4. 异常处理以及其他的相关信息.
WSDL:是“Web Services Description Language”的缩写.意如其名,WSDL是Web Services的定义语言。当你实现了某种服务的时候(如,股票查询服务),为了让别的程序调用,你必须告诉大家你的服务的接口.例如,服务名称，服务所在的机器名称，监听端口号，传递参数的类型,个数和顺序,返回结果的类型等等.这样别的应用程序才能调用你的服务。WSDL协议就是规定了有关Web Services描述的标准。
UDDI: 是Universal Description, Discovery, and Integration的缩写。简单说，UDDI用于集中存放和查找WSDL描述文件，起着目录服务器的作用。
实现一个Web Services，使其能够接受和响应SOAP消息（现在有很多工具都可以帮助实现）。
撰写一个WSDL文件用于描述此Web Services。（现在有很多工具可以自动生成WSDL文件）。
将此WSDL发布到UDDI上。
其他的应用程序（客户端）从UDDI上搜索到你的WSDL。
根据你的WSDL，客户端可以编写程序（现在有很多工具可以自动生成调用程序）调用你的Web Services。
Web Services的缺点
由于是基于XML的应用，Web Services与生俱来地在拥有XML带来的一切优势的同时，不可避免地继承了XML所带来的一些限制。
Web Services通常需要大量的CPU资源。因为XML数据要经过多步处理才能被系统使用。首先是效验（validate），检查它的格式是否符合XML的规范，以及根据应用程序定义（DTD或Schema）检查是否符合语义上的规范；然后还要进行解析（parse），从XML文档分解出单个的元素；最后还要转换成应用程序所需要的二进制表达（例如，把“12” 转换成整型12的二进制表示）。
Web Services还意味着占用较多的内存资源。在进行XML解析的时候，会产生大量的临时内存对象。特别是在处理DOM对象的时候。这些大量的临时对象对于象JAVA这类自动回收内存的语言和系统其实是一种负担，大量的临时对象将会使系统每隔一段时间就会进行内存回收，从而降低系统的性能。当然，现在有的Web Services的产品（如axis）采用了SAX技术，大大减少了内存的占用量。详细信息请参考：（http://xml.apache.org/axis/index.html）。
网络资源的消耗也是Web Services应用的一些限制。因为基于XML数据的传递通常数据量要比二进制的协议（如RMI/IIOP）要大的多。这种额外的消耗在网络资源比较紧张或网络传输比较频繁的应用中会产生一定的影响。
除了XML带来的限制，Web Services本身也具有一些缺点：
到目前为止，Web Services还可以说是一种无状态（stateless）的服务。
所谓stateless就意味着不保存客户端服务调用者的任何信息。这是由Web Services的本质所决定的。Web Services在本质上是要为应用程序之间提供数据通讯的标准，为企业应用之间动态地提供大颗粒度的服务，所以Web Services并不适合于非常精细的基于会话的方法调用以及复杂的事务（transaction）处理之中。
也许有人会对我这点提出异议！因为，现在有很多Web Services的产品（如WASD），不但可以保存session的信息，使服务成为有状态（stateful）的服务，而且还实现了remote interface，可以在Web Services的会话中传递远程对象的句柄，让客户端可以操纵递远程对象（详细信息请参考：http://www.systinet.com ）。原理上说，这并不难实现，因为在XML数据中，可以互相传送任何数据，包括sessionID和transactionID，有了这些ID，从技术角度上说，实现有状态（stateful）的服务和事务处理并不复杂。但是，这样功能缺少标准的支持，当前版本的WSDL还无法表示这些复杂的服务。在企业内部，你可以任意使用这些特殊的功能，可以自己定义会话状态的交互协议，因为服务者和服务调用者之间的通讯都在你的控制之中；然而要将这些服务发布到Internet上，其他的应用程序是无法根据标准去识别这些特殊功能。
数据绑定也存在一些不足。
因为所有的数据传递都用XML格式，因此，需要在二进制数据和XML数据之间有个转换。但是，并不是所有的二进制数据都能方便地用XML来表示，并不是所有的JAVA对象都能被XML所表示。因此，经常在转换过程中会出现语义丢失的情况。
技术要求高，学习曲线较长。
每一个Web Services的产品，都有丰富的工具，能够根据Web Services的定义（如WSDL文件）方便地生成客户端的程序；能够将一般的服务程序，很容易就包装成Web Services服务。因此，各个Web Services的产品都声称自己的平台容易使用，根本不需要了解XML，也不需要了解什么WSDL，UDDI，SOAP就能使用发布Web Services。特别是一个朋友告诉我，他在什么都不了解的情况下，用.NET花了15分钟就发布了一个Web Services！
千万不要醉心于这种简便，这对于简单的Demo也许是对的，可是对于真正意义上严肃的应用，一定要了解Web Services的各个方面，设计整体结构和解决方案，还要根据具体的应用调整性能。所有这些都需要对Web Services知识的全面掌握。
