j2ee|php5|web|web服务|程序|访问处理 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 的主流扩展。