易栈网-膘叔

其实，不知道从几年前起，我就不再碰SOAP了，虽然在自己的项目里也悄悄的实现了一个soap。但那是我偷懒，其实我是将我最常用的一些工具封装了一个类，但是其他人需要调用，于是乎我利用soap，直接将这个类发布了，也就相当于实现了soap的一些最常用的方法。果然是个偷懒的好技巧。

提起这个，是最近有一些朋友来问我soap的相关问题，当初我对soap的使用也就是最多在header里做了一个验证。本来phptext.cn（小猪的网站）上有介绍的这篇文章，但后来他的网站好象崩过一次，数据就没有了。在此，我再介绍 一些文章，以前其实也都介绍过：
1、http://rdc.taobao.com/blog/qa/?p=6023
2、http://www.laruence.com/2010/03/26/1365.html
第一篇是淘宝qa团队，教你怎么使用soapUI进行soap接口测试，第二篇是风雪之隅写的关于soap怎么使用soapHeader之类的文章

当然在我以前的博客里也记录过一些创建soap的文章，比如这个：关于SOAP的几篇文章 ，也可以了解一下。
说实话，现在我真的忘了soap了。

PHP操作soap我总觉得是一件非常痛苦的事情，但没有办法，现在很多功能都是基于WebService的，比如那个amazon的，但其实很多公司都也还是提供了restful之类的接口，使得PHP与其他系统的数据交换比较方便。但让人痛苦的，有时候，你PHP不得不充当soapServer，这时候，怎么做呢？zendstudio可以根据你的函数和类，帮你生成wsdl，但大多数情况下，你没有直接生成的手段，怎么办？官方的soapServer功能也太少了一点。你是否还准备用nuSoap来充当server呢？

搜集了一些资料，用来方便的协助你生成soap接口。如果只是自己的内部调用，可以尝试用phprpc或者它的升级版hprose进行尝试。

1、利用NuSOAP发布wsdl。这是PHP5之前的做法了，因为在PHP5之后，直接有soap库支持，如何发布wsdl，请看：http://hi.baidu.com/arlon/blog/item/d8267d1e6ca4adf01ad576cc.html，然而这个网址打开是白屏的，内容可以稍看这里：

2、利用PHP5自带的soapServer，在手册上，关于如何创建，写了很多例子，就象：

反正，我是觉得很痛苦，不过所幸现在的IDE都支持了直接发布wsdl文件，netbeans可以，zendstudio也可以。所以，也就方便了开发

3、利用开源组件，比如：webservice helper，http://www.jool.nl/new/1,webservice_helper.html，虽然它也是其于soapServer，但是集成的一些代码可以让你少走很多弯路。

比如，它默认就自带了一个contactManager的发布，具体的一些配置，可以看config.php，当然你也可以参考它的一些类，也充实你自己的类库（本来官网有教程的，可能是因为时间太久远了，该教程已经跳到ipublisher的教程上去了）

4、利用框架实现webService。在这里，估计又有很多分支了，比如zend framework，比如xxx和xxxx等，我由于最近在用yii，所以就看了yii的一个小小的实现

介绍页在这里：http://www.yiiframework.com/doc/guide/1.0/zh_cn/topics.webservice

看它的实现是非常简单，在Controller里增加一个转换wsdl的Action，然后，在要提供的方法上面用phpdoc来进行注释。定义传入参数的数据类型等

• str/string: 对应 xsd:string;
• int/integer: 对应 xsd:int;
• float/double: 对应 xsd:float;
• bool/boolean: 对应 xsd:boolean;
• date: 对应 xsd:date;
• time: 对应 xsd:time;
• datetime: 对应 xsd:dateTime;
• array: 对应 xsd:string;
• object: 对应 xsd:struct;
• mixed: 对应 xsd:anyType.

不过我也确实没有过多的细看，没仔细看它对于AUTH验证支持怎么样（第三点里介绍的工具是有验证的，而且就设在config.php里，非常方便）

好了，我就针对现在的soap server的建立，介绍了四种方法，事实上，我到现在为止是一种都没有用过，nusoap也就用过客户端，那也是几年前的事情了，soapClient也是，在构建soapHeader的时候也走过很多弯路。第三步介绍的工具，我也只是下载了看看源码，第四步我是看了看手册。只是先集中一下，以后总会用到而已。
虽然说，PHPRPC和hprose 在andot他们介绍来说，开发速度和处理上，都有较为明显的提高，但如果想做一个公用的web service，那还是用大家都能接受的方法吧。
如果是自己的项目，那可能就会用phprpc或者hprose来了。hprose测试版用过，感觉还是不错的。phprpc，我也做了一个sae平台的移植版，目前也能够正常的使用。。在这里也有个简单的测试：http://nsblog.sinaapp.com/。有兴趣的朋友也可以去看看的。

