|
Web Service故障处理 |
|||||
|
|
|||||
|
2001-10-17· ·Matt Powell and Scott Seely··yesky |
|||||
|
简介 Web Service 的故障处理会是一件很困难的事情，因为很多方面都会发生问题。这篇文章描述了你可能会遇到的各种问题，并说明应如何来处理它们。特别的，我们将讨论如下问题： · 回顾SOAP请求 · 深入服务器端Visual Basic代码 · 深入服务器端Visual C++代码 · 跟踪SSL问题 · 深入Favorites Service中的问题 回顾SOAP请求 当开发一个简单对象访问协议（SOAP）客户端应用程序或服务器终端时，有一大堆东西可能出错。例如，SOAP请求可能不符合Web Service 描述语言（WSDL）规范，或SOAPAction项是错的。为了调试这些问题，你需要一个工具来查看SOAP请求和消息交换。在Microsoft? Windows?平台上，你有两个很好的工具。如果你只是想要调试SOAP请求，你应该下载Microsoft SOAP Toolkit 2.0，得到SOAP跟踪工具（MsSoapT.exe）。当你想要查看整个HTTP信息，请去http://www.pocketsoap.com/下载tcpTrace。这两个工具是互补的。你应该怎样查看SOAP请求呢？ 这两个工具都是通过截取并发送请求来查看SOAP请求的。要截取请求信息，你必须让你的客户端使用跟踪工具正在监听的端口。假定你在客户端用一个WSDL文件来建立调用，你必须将该文件装载到你的机器上，并编辑服务部分。在一台机器上，我们有一个Web Service ，它的服务部分如下：
|
现在，我们来讨论怎样使用这些工具来调试问题。你可能经常遇到的问题是一个终端可能消失或者迁移了。利用一些良好的错误处理机制，你可以会发现问题，但是怎样确定是什么来往消息能够确认问题是由不存在的Web Service 造成的呢？对于这个问题，tcpTrace.exe能很好的解决。图四中显示了这种情况--你从服务器处得到响应，表示它对于你请求的终端不能处理。
|
|
当你开发SOAP客户端应用程序时，你可能发现产生了很多SOAP错误。可能的原因包含从传送坏数据到服务器端问题。有时候直接查看XML文件比将错误信息提取出来写进日志文件更容易。对于你产生的每一个错误，你会想办法让客户端去处理。但为了发现错误，使用跟踪工具是很有帮助的。查看原始XML文件，请使用MSSoapT.exe。为了显示它是怎样工作的，我们以一个SOAP调用为例，它将两个数字相加，并当地一个参数小于10时，强行返回一个SOAP错误。以下是5和20相加的SOAP请求：
|
＜?xml version="1.0" encoding="UTF-8" standalone="no" ?＞ |
如果一切正常而且终端没有被破坏，我们希望返回25。但是，终端被破坏了，得到以下结果：
|
＜?xml version="1.0" encoding="UTF-8" standalone="no" ?＞ |
上面的错误提供了很多信息，可以帮助你发现问题的所在。从错误中可见，WSDLOperation组件发现AddNumbers方法失败。它还表明是客户端发生问题，而且问题是：第一个数必须大于10。图五中显示了MSSoapT.exe中这个错误是怎样的。
|
|
这些工具还有很多用途。你可以用它们来分析SOAP请求和响应。有时候，Web Service只有一个客户端。如果你有客户端的源代码，你可以修改终端，让它可以通过跟踪工具。这样，你可以利用Microsoft SOAP Toolkit的底层API来反过来设计WSDL文件或构建客户端程序。
其他跟踪方法
MSSoapT.exe和tcpTrace.exe是查看SOAP请求甚至HTTP请求的优秀工具，但有的情况下，这些工具收效甚微。比如，如果你尝试发送SOAP请求给服务器，但是它的主机名不能解析，或者不能接受TCP连接，你就无法利用前面所述的两种跟踪工具了。另一种情况可能发生在你试图通过安全套接层（SSL）来进行SOAP通讯。MSSoapT.exe和tcpTrace.exe在SSL下是没有什么作用。所以，在这些情况下，可以使用以下方法：
· Microsoft Network Monitor，它是监控网络数据包的一个管理工具。如果你安装了Windows 2000 Server中带的版本，你可以看到本机发送和接收的数据包。System Management Server中带的是完整版，它能够显示物理网络中所有的数据包。Network Monitor可以用来查看所有试图连接SOAP服务器的信息流。例如，当试图解析要连接的服务器主机名时，你可以看到DNS请求和响应。当与服务器建立连接时，你也可以看到TCP握手数据包。这可以告诉你TCP连接是否正常建立，还是服务器过早的重置了你的连接。你还可以看到数据包中的数据，这样就可以跟踪HTTP报文头和SOAP信封了，当然这在前面所述的两个工具中查看会更方便。Network Monitor不会显示发送到本机的数据流。而且，它虽然能够显示通过SSL连接的数据，但是那是加密的，所以查看其中的数据包内容是没有意义的。
· 通过自定义的ISAPI ReadRawData and SendRawData Filter可以查看你的Web Service 器所有发送和接收的数据。这包括发向你的Web Service 的SOAP请求和响应。MSSoapT.exe 和tcpTrace.exe已经实现了通过ISAPI filter实现的许多功能，但有一个重要的例外：ISAPI filter可以查看SSL中传输的数据，因为它能工作在SSL加密/解密层之上。因此，如果你想要解决SSL中的问题，你可以看到其中HTTP和SOAP等数据。由于ISAPI filter处于较高的网络层次，你将看不到那些连接建立等Network Monitor提供的细节。想要知道如何编写ISAPI filter，请看开发ISAPI Filters一文。
深入服务器端Visual Basic代码
有时候，你需要调试你自己的代码以确定产生错误结果的原因。当调试Microsoft Visual Basic?应用程序时，你必须按照KB：PRB: Error Occurs When You Debut a COM+ Component Under the Visual Basic IDE with an ASP Client中的步骤来处理。这篇文章只适用于Visual Basic集成开发环境下调试COM+组件。文章中第一条也适用于调试SOAP对象。为了节省你查看KB文章的时间，以下是其中一些相关内容的摘要：
1. 在DCOM中创建VB ASP Debugging项：
a. 打开写字板或其他文本编辑器，输入以下语句，这是大小写敏感的。
|
REGEDIT4 |
b.将文件保存为Vbaspdbg.reg。
c.定位到保存该文件的文件夹，双击该文件（它会自动在Windows注册表中注册）。
2． 在DCOM配置中，将Everyone账号的许可加入Visual Basic ASP debugging中。
a.打开DCOMCNFG。在Start菜单中，按Run，在对话框中输入dcomcnfg。
b. 在Distributed COM Configuration Properties页面中，按Application标签，从列表中选择VB ASP Debugging，然后按Properties。
c. 在VB ASP Debugging Properties属性单中，按Securities标签，然后选中Use custom access permissions。按Edit。
d. 在Registry Value Permissions窗口中，按Add，然后加入Everyone账号，允许Allow Access。
e. 按OK，然后按Apply并退出Distributed COM Configuaration Properties页面。