j2ee|php5|web|web服务|程序|访问
很多 Web 开发人员喜欢 PHP 的丰富功能和简单易用，但有时候他们需要访问 J2EE 应用程序服务器中已有的业务逻辑。本文将通过一些例子说明如何通过 PHP 5 中新的 SOAP 扩展使用 Web 服务来访问 J2EE 应用程序，而不必脱离 PHP 环境，也不用学习新的编程模型。
PHP、Web 服务和 SOAP 简介
本文将介绍如何从 PHP 脚本中访问企业应用程序。您可能是一位 PHP 程序员，需要为部门 Web 应用程序编写代码，以便访问公司总部以 Web 服务方式提供的服务。您或许是一位有经验的 J2EE 开发人员，希望多了解一点 PHP 及其应用。本文中的例子是一个运行在 IBM WebSphere? 应用程序服务器上的 Enterprise JavaBean（EJB），但本文并没有讨论 Web 服务的部署。它的主要目标是介绍如何从 PHP 中使用 Web 服务，这一点可以应用于各种 Web 服务实现。
什么是 PHP？
PHP：Hypertext Preprocessor（超文本预处理器，PHP）是一种流行的服务器端脚本语言，用于创建动态 Web 内容。PHP 解释器为主流平台提供了源代码或者编译好的二进制文件，这些平台包括大多数 Linux? 版本、Windows?、Mac OS X 和 iSeries?。
确实有数百万台 Web 服务器正在运行 PHP，其中大部分使用的是 PHP 4。2004 年 7 月推出的 PHP 5 正在逐渐被采用。PHP 5 改进了对象模型，底层的内存管理也从多线程和性能的角度重新作了设计。但是需要注意少数无法向后兼容的修改，PHP 手册中对这些进行了记录。
什么是 Web 服务技术？
Web 服务指的是自成体系的、模块化的应用程序，客户机和服务在这种应用程序中是松耦合的。关于 Web 服务的详细信息，对于本文来说，您只需要了解其中的主要技术：
SOAP（简单对象访问协议）定义了客户机与服务器之间传递的消息。消息采用 XML 格式。SOAP 独立于平台、编程语言、网络和传输层。本文将讨论 HTTP 上的 SOAP。
WSDL（Web 服务描述语言）是用于描述 Web 服务的基于 XML 的语言，描述内容包括服务的位置、格式、操作、参数和数据类型。
UDDI（统一描述、发现和集成）是用 API 和 UDDI Registry 实现来提供在网络上存储和检索 Web 服务信息的方法。
本文包括 SOAP 消息和 WSDL 文档的一些例子，但没有提供 UDDI 的例子。
XMethods 网站是一个有用的 Web 服务工具，在那里可以找到在各种服务器平台上实现的可公开使用的 Web 服务的列表。可以使用本文中的例子很方便地访问从 XMethods 中选择的服务。
SOAP 和 PHP
有多种产品允许在 PHP 4 脚本中使用 SOAP，最常见的产品是 PEAR::SOAP 和 NuSOAP。在写这篇文章的时候，这些产品在与 PHP 5 的兼容方面还存在问题，估计很快就会升级。
PHP 5 中新增了内置的 SOAP 扩展，我们称之为 ext/soap。它是作为 PHP 的一部分提供的，因此不需要下载、安装和管理单独的包。这是第一个用 C 而不是 PHP 为 PHP 编写的 SOAP 实现，因此作者声称它的速度要快得多。
因为新的扩展是 PHP 的完整组成部分之一，相关文档包含在 PHP 手册的 Function Reference 部分。SOAP 参考是以一个重要的免责声明开始的：
警告：该扩展是试验性的（EXPERIMENTAL）。本扩展的行为，包括关于本扩展的函数名和其他内容，在以后的 PHP 版本中随时可能改变，不另行通知。使用该扩展的风险自负。
警告看起来有点让人担心，但实际上这个扩展似乎得到了很好的支持。和任何新代码一样，该扩展也存在缺陷，但是报告的问题通常很快就能得到修正。在 PHP 站点上可以看到缺陷列表。我们估计，在将来的 PHP 版本中，该扩展将从试验性功能转为主流功能。
安装 PHP SOAP 扩展
应该在 Web 服务器上安装并运行 PHP 5。我们的实验采用 PHP 5.0.2，这是现在最新的版本，修正了 PHP 5 初始版本中的很多错误。上面已经提到，ext/soap 是作为 PHP 5 的一部分提供的，因此不需要单独下载，但是您可能需要对它做一些修改来启用它。需要做哪些修改则取决于您是下载源代码，自己编译 PHP，还是直接下载二进制文件。
如果下载的是 PHP 源代码，并在自己的平台上编译，那么可能需要重新进行构建，因为在默认情况下没有启用 ext/soap。重复以前的构建过程，并在 configure 命令中添加 --enable-soap 选项。
如果下载的是预编译平台的二进制文件，ext/soap 可能已经编译但没有加载，因此需要更新 PHP 配置，以便加载 ext/soap。编辑 php.ini 并找到 Dynamic Extensions 部分，在这里增加一行代码来自动加载该扩展。
在 Windows 上，这一代码行是： extension=php_soap.dll
在 UNIX 上是： extension=php_soap.so
如果以前没有加载过任何可选的扩展，可能还要设置 extension_dir 指令，让它指向包含扩展库（其中包括 php_soap）的目录，比如： extension_dir="C:/php/ext/"（在 Windows 上使用正斜杠）
不要将目录信息放到 extension 指令中，需要的话可以使用 extension_dir。
对于 Windows，可以下载其他两个二进制包。Windows 安装程序包不含任何扩展，因此要使用 Windows zip 压缩包，这个压缩包中包含 ext/soap。
注意，ext/soap 依赖于 GNOME xml 库，这个库必须使用 2.5.4 或更高版本。如果版本不够高，可以从 xmlsoft安装 libxml2。
最后，ext/soap 在 php.ini 中有自己的配置部分，在完成配置之后，ext/soap 如下所示：[soap]
; Enables or disables WSDL caching feature.
soap.wsdl_cache_enabled=1
; Sets the directory name where SOAP extension will put cache files.
soap.wsdl_cache_dir="/tmp"
; (time to live) Sets the number of second while cached file will be used
; instead of original one.
soap.wsdl_cache_ttl=86400
这段配置控制了 SOAP 扩展的 WSDL 缓存特性。默认情况下，WSDL 描述文件在 24 小时（86400 秒）内都缓存在 /tmp 目录下。我们迟些时候再讨论这些内容，现在要设置 soap.wsdl_cache_enabled=0，否则，在开发代码时，您会遇到一些莫名其妙的行为。完成开发之后，要记得打开 WSDL 缓存，使代码运行得更快。
为了便于参考，我们将在两种环境中使用 ext/soap：
Linux Centos 3.3（Red Hat EL 3 的免费重建版本）、Apache 2.0.47、PHP 5.0.2，需要升级 libxml2 到 2.6.12。
Windows XP SP1、Apache 2.0.46、PHP 5.0.2 二进制压缩包、libxml2 2.6.11。
这些说明同样适用于其他配置。
Weather Forecast 应用程序
我们要从 PHP 中访问的 Web 服务是一个天气预报应用程序。这是 WebSphere Version 5.1 Application Developer 5.1.1 Web Services Handbook 中开发的示例应用程序。下载示例 Weather Forecast 应用程序，请参阅本文后面的下载部分。这本书设计了几种不同的场景，但我们只考虑一种，在该书中，这种场景称为“自下而上的开发，使用 HTTP 传输和 SOAP 消息从会话 EJB 生成 Web 服务”。在这里，自下而上的意思是说，Web 服务是围绕现有企业应用程序进行包装的。
图 1. 天气预报应用程序 |
图 1 中标出的 Weather Forecast 应用程序的主要组成包括：
预测天气的后台 WEATHER 数据库。天气预报中的信息包括：
风向，八个方位
风速，公里/小时
气温，摄氏度
天气状况：晴、有时阴、阴、雨、暴雨
日期
WeatherPredictor 类用于访问 WEATHER 数据库。如果数据库中没有适用于请求日期的预报，那么 WeatherPredictor 会随机生成天气预测（与实际的天气预报不同），并将它保存到数据库中。
业务逻辑由 WeatherForecastEJB 会话 bean 提供，并公开为 Web 服务，它提供三项操作：
getDayForecast 返回某一天的天气预报。
getForecast 返回某个时期的天气预报。
getTemperatures 返回某个时期的气温预测。
将这个会话 bean 部署为 Web 服务所需的所有元素都是由 WebSphere Studio Application Developer 的 Web 服务向导生成的，并且是作为 ItsoWebService2RouterWeb 项目生成的。路由器 servlet 是连接 SOAP 消息和 EJB 容器的桥梁，需要配置和部署路由器 servlet，通过 URL ItsoWebService2EJBRouterWeb/services/WeatherServiceEJB 来使 Weather 服务可用。WSDL 文档 itso.session.WeatherForecastEJB.wsdl 在 ItsoWebService2EJBRouterWeb/wsdl 目录中。
Java 客户机是这本书中开发的多个 Weather Service 客户机之一。ItsoWebService2EJBClient 项目中的 WeatherClientEJB 是一个简单的 Java servlet，调用 getForecast Web 服务操作。典型的运行结果如下所示：
图 2. Java WeatherClient |
下一步是在 PHP 中建立等价的客户机功能。
阅读本文不需要自己运行这个例子，可以针对从 XMethods 网站选择的服务建立 PHP 客户机。
PHP Weather 客户机
这一节将建立我们自己的 PHP Weather 客户机。这里提供了一些代码片段，建议下载完整的客户机和 WSDL 文件。
用于表示 Weather Service 的 ext/soap 类是 SoapClient。正如我们介绍 Weather Forecast 应用程序时所讨论的，我们知道应用服务器在 http://host:port/ItsoWebServer2RouterWeb/wsdl/itso/session/WeatherForecastEJB.wsdl 中提供了 WSDL。我们使用的是默认端口，并且在作为服务器的计算机上工作，这样就可以通过查找 WSDL 文件创建第一个 SoapClient：
| ＜?php $soapClient = new SoapClient("http://localhost:9080/" . "ItsoWebService2RouterWeb/wsdl/itso/session/WeatherForecastEJB.wsdl"); ?＞ |
注意，因为 ext/soap 是内置的，所以，在引用 SoapClient 之前，不需要任何 include 或 require 语句。
现在已经实例化了客户机，还要联系 Weather 服务，并调用它的 getForecast 操作。在 WSDL 模式下使用 SoapClient 时，ext/soap 有一种很好的特性，即可以直接引用远程操作，就像它是 SoapClient 自身的函数一样。但是在建立输入参数时需要一点技巧。ext/soap 可以提供从 WSDL 中发现的操作和参数的数组：
| $functions = $soapClient-＞__getFunctions(); print_r($functions); $types = $soapClient-＞__getTypes(); print_r($types); |
只需要显示与 getForecast 相关的结果，并重新格式化这些结果，以方便阅读，于是我们看到以下代码：
| getForecastResponse getForecast(getForecast $parameters) struct getForecast { dateTime startDate; int days; } struct getForecastResponse { Weather getForecastReturn; } struct Weather { string condition; dateTime date; string windDirection; int windSpeed; int temperatureCelsius; boolean dbflag; } |
ext/soap 实际上并没有为我们定义 getForecast 类，我们必须创建该操作所需要的输入参数数组：
| $getForecastParam = array('startDate' =＞time(), 'days' =＞ 3); |
然后像 SoapClient 的方法那样调用该操作：
| $forecastResponse = $soapClient-＞getForecast($getForecastParam); |
最后我们得到了返回的 getForecastResponse 对象，它本身是一个 Weather 对象数组，然后在表格中显示结果：
| echo "＜table border=0 cellpadding=5＞"; echo "＜tr＞＜th＞Date＜/th＞＜th＞Condition＜/th＞＜th＞Temperature＜/th＞＜th＞Wind＜/th＞＜/tr＞"; $weatherArray = $forecastResponse-＞getForecastReturn; foreach ($weatherArray as $weather) { echo "＜tr＞", "＜td＞",strftime("%a. %b %d, %Y", strtotime($weather-＞date)),"＜/td＞", "＜td＞$weather-＞condition＜/td＞", "＜td＞$weather-＞temperatureCelsius＜/td＞", "＜td＞$weather-＞windDirection $weather-＞windSpeed＜/td＞", "＜/tr＞"; } echo "＜/table＞"; |
PHP 客户机与 Java 客户机的输出相同，于是我们知道圣诞节期间 San Jose 不会下雪……
图 3. PHP WeatherClient |
观察 SOAP 流
我们成功地与 Weather 服务取得了联系，并显示了结果。但是如果出现错误，得不到预期的结果，该怎么办？ext/soap 可以显示客户机与服务器之间交换的 SOAP 消息，能够帮助我们确定问题所在。
只有使用 trace 选项创建 SoapClient 时，才要使用跟踪功能。我们在 options 数组参数中设置 trace 选项，将该参数传递给 SoapClient 构造函数。我们将构造函数的使用改为：
| $soapClient = new SoapClient("http://localhost:9080/" . "ItsoWebService2RouterWeb/wsdl/itso/session/WeatherForecastEJB.wsdl", array('trace' =＞ 1)); |
并在调用 goForecast 之后调用 trace 方法：
| echo "Request :＜br＞", htmlspecialchars($soapClient-＞__getLastRequest()), "＜br＞"; echo "Response :＜br＞", htmlspecialchars($soapClient-＞__getLastResponse()), "＜br＞"; |
一定要使用 htmlspecialchars 内置函数对 trace 输出进行编码，因为它将 SOAP xml 分界符转换成特殊字符，如
下面是某个请求的 trace 输出：
| ＜?xml version="1.0" encoding="UTF-8"?＞ ＜SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="http://session.itso"＞ ＜SOAP-ENV:Body＞ ＜ns1:getForecast＞ ＜ns1:startDate＞2004-11-30T13:41:59＜/ns1:startDate＞ ＜ns1:days＞0＜/ns1:days＞ ＜/ns1:getForecast＞ ＜/SOAP-ENV:Body＞ ＜/SOAP-ENV:Envelope＞ |
对应的应答是：
| ＜?xml version="1.0" encoding="UTF-8"?＞ ＜soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"＞ ＜soapenv:Body＞ ＜getForecastResponse xmlns="http://session.itso"＞ ＜getForecastReturn xmlns:ns-239399687="http://mapping.itso"＞ ＜ns-239399687:condition＞sunny＜/ns-239399687:condition＞ ＜ns-239399687:date＞2004-11-30T00:00:00.000Z＜/ns-239399687:date＞ ＜ns-239399687:windDirection＞W＜/ns-239399687:windDirection＞ ＜ns-239399687:windSpeed＞18＜/ns-239399687:windSpeed＞ ＜ns-239399687:temperatureCelsius＞6＜/ns-239399687:temperatureCelsius＞ ＜ns-239399687:dbflag＞1＜/ns-239399687:dbflag＞ ＜/getForecastReturn＞ ＜/getForecastResponse＞ ＜/soapenv:Body＞ ＜/soapenv:Envelope＞ |
如果在开启跟踪功能的情况下运行客户机来收集这些输出，那么需要将 days 参数设置为 0，只有这样做，SOAP 应答才会输出较少的行。但是我们遇到了没有预料到的行为。我们本来期望 getForecastResponse 和以前一样是一个 Weather 对象数组，但是它应该只有一个元素，而不是 4 个元素。然而，它被转换成了一个简单的 Weather 对象，我们必须根据这种行为进行编码，就像您在最终的示例 PHP 客户机代码中看到的那样。这与 Java 客户机的行为有所不同，在客户机行为中，getForecast 总是返回 Weather 对象数组，无论服务器响应中有多少个 Weather 对象。SoapClient::_getTypes() 输出并没有为我们理解这种差异提供足够的细节，因此我们要求助于 WSDL 文档来了解完整的接口规范。
解释 WSDL
我们已经成功地调用了 Weather 服务，但是还没有看过它的 WSDL 文档。WSDL 中的细节要比 SoapClient 公开的多。我们如何知道应该在 startDate 参数中放什么呢？我们应该期望从返回的数据中实际得到什么？要回答这些问题，必须更深入地分析 WSDL。
可以从下载部分下载 Weather Forecast 应用程序的 WSDL。如果使用不同的 Web 服务，只需要在浏览器中打开相应的 WSDL 文档即可。
getForecast 操作的 WSDL 是：
| ＜wsdl:operation name="getForecast"＞ ＜wsdl:input message="intf:getForecastRequest" name="getForecastRequest"/＞ ＜wsdl:output message="intf:getForecastResponse" name="getForecastResponse"/＞ ＜/wsdl:operation＞ |
其中的 getForecastRequest 消息被定义为：
| ＜wsdl:message name="getForecastRequest"＞ ＜wsdl:part element="intf:getForecast" name="parameters"/＞ ＜/wsdl:message＞ |
而 getForecast 结构被定义为：
| ＜element name="getForecast"＞ ＜complexType＞ ＜sequence＞ ＜element name="startDate" nillable="true" type="xsd:dateTime"/＞ ＜element name="days" type="xsd:int"/＞ ＜/sequence＞ ＜/complexType＞ ＜/element＞ |
于是我们知道该函数需要两个参数，xsd:dateTime 类型的 startDate 和整数类型的 days。这与我们所了解的 SoapClient::_getTypes 函数完全匹配，但是现在我们还知道 startDate 可以为空（nillable）。毫无疑问，如果我们简化输入参数，那么该函数将如下所示：
$forecastResponse = $soapClient-＞getForecast(array('startDate'=＞Null, 'days'=＞3));
如果明确指定今天的日期，结果会与所指定的完全一致。
如果希望制定其他起始日期怎么办呢？XML Schema将 dateTime 定义成一种基本类型，按照 ISO 8601 标准格式化，比如“2004-12-01T00:00:00”。假设希望了解三天之后的天气预报，可以使用内置函数 strtotime("+3 days") 获得需要的日期，该函数与 time() 函数相同，都返回标准 UNIX 格式的日期时间，即表示从公元纪年开始到现在的秒数的一个整数。我们知道 XML Schema 要求日期采用具有字符串字段的 ISO 8601 格式进行编码，于是在示例客户机中编写了 timeToIso8601 函数，将整数日期转换成 SOAP 编码定义的格式。但我们吃惊地发现，其实并不需要这样做，ext/soap 非常聪明地将整数日期转化成了需要的字符串字段格式。无论传递的是整数还是预格式化的字符串，都没有关系，最终传送的 SOAP 消息都是一样的。
响应中的日期又如何呢？在回程中，ext/soap 从 SOAP 响应获得了 dateTime 字段，但是没有做任何格式转换。我们希望它返回一个整数，以表示从公元纪年到现在的秒数，但实际上得到的是按照 ISO 8601 格式化的字符串。于是我们使用 strtotime 函数将其转化成整数，然后使用 strftime 格式化该整数，以便于表示。
Weather Service 按日期提供预报，但它忽略了 dateTime 编码中的时间成分。所以我们没有考虑这方面的调整，如果从运行在不同时区内的服务中请求天气预报，那么可能必须这样做。如果希望进一步了解时区转换，请参阅参考资料中给出的描述 ISO 8601 标准的文章。
现在再回到响应格式上来。上一节中曾经提到 getForecast 返回数据的不一致性。WSDL 描述告诉我们 getForecast 返回一个 getForecastResponse 对象，getForecastResponse 可以包含无限多个称为 Weather 的复杂类型的列表：
| ＜element name="getForecastResponse"＞ ＜complexType＞ ＜sequence＞ ＜element maxOccurs="unbounded" name="getForecastReturn" type="tns2:Weather"/＞ ＜/sequence＞ ＜/complexType＞ ＜/element＞ ＜complexType name="Weather"＞ ＜sequence＞ ＜element name="condition" nillable="true" type="xsd:string"/＞ ＜element name="date" nillable="true" type="xsd:dateTime"/＞ ＜element name="windDirection" nillable="true" type="xsd:string"/＞ ＜element name="windSpeed" type="xsd:int"/＞ ＜element name="temperatureCelsius" type="xsd:int"/＞ ＜element name="dbflag" type="xsd:boolean"/＞ ＜/sequence＞ ＜/complexType＞ |
WSDL 不允许出现单元素数组这种特例。不幸的是，当响应只包含一个 Weather 对象时，ext/soap 没有考虑 WSDL 中应用于 getForecastResponse 的 ＜sequence＞ 标签，因为这种行为在客户机代码中造成了不必要的复杂性。
最后，WSDL 文档还告诉 SOAP 客户机可以从网络中的哪个地方找到该服务：
| ＜wsdl:service name="WeatherForecastEJBService"＞ ＜wsdl:port binding="intf:WeatherForecastEJBSoapBinding" name="WeatherForecastEJB"＞ ＜wsdlsoap:address location= "http://localhost:9080/ItsoWebService2RouterWeb/services/WeatherForecastEJB"/＞ ＜/wsdl:port＞ ＜/wsdl:service＞ |
处理 SOAP 错误
如果运行客户机时出现错误怎么办？与其他语言（如 Java）一样，PHP 5 新增加了一种异常机制。ext/soap 使用这种新的机制，以 SoapFault 对象的形式返回错误。比方说，可以用下面这种形式将代码包装起来： try {
... some SOAP operation
} catch (SoapFault $soapFault) {
echo $soapFault;
}
注意，与 Java 有所不同，PHP 语言的 try - catch 块不能包含 finally 子句。
SoapFault 可以在本地生成。比方说，假设输错了 getForecast 的 startDate 参数。客户机的输出就会变成：SoapFault exception: [SOAP-ENV:Client]
SOAP-ERROR: Encoding: object hasn't 'startDate' property in WeatherClientEJB.php:32
Stack trace: #0 WeatherClientEJB.php(32): SoapClient-＞getForecast('getForecast', Array)
#1 WeatherClientEJB.php(73): displayForecast(Array)
#2 {main}
注意，其中没有 trace 输出，因为并没有发送请求。SOAP_ENV:Client 是 SOAP 规范中为 Faulty body 元素 Faultcode 字段定义的值之一。
这个 SoapFault 是在 ext/soap 内部发现错误时生成的，它没有发送 SOAP 消息。但是 SoapFaults 也可以报告服务器上发现的错误。比如，假设修改代码，将 startDate 参数的值设成“badDateString”。这是一个非法的 ISO 8601 字符串，但是 ext/soap 没有检查提供的格式，仅仅把消息发送到服务器，而服务器拒绝该请求：Request :
＜?xml version="1.0" encoding="UTF-8"?＞
＜SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ns1="http://session.itso"＞
＜SOAP-ENV:Body＞
＜ns1:getForecast＞
＜ns1:startDate＞badDateString＜/ns1:startDate＞
＜ns1:days＞2＜/ns1:days＞
＜/ns1:getForecast＞
＜/SOAP-ENV:Body＞
＜/SOAP-ENV:Envelope＞
Response :
＜?xml version="1.0" encoding="UTF-8"?＞
＜soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"＞
＜soapenv:Body＞
＜Fault xmlns="http://schemas.xmlsoap.org/soap/envelope/"＞
＜faultcode xmlns=""＞Server.generalException＜/faultcode＞
＜faultstring xmlns=""＞
＜![CDATA[java.lang.NumberFormatException:
WSWS3046E: Error: Invalid date/time: badDateString]]＞
＜/faultstring＞
＜detail xmlns=""/＞
＜/Fault＞
＜/soapenv:Body＞
＜/soapenv:Envelope＞
SoapFault exception: [Server.generalException] java.lang.NumberFormatException:
WSWS3046E: Error: Invalid date/time: badDateString in WeatherClientEJB.php:32
Stack trace: #0 WeatherClientEJB.php(32): SoapClient-＞getForecast('getForecast', Array)
#1 WeatherClientEJB.php(73): displayForecast(Array)
#2 {main}
这一次，SOAP 请求传递给了服务器，但是因为日期格式无效而被拒绝。WeatherForecastEJB 实现抛出一个 java.lang.NumberFormatException，该异常在 SOAP 应答中作为 Faulty body 元素返回，然后作为一个 SoapFault 异常报告给客户机。
保护 Web 服务
我们考察了三种安全方法，以及如何在 PHP 中使用它们：
基本 HTTP 身份验证
如果 HTTP 服务器要求客户机进行身份验证，就会请求用户输入 id 和口令并在应答中增加 Authentication Required HTTP 头文件。在进行后续操作之前，客户机必须响应包含可接受 Authorization HTTP 头文件的请求。
请求 HTTP 身份验证的通常是 Web 服务器，而不是 Web 服务提供者。Authentication Required HTTP 头文件被传递给浏览器，浏览器弹出对话框请求用户 id 和口令，然后将用户的应答作为 HTTP Authorization 头文件发送给 Web 服务器。在 PHP 脚本中很容易实现这一点，可以使用 header() 函数发送需要的 HTTP 头文件字段。例如：if (!isset($_SERVER['PHP_AUTH_USER'])) {
header('WWW-Authenticate: Basic realm="Weather"');
header("HTTP/1.0 401 Unauthorized");
}
echo "Welcome " . $_SERVER['PHP_AUTH_USER'];
PHP 手册中的使用 PHP 进行 HTTP 身份验证 一章详细介绍了这个过程。
您可能遇到这样一些 Web 服务，这些服务的提供者要求 PHP Web 服务客户机使用 HTTP 进行验证身份。ext/soap 提供了一种简单的发送 HTTP Authorization 请求头文件的方法，使用传递给 SoapClient 构造函数的 options 数组：$soapClient = new SoapClient("http://localhost:9080/" .
"ItsoWebService2RouterWeb/wsdl/itso/session/WeatherForecastEJB.wsdl",
array('login' =＞ "userid",
'password' =＞ "password"));
但是，人们认为 HTTP 基本身份验证不是一种安全的用户验证方法（除非结合使用其他外部安全系统，如 SSL），因为用户名和口令是以明文形式在网络上传递的。 HTTP Digest 验证通过加密口令改进了这种方法，但是并不是所有的浏览器都支持这种改进。而且，PHP 的 header() 函数只支持基本身份验证。
SSL（安全套接字层）
一种更加安全的协议是 HTTPS（HTTP over SSL），它使用 SSL 加密 HTTP 消息。SSL 在传输层上工作，不了解 HTTP 或 SOAP 协议。因此，它不能只加密消息中的敏感成分，而必须加密整个消息。HTTPS 可以在浏览器与 Web 服务器之间，或者 Web 服务器与 Web 服务提供者之间使用。
如果编译并启用了 OpenSSL，那么 PHP 还可以支持 HTTPS。如何在 PHP 脚本中使用 SSL，请参阅 PHP 手册中的 OpenSSL 一章。
身份验证怎么样呢？SSL 可以发送安全证书，对方可以接受或拒绝该安全证书。如果要求客户机验证 Web 服务提供者（如电子商务应用程序），那么这种方法很有效。但是如果 Web 服务本身提供敏感信息的访问，那么 Web 服务提供者还是需要验证每个客户。基于证书的身份验证并不合适，因为客户可能很多，而且是动态的，事先为每个客户分发适当的证书不太现实。
WS-Security
WS-Security 标准为 Web 服务安全提供了不同的方法。目前我们所考察的安全控制都在 SOAP 协议之外。但是 WS-Security 是通过在 SOAP 消息中增加安全头文件来实现安全控制的。比如，对于 WS-Security 基本身份验证（与 HTTP 基本身份验证不同），下面的标签将出现在 SOAP 头文件中：＜wsse:UsernameToken＞
＜wsse:Username＞userid＜/wsse:Username＞
＜wsse:Password＞password＜/wsse:Password＞
＜/wsse:UsernameToken＞
这只是一个简单的例子，不过，完整的安全扩展集是非常完善的，不仅包括身份验证，还包括完整性、保密性，等等。
目前 ext/soap 中还没有为 WS-Security 提供很好的支持。因此，如果要在 PHP 中发送和接收 WS-Security 头文件，那么必须深入到更底层的接口，显式地创建 SOAP 头文件。到目前为止，示例中使用的都是 ext/soap 的 WSDL 模式。但是，还有一种非 WSDL 模式，可以用它来控制整个 SOAP 消息。当然也必须在代码中做大量的工作。可以使用 SoapHeader、SoapParam 和 SoapVar 类创建消息，然后用 SoapClient::__call 发送 SOAP 请求和接收响应。如果没有任何内置支持，那么在 PHP 中编写 Web 服务安全扩展（或者其他高级规范如 WS-Transactions）将是一项相当艰巨的任务，我们不打算在本文中进行这方面的尝试。
结束语
使用 PHP SOAP 扩展并不难。无论服务器是如何实现的，只需要几行代码，就可以开发出访问简单 Web 服务的 PHP 脚本。与往常一样，PHP 在易用性上表现非常出色。本文主要讨论了如何使用 SoapClient 类访问异构网络上的现有 Web 服务，但是通过使用 ext/soap，利用 SoapServer 类也可以部署 Web 服务，同样非常直观。
如果要处理更复杂的交互，ext/soap 当前的版本不能给我们提供很多帮助。从 XML 模式到 PHP 的映射有时候不够清晰，只能通过试验或者研究源代码来验证。如果希望使用更先进的 Web 服务协议，惟一的选择就是深入研究非 WSDL 模式，用自己的脚本创建 SOAP 头文件，但这样做非常乏味而且容易出错。
Web 服务的一项重要主张是不同平台、操作系统和编程语言的互操作性。独立的 WS-I (Web Services Interoperability) Organization 提供了一个测试包，以验证对其 Basic Profile 的适应性，我们希望看到 ext/soap 能够达到某种程度，表现出它能够适应。我们也希望 ext/soap 继续发展，成为 PHP 的主流扩展。