1.6版本的zf终于将SOAP放进来了，同时也增加了DOJO的支持。不过我没有想通。为什么那么多的JS框架，最终会选择了DOJO。

这些不是我能够想得通的。还是看看到底更新了什么再说吧。

An overview of new features:

• Dojo Integration
  • JSON-RPC
  • Dojo Data packing
  • Dojo View Helper
  • Dijit integration with Zend_Form & Zend_View
  • Dojo Library Distribution
• SOAP
  • SOAP Server
  • SOAP Client
  • Autodiscovery
  • WSDL access
  • WSDL Generation
• Preview of Tooling Project in Laboratory (see /laboratory folder)
  • Command Line Interface
  • Project Asset Management
• Unit Testing Harness for Controllers
• Lucene 2.3 Index File Format Support
• Zend_Session save handler for Database Tables
• Paginator Component
• Text/Figlet Support
• ReCaptcha Service
• Zend_Config_Xml Attribute Support
• Character Set Option for DB Adapters
• Zend File Transfer Component
• New Media View Helpers (Flash, Quicktime, Object, and Page)
• Support in Zend_Translate for INI File Format

This obviously marks a very important step towards a high-quality, highly tested 1.6 GA release. Thanks to everyone who has contributed to this release in any way: with patches/check ins, documentation/translations, and bug reports.

But our work is not yet over! Let's do our best to bring this release to the breaking point to find areas we can improve the release for General Availability. Based on your feedback we will determine in the next few weeks whether we require additional release candidates, so please provide feedback on our issue tracker (http://framework.zend.com/issues) as soon as you can and ask any questions/post your experiences on the appropriate mailing list.

Again, the Zend Framework community does NOT recommend this release for production use. We do, however, recommend evaluating new features in this release with existing and new applications.

Enjoy 1.6RC1, and see you on the issue tracker, wiki, and mailing lists!

————END————

不知道：Zend File Transfer Component，这个会给我们带来什么样的惊喜？大文件传输还是其他的？下载源码研究一下，哈哈

比较REST和SOAP的“风格”

REST依赖一套简单的“动词”，把所有的复杂性都转移到了指定资源的“名词”中。与此不同，SOAP却有一套相当复杂的XML格式化命令和数据传输选项。

在Web服务发展的初期，XML格式化消息的第一个主要用途是，应用于XML-RPC协议，其中RPC代表远程过程调用。在XML远程过程调用(XML-RPC)中，客户端发送一条特定消息，该消息中必须包括名称、运行服务的程序以及输入参数。相反， REST风格的请求却不关心正在运行的程序是什么，它仅仅请求命名资源。

XML-RPC只能使用有限的数据类型种类和一些简单的数据结构。人们认为这个协议还不够强大，于是就出现了SOAP——其最初的定义是简单对象访问协议。之后，大家逐渐意识到SOAP其实并不简单，而且也不需要必须使用面向对象语言，所以，现在人们只是沿用SOAP这个名称而已。

XML-RPC只有简单的数据类型集，取而代之，SOAP是通过利用XML Schema的不断发展来定义数据类型的。同时，SOAP也能够利用XML 命名空间，这是XML-RPC所不需要的。如此一来，SOAP消息的开头部分就可以是任何类型的XML命名空间声明，其代价是在系统之间增加了更多的复杂性和不兼容性。

另外，非常重要一点是，REST是需要请求HTTP的，与其相比，SOAP更具优势，SOAP消息可以由所有能够处理Unicode文本的传输方式来传送，很可惜，这一点通常不被人们所认可。事实是，由于HTTP穿透防火墙的便捷性，以及开发商们对Web非常熟悉，因此，人们还在继续强调着HTTP传输。

随着计算机行业的觉醒，人们发现了基于XML的Web服务的商业潜力，于是，各家公司开始不断地发掘想法、观点、论据以及标准化尝试。W3C曾经设法以“Web服务活动”的名义来组织成果展，其中也包括实际做出SOAP的XML协议工作组(XML Protocol Working Group)。与Web服务有关的标准化成果——从某种程度上说与SOAP相关或者依赖于SOAP——的数量已经倍增了到了令人惊讶的程度。

