2001 年 6 月 21 日发布的 SP2 2.0 版,可从http://msdn.microsoft.com/library/default.asp?url=/downloads/list/websrv.asp 站点获得此版本。
使用 MSSOAPT 在服务器端跟踪:
修改 WSDL 中 soap:address 元素的位置属性,将客户端定向到 8080 端口。例如,如果 WSDL 包含 <http://MyServer/VDir/Service.wsdl>,将其更改为 <http://MyServer:8080/VDir/Service.wsdl>。
在服务器端运行 MSSOAPT。
选择文件、新建、格式化跟踪(如果不需要看到 HTTP 标头)或文件、新的未格式化跟踪(如果希望看到诸如 ContentType 和 SoapAction 这样的 HTTP 标头)。
单击 Trace Setup 对话框上的 OK 以接受默认值。
现在,向 WSDL 中指定地址提出的所有请求/指定地址返回的所有响应都会在跟踪中出现。
使用 MSSOAPT 在客户端跟踪:
生成服务的 WSDL 文档的本地副本。
修改 WSDL 中 soap:address 元素的位置属性,将客户端定向到 localhost:8080,并对当前主机和端口进行说明。例如,如果 WSDL 含有 ,将其更改为 ,并对 "MyServer" 进行说明。
在客户端运行 MSSOAPT。
选择文件、新建、格式化跟踪(如果不需要看到 HTTP 标头)或文件、新的未格式化跟踪(如果希望看到 HTTP 标头)。
在 Trace Setup 对话框,输入步骤 2 中说明的主机和端口作为目标主机和目标端口值,然后单击 OK。
现在,来往于客户端的任何请求/响应都会在跟踪中出现。
假设服务器设置为需要 SSL,您只需将 WSDL 文件中的 URL 更改(或者,如果您正在使用低级别接口,更改 Soap Connector URL)为以 HTTPS 开头,而不以 HTTP 开头。不必在客户端设置 UseSSL 属性。如果这样做不起作用,最常见的原因就是服务器证书已经过期,或是服务器需要客户证书。注意,我们经常听说“使用 HTTP URL 运行成功,但使用 HTTPS URL 运行失败”。如果虚拟根目录设置为要求 SSL,那么使用 HTTP 就不会运行,因此,本语句意味着服务器没有设置为要求 SSL。
其他一些常见问题:
请确保证书有效且有可信的根目录—打开此证书(双击它)并检查是否有警告。
请确保您的服务器正确配置了 ssl—服务器端证书是有效的,有可信的根目录,而且它的根目录安装在 LOCAL_MACHINE 存储区。
不能将 localhost 用作主机名—URL 中的主机名应该与服务器端证书中的主机名相匹配。
如果您的机器上没有 mmc 工具,要查看证书,可以使用 IE—步骤为 Tools/Options/Content/Certificates/。
如果将服务器 vdir 设置为需要客户证书—可以通过 Microsoft Internet Explorer 访问 vdir 来检查可使用哪些客户证书。IE 会显示一个客户证书列表,这些客户证书具有服务器端信任的根目录。如果您有 IE 5.5,在安全性设置中禁用 "Miscellaneous\Don't prompt for client certificates selection when no certificates or only one certificate exists" 标志。
在 MSDN 文章中,可以找到对这些问题及其他问题的准确解释,用 Microsoft SOAP Toolkit 2.0 构建安全的 Web 服务。
查找到 "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\6.0\Setup\Microsoft Visual Basic\ProductDir" 注册表项时,安装 SMO Generator 的选项应该是可见的。请使用 regedit 查看 该项是否存在。
在 2.1 版之前,Apache 要求所有 Soap 参数的 xsi:type 属性。而且,Soap Toolkit 通常不发送 Soap 消息中的 xsi:type。如果部署说明符中定义了类型,Apache 2.1 版就不再需要 xsi.type 属性。但是,Apache 服务还不使用 WSDL,因此,必须为 Soap Toolkit 客户端创建一个 WSDL 文件与 Apache 服务器进行对话。已经使用 Apache 2.2 成功测试了 RTM Soap Toolkit。
另一个有时起作用的窍门是在生成 WSDL 文件后对其进行编辑,将 Apache 出现问题的类型更改为 "xsd:anyType"。这会使该工具包将参数作为变量,因此它会包含 Apache 正在查找的类型信息。
WSDL 是描述 Soap 消息和 Web 服务的标准的、结构化方法。Soap Toolkit 依赖于 WSDL 创建并解释 Soap 消息,因此,对于任何 Soap Toolkit 2.0 客户端或服务器,均要求 WSDL 文件。如果希望 Soap Toolkit 2.0 客户端与不提供 WSDL 的 Soap 服务器通讯,必须创建一个 WSDL 文件,该文件描述 Soap 服务期望的消息。完成此任务最简单的方法是:在 Microsoft Visual Basic 中创建一个与服务器所希望相匹配的虚拟接口,并使用 VB dll 上的 WSDLGen 创建 WSDL 文件。也可以手工创建 WSDL 文件。如果您希望支持非 WSDL 的 Soap 客户端与 Soap Toolkit 2.0 服务对话,仅需要使用 WSDL 文件来描述 Soap 消息的外观,并将此翻译成客户端用来创建 Soap 消息的任何机制。
W3C 已经确认了 WSDL 1.1 规范的提交。现在,可以在 http://www.w3.org/TR/wsdl 找到该规范。
使用 MSXML 的 http 接口,将 WSDL 文件加载到 WSDL 读取器中的 DOM。运行 ASP 页中的 MSXML HTTP 堆栈要求使用 ServerHTTPRequest 选项。为此,请遵循如下操作:
将 "ServerHTTPRequest" ClientProperty 设置为 true。示例:SoapClient.ClientProperty("ServerHTTPRequest") = True
需要运行 proxycfg.exe (请参阅 知识库文章 Q289481)。
另一个选择是使用本地 filepath 来指定 WSDL: mssoapinit ("C:\wsldfiles\MyProject.wsdl")
另一个选择是使用本地 filepath 来指定 WSDL: mssoapinit ("C:\wsldfiles\MyProject.wsdl")
WSML 被确切地描述为 Soap Toolkit 配置文件。它包含将 WSDL 文件描述的 SOAP 消息映射到 COM 接口所要求的信息。这包含诸如 ProgID 和 DispID 这样的标准 COM'ism。WSML 决不会是一个标准,因为它只对 Soap Toolkit 有意义。
虽然两者之间存在一些重叠,但高级别接口在传统 RPC 类型应用程序中处于最佳状态。同时,SMO 在执行面向消息的应用程序时状态较好。如果希望使用 Soap 来交换 XML 文档,SMO 是最佳选择。如果希望使用 Soap 执行远程主机上的操作,高级别接口可能是更好的选择。SMO 提供了一个接口,创建复杂 XML 文档时比高级别接口更易于使用。
我的回答是几乎总要使用。ISAPI 使用起来比 ASP 页更加快捷方便,因此,除非所需工作 ISAPI 无法完成或正在使用 SMO,否则我会推荐使用 ISAPI。
安装 ISAPI 时,它会自行注册以处理 ".WSDL" 文件。Soap Toolkit 2.0 的安装通过创建 “App Mapping” 将 ".WSDL" 扩展与机器(服务器)级别的 soapisap.dll 相关联来完成此任务。安装 SoapToolkit 2.0 之前,如果 “App Mapping” 在比机器级别低的节点发生变化(例如,在 “Web Site” 或 “Virtual Directory” 级),那么,新添加的 ".WSDL" 映射不会继承机器级别设置。在这种情况下,可以用 IIS MMC Admin 工具在较低级别节点手工输入 “App Mapping”。
例如,下面是使用 IIS MMC Admin 工具在 IIS 5.0 上手工添加 “Default Web Site” 的 “App Mapping” 的步骤(在进行这些步骤前要确保您有本地 admin 权限):
在 “Default Web Site” 的属性下选择 Home Directory 选项卡。
在 Home Directory 选项卡上,单击 Configuration 按钮并选择 App Mappings 选项卡。
如果 .wsdl 扩展不存在,则单击 Add 按钮为 .wsdl 添加新的扩展项。
输入 soapisap.dll 的路径。
注 由于 IIS Admin 工具的 UI 中的错误,不能添加带有空格的路径名。 要解决这个问题,输入 soapisap.dll 的短文件路径名(示例: ?C:\PROGRA~1\COMMON~1\MSSOAP\BINARIES\SOAPISAP.DLL}。 在 "Extension" 文本框中输入 .wsdl。 如果您正在使用 Microsoft Windows 2000,为 "Verbs" 选择 Limit to 并添加: GET、POST、HEAD。 如果您正在使用 Windows NT_ 4 ,保持 Exclude 文本框为空。 最后,应选中 “Script Engine”,且不应选中 "Check that files exist"。 现在,单击 OK 以输入新项。
注 虽然以上步骤会在 “Default Web Site” 级别添加 “App Mapping”,但在诸如 “Virtual Directory” 这样的较低级别,可遵循同样的步骤。
Soap Toolkit 中支持简单类型的一维数组、复杂类型的数组和多维数组。后面的服务软件包包括对数组处理的几项改进和修复。
细节部分是具有命名空间资格的,使用下列命名空间:
http://schemas.microsoft.com/soap-toolkit/faultdetail/error/
所有 Soap Toolkit 特定信息进入下列主干:
<soap:fault....> <detail> <mserror:errorInfo xmlns:mserror="http://schemas.microsoft.com/soap- toolkit/faultdetail/error/"> <mserror:returnCode></mserror:returnCode> <mserror:serverErrorInfo> <mserror:description></mserror:description> <mserror:source></mserror:source> <mserror:helpFile></mserror:helpFile> <mserror:helpContext></mserror:helpContext> </mserror:serverErrorInfo> <mserror:callStack> <mserror:callElement> <mserror:component></mserror:component> <mserror:description></mserror:description> <mserror:returnCode></mserror:returnCode> </mserror:callElement> </mserror:callStack> </mserror:errorInfo> </detail>
因此,假设已经汇编了丰富的错误信息,我们就会以 mserror:errorInfo 元素开始创建扩展的 errorinfo 节。在第一个子级内,returnCode 进入客户端 Error 对象的 HR。
如果提供服务器端 errorinfo 对象本身的内容产生失败(诸如 servercomponent 被调用),那么(并且只是那么,因此并不总是需要下面步骤),我们创建 mserror:serverErrorInfo 节。此节中的所有字段都是可选的—虽然,当 helpfile 持续时,您总是另外得到 helpContext—而且,只有当服务器在字段中有信息时,字段才持续。如果这些字段存在,就进入客户端的 Error 对象。
在试图执行下列操作时,出现 “library not registerd” 错误:Server.CreateObject("MSSOAP.SoapServer")。
产生这一错误的原因可以追溯到 typelib 注册表项,它没有给出 "Everyone" 分组读访问权限。这很可能是优先安装 Crystal Reports 8.0 的结果(请参阅 http://support.microsoft.com/support/kb/articles/Q266/6/21.ASP)。
您可能会遇到 SOAP 应用程序中三个版本的 XSD 命名空间:1999、2000/10 和 2001。只要消息中的命名空间与 WSDL 文件中的命名空间相匹配,Soap Toolkit 2.0 就会接受具有任何一种版本命名空间的消息。WSDLGen 已经修改,因此您能够在三种命名空间中指定希望使用哪一种。如果不需要使用 1999 或 2000 版本与较低版本 Soap 实现兼容,建议使用默认的 2001 版本。注意,几种数据类型名称在 2001 版规范中已经更改。详细信息,请参阅文档。
这确实是 FAQ。正确的答案是使用 .MSM 文件,可以从下载 toolkit 的页上下载该文件。如果您仔细将所有 DLL 置于正确的目录并正确注册,或许就能进行您自己的安装;然而,将 .MSM 合并入您的安装程序是实现这一目的最安全的方法,也是唯一受支持的方法。
如果 SOAP 方法使用自定义类型匹配器,您可能需要使用客户端的 WSML 文件。WSML 文件为 SoapClient 指定了自定义匹配器的 progid 以获知它的位置。如果您的 WSML 文件指定了服务器组件的 progid(如同使用为服务器生成的 WSML 时一样),您可能想删除服务器组件信息,因此,SoapClient 不会试图加载服务器组件。
虽然在一些实例中这可能有效,但这并不是一个经过测试或受到支持的配置。建议编写基于 DLL 的 .EXE 包装来处理这种情况。
WSDLReader 不公开调度接口,因此它不能在脚本中使用。
Windows NT 4.0 不支持 CHS:gb2312 或 AR:iso8859-6 编码。
Serializer.writeXML 无需转义即可写出 XML。文档提到它使用 CDATA 节,但实际不是这样。
切记,Soap Toolkit 应用程序是 Web 应用程序。所有 Web 服务器都有许多保护措施确保用户不能访问不应访问的内容。这意味着访问被拒绝经常是服务器应用程序的默认状态。请检查以下几项内容:
确保应用程序所运行的用户(IWAM_... 或 IUSR_... 等等)具有对 WSDL 和 WSML 文件的读访问权限—检查 ACL 文件及 IIS 配置。
确保 Web 应用程序用户拥有 dll 的读和执行权限,dll 实现 Soap 服务。
确保您的虚拟根目录设置为允许 .wsdl 扩展的读和执行权限。
在 VB 调试程序中运行服务器对象时,这种情况经常发生。匿名用户没有激活 VB 调试程序中对象的足够权限。
这不是一个详尽的列表,但应该能够为您提供一些初始的建议。
错误 | 十进制 | 十六进制 |
---|---|---|
AMBIGUOUS | 5000 | 1388 |
BAD_REQUEST | 5050 | 13BA |
ACCESS_DENIED | 5051 | 13BB |
FORBIDDEN | 5052 | 13BC |
NOT_FOUND | 5053 | 13BD |
BAD_METHOD | 5054 | 13BE |
REQ_TIMEOUT | 5055 | 13BF |
CONFLICT | 5056 | 13C0 |
GONE | 5057 | 13C1 |
TOO_LARGE | 5058 | 13C2 |
ADDRESS | 5059 | 13C3 |
SERVER_ERROR | 5100 | 13EC |
SRV_NOT_SUPPORTED | 5101 | 13ED |
BAD_GATEWAY | 5102 | 13EE |
NOT_AVAILABLE | 5103 | 13EF |
SRV_TIMEOUT | 5104 | 13F0 |
VER_NOT_SUPPORTED | 5105 | 13F1 |
BAD_CONTENT | 5200 | 1450 |
CONNECTION_ERROR | 5300 | 1464 |
BAD_CERTIFICATE_NAME | 5301 | 1465 |
HTTP_UNSPECIFIED | 5400 | 1518 |
HTTP_SENDRECV | 5401 | 1519 |
HTTP_BAD_REQUEST | 5402 | 151A |
HTTP_BAD_RESPONSE | 5403 | 151B |
HTTP_BAD_URL | 5404 | 151C |
HTTP_DNS_FAILURE | 5405 | 151D |
HTTP_CONNECT_FAILED | 5406 | 151E |
HTTP_SEND_FAILED | 5407 | 151F |
HTTP_RECV_FAILED | 5408 | 1520 |
HTTP_HOST_NOT_FOUND | 5409 | 1521 |
HTTP_OVERLOADED | 5410 | 1522 |
HTTP_FORCED_ABORT | 5411 | 1523 |
HTTP_NO_RESPONSE | 5412 | 1524 |
HTTP_BAD_CHUNK | 5413 | 1525 |
HTTP_PARSE_RESPONSE | 5414 | 1526 |
HTTP_TIMEOUT | 5415 | 1527 |
HTTP_CANNOT_USE_PROXY | 5416 | 1528 |
HTTP_BAD_CERTIFICATE | 5417 | 1529 |
HTTP_BAD_CERT_AUTHORITY | 5418 | 152A |
HTTP_SSL_ERROR | 5419 | 152B |
WSDL_MUSTUNDERSTAND | 7100 | 1BBC |
发生这个问题的一个常见原因就是可能需要更改两个不同的 URL。SoapClient.mssoapinit 调用包含了 WSDL 文件(以及可选择的 WSML 文件)的位置。如果移动服务时移动了这些文件,必须更改参数与之匹配。在 “location” 属性中的 WSDL 文件中,指定了 Soap 服务的实际 URL—这一点常常被遗忘。
有一个基于脚本的 Soap 实现,不需要安装 Soap Toolkit。
Soap 本质上是一个 Web 应用程序,因此,所有应用于 Web 应用程序的安全性基本原理也适用于 Soap。这篇 FAQ 已经涵盖了一些最常见的疑问,但安全性是一个非常广泛的问题,这里不能完全涵盖。下面是一篇由我们的测试负责人撰写的有关 Soap 安全性的文章:http://msdn.microsoft.com/library/default.asp?url=/library/en-us/Dnsoap/html/Soapsecurity.asp?frame=true.我所了解的用于设置 Web 安全性的最佳资源是 Michael Howard 的专著:Designing Secure Web-Based Application for Microsoft Windows 2000,Microsoft Press;ISBN:0735609950。
ASPToday 也有几篇不错的关于安全性的文章,其中有:Securing Windows 2000 IIS 5.0applications.
关于客户证书的一个常见问题是在一个证书中有多个名称—友好名称和主题名称。主题名称是在 Soap Client 中指定客户证书时使用的名称。要查找主题名称,使用 IE 定位到 IE/Tools/Internet Options/Content,并单击证书按钮。要使用的名称位于 "Issued To" 列。这个名称常常是一个 X.500 名称。如果这样,CN 是所要求名称的一部分。有关详细信息,请参阅 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/Dnsoap/html/Soapsecurity.asp?frame=true 上的 Soap 安全性文章。
可从 http://support.microsoft.com/directory/overview.asp?sd=gn&fr=0 站点获得 Microsoft 支持选项概览。您可以从以下站点选择电话支持或基于 Web 的支持:http://support.microsoft.com/directory/directory.asp?sd=gn。
Windows 95 缺少一些 Soap Toolkit 代码使用的系统调用,因此,目前不能支持。
低级别对象在处理边界间(例如,中等或高等保护,COM+ server 应用程序和调试程序)使用时,关于它们的一些封送处理问题会产生其他问题。目前,只使用低级别组件 inproc。这个问题将在服务软件包版本中解决。
请查阅:http://msdn.microsoft.com/workshop/networking/wininet/reference/constants/statuscodes.asp。
从 soapsdk 新闻组不能得到满意的解答。可将问题发送到:iewctrls@microsoft.com。
Soap Toolkit 3.0 应该在 2001 年秋末发布其第一个测试版。
添加的注册表设置使您能够关闭 ISAPI 服务器中的 Nagling 延迟。从特殊连接上的 ISAPI 接收到每个缓冲区后,Nagling 通过添加延迟防止 TCP 发送小的数据包,以免另一个缓冲区很快就到达,因而两个缓冲区能够结合起来。这个延迟是 200 ms,因此,大多数 Soap 操作都有额外的 200 ms 通过 Nagling 延迟添加到它们的执行时间。这使得一些愚蠢的基准使调用服务器的单一客户端在循环中报告比在关闭 Nagling 时更糟糕的结果。显然,即使客户端和服务器执行时没有花费时间,单一客户端线程也不能每秒将五个以上的事务发送到服务器。在数以千计的客户并行访问服务器这种更现实的基准中,Nagling 常常通过减少发送的小数据包数量来提高性能。通常,如果基准给出的结果比预料的结果更糟糕,尝试关闭 Nagling,看看是否有用。要关闭 Nagling 延迟,将 HKEY_LOCAL_MACHINE\Software\Microsoft\MSSOAP\SOAPISAP 中的 "NoNagling" DWORD 值更改为 1。
看一下 WSDL 是否有导入语句。2.0 版的 toolkit 还不支持导入。唯一的途径就是自己复制 WSDL 文件,并使用剪贴将导入信息拖入主文件。这应在 toolkit 3.0 版本中解决。
联系客服