最初，SOAP是作为XML-RPC的扩展而发展起来的，它主要强调的是，通过从WSDL文件中所获得的方法和变量名来进行远程过程调用。现在，通过不断进步，人们发现了更多的使用SOAP的方式，而不仅仅是采用“文件”方式——基本上是使用一个SOAP信封来传送XML格式化文件。无论如何，要掌握SOAP，了解WSDL所扮演的角色是最根本的。

Web服务描述语言或WSDL
为了创建一个用于描述Web服务的XML格式化文件，Web服务描述语言(WSDL)标准提供了足够多的细节，以便能够构建出客户端代码，从而访问服务或者服务器端代码以提供服务。一个服务的WSDL文件将会为你提供以下几个方面的内容：

用于访问服务的地址信息
用于传送信息的传输协议(例如，通道数)
用于所有可使用功能的名称和接口使用方法
在所有的请求和响应中所使用的数据类型
2001年3月，W3C推出了WSDL 1.1版本用于讨论，这并不是最终确定的规范。W3C Web服务描述工作组目前正在开发该规范的2.0版本，基本上已经到了尾声。虽然，WSDL通常是用于特定的SOAP服务，但是，从理论说，它是完全可以用于特定的REST风格的GET或者POST操作的。

能够根据服务的WSDL描述来自动创建客户端和服务器端代码，支持这一功能的开发环境目前使用得很广泛，以便能够适用于Web服务器和Web服务客户端的不同程序设计语言。如果你使用Google搜索“SOAP IDE”的话，大概会出现上百万条相关信息。也有这样的工具，根据Java或C#对象来生成相应的WSDL和代码。自动生成代码也许能够使你的开发效率更高，但是离优化却是越来越远。

安全与SOAP

如果企业使用SOAP来传送有价值的信息的话，那么，安全就是最重要的问题。由OASIS组织发起，计算机行业的领导者们已经联合开发了一套标准，称为WS-Security。这个标准对基本的SOAP通信做出了改善，以便能够处理以下几个问题：

消息机密性——由于拦截HTTP消息的方式非常多，因此，在请求和响应过程中，必须能够对所有重要信息加密。很幸运，现在的加密技术非常先进，我们能够对消息内容进行加密，以保证消息不被修改。

客户和服务身份——必须能够核实SOAP请求来源的身份。

结论

在开发人员的意识里，对于Web服务的开发而言，REST和SOAP风格各有千秋。SOAP拥有更为详尽的标准化成果和开源工具。除此之外，现在，有许多集成开发环境能够在现有代码的基础上，依据接口方法自动生成SOAP。如果你需要使用WSDL来发布你的服务，或者你需要一些安全功能如消息签名和加密，那么，SOAP能够确保消息的安全性。另一方面，如果你希望使用简单接口来公布一些信息，而不需要繁琐的处理过程，那么，REST也许是最佳选择。

——END——
原文来自：http://www.diybl.com/course/3_program/java/javajs/2007918/71772.html
仅作参考

　我有这样一个推断，在计算机世界中，但凡那些让开发人员记住的重要概念，都有一个很酷的名称首字母缩写，否则的话，开发人员很快就会将其抛之脑后。比如Ajax、SOAP以及REST就证明了这一点。

REST能够在计算机领域被广泛采用，它走的道路是不同寻常的。这个术语是由Roy Fielding创造的。Fielding毕业于Irvine市加利福尼亚大学，在他的博士学位论文中第一次提出了REST这个概念。在Web方面，我们必须承认Fielding是非常精通的，他曾经帮助创建HTTP 1.0规范，该规范从1996年开始就为Web提供基本准则。他在Web标准方面非常有经验，这为他的这篇博士论文奠定了坚实的基础。

Fielding指出，使用且符合代表性状态传输(REST)设计约束的 Web 上部署的组件，可以充分利用 Web 的有用特性，万维网(World Wide Web)才能够达到最佳的工作效果。可以这样理解REST——当一个浏览器得到并且显示构成HTML页面的各个元素时，它正在获取资源的当前状态的表现形式。在Fielding的博士论文中，他列举了REST风格的设计约束，并且解释了为什么这些约束能够充分利用Web 的有用特性，使其达到最佳状态，以及这些约束的关键所在。同时，在论文中，他也包含了一些关于REST和某些目前的Web风格之间 “不符合”的讨论，以及这些Web风格是如何导致设计无法利用Web特性的。

Fielding认为，对于使用HTTP承载应用程序协议穿越防火墙，XML-RPC 和SOAP所采用的方式是“从根本上被误导的概念。”它们所采用的方式违背了设立防火墙的概念，结果是，防火墙厂商为了保护系统需要侦察出所承载的协议。由于大多数SOAP应用程序使用HTTP都是为了穿越防火墙，因此，你可以发现REST与SOAP之间的冲突是从哪里开始的。Fielding认为，如果你打算使用HTTP的话，就应该与充分利用HTTP本身的含义。

REST风格强调，通过有限的操作或者是“动词”以及一个组件之间的标准接口，也就是HTTP协议提供的借口，来提升客户与服务之间的交互。通过为每一个资源分配其自己的URL，来实现灵活性，REST可以调用包含上百个URI的资源类型的客户，其中的关键是REST能够给你无限多的“名词”。REST使用HTTP的动词——简单的良定义操作集:POST, GET, PUT,DELETE进行请求和响应，从而避免了歧义。举个例子，GET只能够简单地返回资源的表现形式，而不能够创建任何其他的内容。

在Web发展的初期，由于人们都在试验通过收集各种不同来源的元素，从而把Web应用程序融合在一起，有大量这种Web服务的不成熟探索的例子——从HTTP页面中解析信息，用于页面创建者没有计划到的用途。这种“屏幕抓取”的Web类比表明，REST风格的方法是先于那些更加复杂的Web服务而出现的。

REST是一种风格而不是一个标准

你可能会把软件的架构风格当作对上层设计模式的抽象。然而，根据Fielding所说，设计模式的堆砌并不等同于架构风格，因为模式是非常接近于特定问题的。

由于REST是超文本系统的一种风格，而不是Web服务的，因此，本文的标题“REST与SOAP之比较”就有些让人误解。然而，很多软件设计人员会将其混淆，他们在考虑如何创建Web服务时，会得出这样的结论：SOAP过于复杂，而简单的类似于REST的设计却更加适合。

REST与RPC风格之比较

远程过程调用的架构，是应用在基于XML-RPC或者 RPC风格的SOAP的Web服务中的，它却有着完全不同的风格。客户端发出命令，以使服务做出特定的操作。换句话说，RPC有动词的倾向。

REST强调资源(名词)有统一的接口以此来对它们寻址，而RPC强调过程(动词)有统一的接口来激发它们。一个基于RPC的架构，动词数量是没有限制的。REST说，我们使用四个动词——非常熟悉，HTTP标准的GET、POST、PUT以及DELETE——来进行请求和响应，REST使用资源寻址来处理其可变性。

一个简单的REST举例

假设我们希望一个Web服务暴露一部分目录，从这个目录中，用户将能够得到一些描述、图片、安装指令等等。为了得到数字“n1996-01”的描述，用户需要格式化一个GET请求，类似于下面的这个URL：

http://company.com/catalog/description/n1996-01

在处理这个请求时，“/catalog”将映射到一个服务中，之后，通过该服务对“description/n1996-01”进行解释，从而定位资源。在创建响应时，服务需要使用内容类型(Content-Type)的头文件来指定返回格式。在这种情况下，假定返回格式是HTML或者XML，客户端能够使用它来控制页面的布局。如果要得到图片，那么这个请求将对“/catalog/picture/n1996-01”进行寻址，返回的响应将是图片内容类型(Content-Type)。

REST的商业应用

最近几年，大多数Web商业企业开始对REST非常感兴趣。Google Data API(目前还在测试版本)专门使用REST规则来提供简单的协议。对服务的HTTP GET请求的响应结果是，采用Atom或者是RSS联合格式的XML数据。Google也使用Atom以及POST、PUT和DELETE操作来完成公共协议。eBay服务提供通过使用不同语言工具来访问服务，这些工具包括文档/文字风格的SOAP以及REST风格。

那么，对于XML-RPC和SOAP所具有的RPC风格而言，REST风格是否是一个具有竞争力的替代者呢?当然，我决不这样认为，在下一篇文章中，我将尽量向大家展现SOAP所向无敌的领域。
———END——
原文来自：http://www.diybl.com/course/3_program/java/javajs/2007918/71777.html
仅作参考