此文件包含影响 Web Service 的永久和临时局限性的完整列表。
使用 Web Service 时可能遇到的局限性分为下列几部分:
受支持的软件和规范
“Web Service 资源管理器”支持下列 Web 浏览器:
- Microsoft® Internet Explorer 6.0 或更高版本
- Mozilla 1.2.1 或更高版本
如果要在工作台外面使用 Mozilla 启动 WORF 测试环境,则建议使用最低 1.3.1 版本的 Mozilla。调用 Web Service 和描述文件的输出在 Mozilla 浏览器的较早版本中可能不能正确呈示。
使用 Web Service 向导时遇到的问题
- 如果您在创建 Web Service 时指定空的 EAR(不带任何模块的 EAR),则可能会导致异常或错误。建议您对使用向导创建 Web Service 时将选择的 EAR 至少创建一个模块,或者允许向导为您创建 EAR。
- 如果您选择为 Web Service 定制从名称空间至包或者从包至名称空间的映射,然后单击允许您定制该映射的向导的页面上的完成,则不会使用定制的映射。仅当您单击该特定页面上的完成时才会发生此错误。如果您单击下一步以进入该向导的下一页然后单击完成,就会处理这些定制映射。
- 如果您在任何 Web Service 向导内中途单击取消,则可能会留下由向导在工作空间中生成的文件以及 J2EE 部署描述符中的 Web Service 条目。应该在关闭向导之后手工删除这些文件。
使用 WebSphere® 运行时环境时遇到的问题
- IBM® WebSphere Web Service 运行时环境不能处理使用缺省 Java™ 包的 Java bean。结果是在服务器启动期间将抛出异常并且在 Web Service 在运行时不工作。
- 当使用 WebSphere 运行时环境从 Java bean
或 EJB 创建 Web Service 时,不要将复杂类型 bean 与以 Java 基本类型(例如,int、float 和 double)开头的包名配合使用。否则,生成的
WSDL 文件的模式可能会不正确地将复杂类型看作 Java 基本类型。
- 对于 RPC 样式消息,不能混合 SOAP 编码与文字编码。但是,这是 DADX 将生成的 WSDL 文档。因此,不能正确地从使用 RPC 为 DADX Web Service 生成的 WSDL 文件来创建 WebSphere 客户机。要防止发生此问题,使用 DOC 样式创建 DADX Web Service。WebSphere 运行时环境可以从此 WSDL 创建客户机而不会产生问题。要使用
DOC 样式 DADX Web Service,将 DADX 组的 group.properties 文件中的 useDocumentStyle 参数设置为 true。这也可以通过 DADX 组配置向导来完成。
- 当从 Java bean
或 EJB 创建 Web Service 时,如果 Java 或 EJB 实现具有对不同包中的 Java 类的引用,则生成的
WSDL(更具体地说,WSDL 文件的 <schema> 部分)可能会丢失 <import> 语句。注意:这只会影响针对 WebSphere Application Server V5.x 的 Web Service - 它不会影响使用 WebSphere Application Server V6 的 Web Service。
- 当从 WSDL 文件生成 Java 或
EJB 框架时,如果使用的 WSDL 文件包含不具有标准 JAX-RPC 映射的 XML 类型(例如,<choice> 组),则生成的框架实现不能正确创建相应的
javax.xml.soap.SOAPElement。因此,Web Service 可能会返回结构不良的 SOAP 响应。
以下方法可解决此问题:
- 打开实现类。
- 转至实例化 SOAPElement 的行(应该类似如下内容:createSOAPElement("http://schems.ibm.com/wswrapper",">D")
- 除去 > 字符。
- 保存它并重新启动 EAR 项目。
注意:这只会影响针对 WebSphere Application Server V5.x 的 Web Service - 它不会影响使用 WebSphere Application Server V6 的 Web Service。
- 在 WebSphere 运行时环境上部署 Web Service 之后,如果更改该 Web Service 使用的其中一个类,则可能不会刷新更改并且可能在服务器控制台中产生 ClassCastException。如果真的产生异常,则右键单击“服务器”视图中的服务器,选择重新启动项目,然后选择包含具有已更改类的项目的 EAR。注意:这只会影响针对 WebSphere Application Server V5.x 的 Web Service - 它不会影响使用 WebSphere Application Server V6 的 Web Service。
- 如果使用 WebSphere 运行时环境创建 Web Service 客户机,则客户机的部署描述符在“通用测试客户机”中不可用。因此,客户机代理的 JNDI 查询在“通用测试客户机”中不起作用。要使用 UTC,必须构造并使用“定位器”类,或者使用生成的“代理”类并将 useJNDI 设置为 false(这将在内部构造并使用“定位器”)。注意,如果未处理客户机端部署描述符,则诸如 WS-Security 和 Handlers 的某些元数据将不可用。此类客户机配置的一个示例是安全性。使用样本 JSP 而不是“通用测试客户机”来测试代理。
- 在 RPC/文字中不支持数组:当创建 RPC/文字服务时,方法特征符中不能包含数组。如果方法特征符包含数组,则不能使用生成的客户机代码调用服务。此问题当前没有变通方法。若有可能,请尝试使用文档/文字或 RPC/编码。注意:这只会影响针对 WebSphere Application Server V5.x 的 Web Service - 它不会影响使用 WebSphere Application Server V6 的 Web Service。
- WSDL 导入:WSDL
import 语句只能具有绝对 URL 或同一目录中的相对 URL。例如,不支持以下格式的相对导入:<import namespace="http://someNamespace/" location="../someFile.wsdl"/>
- 当从 WSDL 文件生成框架 EJB 时,如果 WSDL 文件使用基于 JMS 的 SOAP 作为传输方法,则确保路由器项目是 EJB 项目而不是 Web 项目。否则,在完成 Web Service 创建向导时将会产生错误消息。
- 在生成 EJB
框架时,如果选择 J2EE 级别 1.2 Web 项目作为“服务部署配置”页中的“路由器”项目,则在继续向导前,确保选择了包含在
Web 项目所在的同一个 EAR 中的现有级别 1.1 EJB 项目作为 EJB 项目。如果依赖向导自动创建 EJB 项目,则向导将创建级别 2.0 的 EJB 项目,该项目与级别 1.2 的 EAR 和级别 1.2 的 Web 项目不兼容。
- 当从 WSDL 文件(该文件使用没有任何缺省 JAX-RPC 映射的类型)生成 EJB 框架时,在用户尝试调用 Web Service 时将会返回运行时环境异常。产生问题的原因是运行时对 javax.xml.soap.SOAPElement 进行反序列化有困难。java.xml.soap.SOAPElement 是在类型没有任何相关联的映射时使用的,因此,它被作为文档片段映射。注意:这只会影响针对 WebSphere Application Server V5.x 的 Web Service - 它不会影响使用 WebSphere Application Server V6 的 Web Service。
- 当使用具有输入输出参数的操作从 WSDL 文件生成 EJB
框架时,在为 EJB 生成部署代码时将出现错误。产生问题的原因是输入输出参数被映射至
javax.xml.rpc.holders.Holder 类。因为 java.xml.rpc.holders.Holder 不实现 java.io.Serializable,所以它们将导致
EJB 部署错误。注意:这只会影响针对 WebSphere Application Server V5.x 的 Web Service - 它不会影响使用 WebSphere Application Server V6 的 Web Service。
使用 Apache Axis 1.0 运行时环境存在的问题
在使用 IBM SOAP 运行时环境的情况下的永久局限性
IBM SOAP 运行时环境应主要用于向后兼容性。对于所有生产,强烈建议您将 Web Service 向导与 IBM WebSphere 运行时环境配合使用。当将 Web Service 向导与 IBM SOAP 运行时环境配合使用时,用户可能会遇到下列永久局限性:
- 从 Java bean 生成 WSDL 文档
- char 和
java.lang.Character 要求您输入定制映射,因为从
char 或 java.lang.Character 至 WSDL XSD 的缺省映射不存在。
- 基本包装器类型 java.lang.Boolean、java.lang.Byte、java.lang.Short、java.lang.Integer、java.lang.Long、java.lang.Float 和
java.lang.Double 不能与服务 bean 的所有输入参数中它们相应的单个基本类型 boolean、byte、short、int、long、float 和 double 共存。例如,不能将 java.lang.Integer 和
int 同时出现在其中某个地方作为输入参数类型的服务 bean 转换为完整的 Web Service。当尝试使用 Web Service 向导来从此类型的服务
bean 创建 Web Service 时,除非未在该向导的“Web Service Java
Bean 方法”页面上选择包含基本类型或包装器类型的方法,否则将显示警告消息。但是,必须确保在第一次遇到“Web Service Java Bean 方法”页面时,未选择这些方法。在看到警告后返回到此页面并清除存在问题的方法可能会产生不完整的 Web Service。在这种情况下,应重新启动向导,以便可以在第一次遇到“Web Service Java Bean 方法”页面时进行正确的方法选择。
- 不支持多维数组。Java 中的备用方法是在各维之间插入 Java bean。例如,模式 MyArray[](其中 MyArray 具有类型为 MyType[] 的属性)而不是 MyType[][] 将能够凑效。
- 具有包含 DOM 元素和简单 bean 类型混合的输入参数列表的方法需要一个或多个定制映射的条目。“Web 服务定义语言”(WSDL)版本 1.1 规范对于所有输入部件(参数)都支持一种编码样式。“简单对象访问协议”(SOAP)版本 2.2 运行时环境不具有对带有文字 XML 编码的基本类型和 bean 的 SOAP 编码的“DOM 元素”的缺省映射支持。
- 在配置定制映射时,如果尝试使用来自 SOAP 运行时环境的序列化器和反序列化器类(即,来自包 org.apache.soap.encoding.soapenc 的类)并接收到错误“不能从此项目装入选择的序列化器/反序列化器类”,则 soap.jar 很可能不在 Web 项目构建路径上。要更正该问题,取消向导,使用“Web 项目属性”对话框来将 WS_installdir\wstools\eclipse\plugins\com.ibm.etools.webservice\run-time environment\soap.jar 添加至 Web 项目的构建路径,然后重试 Web Service 向导。
- 对于嵌套的复杂类型,不支持定制映射。尽管嵌套类型将出现在向导的映射页上,但是这些类型的定制映射将被忽略。
- 当从
Java 类(其接口包含抽象 Java 类型)创建 Web Service 时,Web Service Java 至 XML 映射页可能会不正确地将该抽象类型的反序列化器字段设置为 org.apache.soap.encoding.soapenc.BeanSerializer。这在运行时环境中将会失败,因为 BeanSerializer 类中的反序列化器代码将不能构造该抽象类型的实例。为了避免此问题,必要时选择类型的“定制映射”选项并将反序列化器字段更改为编写来对该抽象类型进行反序列化的类的名称。
- Web Service 工具当前不支持从包含嵌套内部类(即,在顶级类内定义中的内部类)的
Java Bean 创建 Web Service。要解决此问题,应将内部类移至单独的 Java 文件中的顶级类。
- 当从
Java
bean(它使用其它具有属性类型 Vector、Hashtable
或 Map 的 Java Bean)创建
Web Service 时,将从名称空间“http://xml.apache.org/xml-soap”生成具有包含类型“Vector”和“Map”的
complexTypes 的 XSD。因为此名称空间当前没有模式,所以“XSD 验证器”将生成错误和警告,如下所示:
- src 解析错误:不能将名称“xsd2:Vector”解析为类型定义组件。
- 警告 src-import.0:无法读取导入的模式文档“null”。
这些错误和警告不会干扰 Web Service 向导对 WSDL 和 XSD 的正确处理。将把“Map”和“Vector”类型正确地映射至它们的 Java 对应项。注意,其它供应商在处理包含这些类型的
WSDL 或 XSD 时可能会遇到困难,因为 http://xml.apache.org/xml-soap 不是 WSDL 1.1
或 SOAP 1.1 规范可识别的名称空间。为了提高互操作性,考虑使 Java 收集类与数组和
bean 相适应,然后从适配器构建 Web Service。
- 从 WSDL 文档生成 Java 构件
- 支持将限于每个 input 或 output 元素一个部件。不支持一个输入或输出消息中有多个逻辑部件。将处理第一个这样的部件并且将忽略其余的部件。
- 当从使用类型 base64Binary(它来自 xsd(http://www.w3.org/2001/XMLSchema)名称空间)的 WSDL 生成 Web Service 框架或代理时,Web Service 运行时环境实际上将使用来自 soapenc(http://schemas.xmlsoap.org/soap/encoding/)名称空间的 xsi:type base64。通常,这两种类型可自由互换。但是,消息中的类型与模式中的类型之间的差别可能会导致某些 SOAP 协议运行时环境拒绝消息。如果出现这种情况,可以手工制作类似于
Apache SOAP 的 Base64Serializer 的序列化器,但是它将为 xsd:base64binary
而不是 soapenc:base64。
- 如果 Java bean 框架是从包含不是有效
Java 标识的操作和部件名称的 WSDL 文档创建的,则不会编译它们。WSDL 操作和部件名称必须是有效的
Java 标识才能成功创建 Java bean
框架。
- 缺省情况下,当生成 WSDL 时,Web Service 向导使用“http”URI,但是来自其它工具的一些
WSDL 文档可能偶然会使用一些使用除“http”之外的方案(例如,“urn”)的 Web Service、“SOAP 操作”或“目标名称空间”URI。当从包含非 http URI 的
WSDL 生成代理或框架时,Web Service 向导可能会将这些 URI 映射至 Java 包“com.example”而不是映射至更有意义的包。在某些情况下,Web Service 向导可能无法彻底处理这些 URI 并且将生成错误“IWAB0234E 发生了内部错误”。
- 当从 WSDL 生成 Java 代理和 Java 框架时,可以选择将 XSD 本征类型 boolean、byte、short、int、long、float 和 double 映射至“java.lang”包装器类型(例如,java.lang.Integer),而不是映射至 Java 基本类型(例如,int)。缺省情况下,Web Service 向导将映射至 Java 基本类型。相反,要使向导映射至“java.lang”包装器类,打开 Windows® ->“首选项”->“Web Service”->“代码生成”并选择“将简单 XML 数据类型映射至 java.lang 包装器类”。
- 当从 Java bean
或 EJB 创建 Web Service 时,如果指定从 Java 类型至
XSD 类型的定制映射,则 Bean 类字段会被自动设置为 Java 类型的全名并且不能编辑它。当定制映射
Java 数组时,Bean 类名将使用数组格式,例如,“java.lang.String[]”,并且将以此格式发送到“.isd”和“dds.xml”部署描述符文件中。SOAP 运行时环境不能正确处理此格式的类名,从而将导致类似如下的错误:
SOAP 服务
http://tempuri.org/webservice.AddressBook 中发出部署错误:类名 java.lang.String[] 未能解析:java.lang.String[]
因此,不能定制服务端上 Java 数组的序列化器的映射。部分变通方法是对于定制映射,使序列化器类字段保持空白。这将消除将数组类名生成到部署描述符中,从而使服务能够起作用。注意,反序列化器类以及定制反序列化器的映射不受此问题和变通方法的影响。
在 XSD Bean 生成器中具有一定局限性。它不能处理重复命名的元素。例如,如果您的模式的格式为:
<xsd:schema>
<xsd:choice>
<xsd:element name="aElem" type="xsd:string">
<xsd:sequence>
<xsd:element name="bElem" type="xsd:string">
<xsd:element name="aElem" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:choice>
</xsd:schema>
则 XSD Bean 生成将使用多个具有相同方法名的 setter 来创建 bean。如果序列中 aElem 的类型发生更改,则会发生类似的问题,两个 getter 中的每个 getter 都将返回不同的类型,但是它们具有相同的自变量。
- 运行时注意事项
- 如果选择 Web Service 代码生成首选项“启用基于元素的映射”并且选择了部署到
WebSphere Application Server V4,则在
ISD 文件和 dds.xml 中可能会有以下条目:
<isd:map encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:x="" qname="x:some-name" xml2JavaClassName="some-serializer"/>
XML 编辑器可能会标记以下错误:
属性“xmlns:x”的值无效。具有前缀的名称空间绑定不能是空的。
此错误对于
WebSphere Application
Server V4 是无害的。然而,不要尝试将此 dds.xml 部署到使用
Xerces 2.x (XML4J 4.x) 或更高版本(例如,WebSphere Application
Server V5)的其它服务器。否则,在服务器装入 dds.xml 文件时将会产生类似的 Xerces 解析错误。应通过完成 Web Service 方案并选择正确的服务器类型来重新生成 dds.xml。这将为该服务器类型生成正确的
dds.xml。
另外,当尝试从该 ISD 文件部署 Web Service 时也会产生类似的
Xerces 解析错误。变通方法是手工将该文件编辑为以下格式:
<isd:map encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" qname="some-name" xml2JavaClassName="some-serializer"/>
当调用从 Java bean
或 EJB 创建的 Web Service 时,如果产生具有 targetException 的 SOAPException,如:“java.lang.IllegalArgumentException: 无法实例化 ...” 产生该问题的原因可能是:作为 Web Service 的方法包含不具有公用缺省构造函数作为参数和/或返回类型的 Java bean。需要公用缺省构造函数以便 SOAP 运行时环境将对象构造为反序列化过程的一部分。
- 当前部署到 Web 项目中的安全性文件
cl-ver-config.xml 和 sv-ver-config.xml 是来自
WebSphere V4.0 的文件并且不与 DTD 精确匹配。但是这些文件在 WebSphere V4.0 和
WebSphere V5.0 上都能工作,尽管验证错误说明必须声明“xmlns:ds”或“xmlns:SOAP-SEC”。
- 如果创建使用同一个包中两个不同的复杂类型的 bean,则在从此
bean 创建基于 SOAP 的 Web Service 时,将为每个复杂类型创建 XSD 文件并且将给予它们相同的名称空间。这会导致在“任务列表”和“Web Service 资源管理器”中产生验证错误。
- ISD Web Service
- 当创建 Java 或 EJB Web Service 时,在填写了定制映射后,将把定制映射信息(XSD 位置 URL 除外)存储在 ISD 文件中。当从该 ISD 文件创建 Web Service 时,就会检索该信息。因此,当从
ISD 文件创建 Web Service 时,在向导的 Web Service Java 至 XML 映射页中,需要手工填写 XSD 位置 URL。
创建 Web Service 客户机时的局限性
当将 Web Service 客户机部署至 EJB 项目时,代理配置页将包括一个组合框,它允许您选择此 Web Service 客户机将属于哪个 EJB。这是由 JSR-109 定义的一个需求,其中 component-scoped-refs 元素的组件名必须与模块中 EJB 的 ejb-name 相匹配。
当项目中至少有一个 EJB 时,将不会发生错误。但是,如果项目中没有 EJB,则代理配置页中的组合框将是可编辑的并且将具有一个这样的缺省值:它是 WSDL 中的服务名称,并且以“EJB”作为后缀。而且,客户机向导将会显示一个警告对话框,指示因为 Web Service 客户机不属于现有 EJB,所以部署不完整。用户可以通过创建一个与 webservicesclient.xml 中使用的组件名具有相同名称的 EJB 来修正此问题。
但是,如果选择从向导取消来异常终止客户机创建,则向导将不会从 webservicesclient.xml 除去不完整的 component-scoped-refs。应该在重新部署之前手工除去不完整的 component-scoped-refs。
当生成 URL Web Service 或仅包含 HTTP GET 和 POST 绑定的任何 WSDL 的 Web Service 客户机时,对该客户机使用 IBM SOAP 运行时环境。使用 Axis 或 IBM WebSphere 运行时环境的任何尝试都将导致生成的代码不完整或内部错误(IWAB0234E 发生了内部错误)。
当从 URL 生成 Web Service 时,产生的 WSDL 具有 HTTP GET 和 HTTP POST 绑定,但是没有 SOAP 绑定。Axis 和 IBM WebSphere 运行时环境不支持 WSDL 中的 HTTP GET 和 POST 绑定。只有 IBM SOAP 运行时环境才支持 HTTP 绑定。要了解有关 WSDL 绑定的更多信息,请参阅 http://www.w3c.org/TR/wsdl
Web Service 资源管理器问题
- 当“Web Service 资源管理器”装入使用多个直接插入模式的 WSDL 文件时,将会对这些模式间引用的类型生成警告消息。警告消息将类似于以下内容:未解析类型 <qualified_type_name> 的引用。这些是警告而不是错误,因此,可以安全地忽略它们。
- 当将“Web Service 资源管理器”与“专用 UDDI 注册中心”配合使用时,在下列情况下,不会装入企业节点的“管理发布器断言表单”:
- 您未登录到包含企业节点的注册中心节点中。
- 您登录到包含企业节点的注册中心节点中,但是企业节点不为用来登录到包含的注册中心的用户标识/密码所拥有。
- 将不能通过启用了基本认证的 UDDI 注册中心来使用“Web Service 资源管理器”进行查询或发布。此类注册中心的一个示例是在打开了基本认证的服务器上部署的专用注册中心。请注意,所有公用注册中心(IBM、Microsoft、SAP、NTT 和 XMethods)都不受此问题影响。
- 当在“Web Service 资源管理器”中使用高级搜索来在使用
Cloudscape™ 后端配置的
WAS 专用 UDDI 注册中心中查找企业并且指定了一个或多个服务接口作为参数时,搜索将会失败并且状态窗口将显示:com.ibm.uddi4j.wsdl.client.UDDIWSDLProxyException:未能列示所有服务提供者。------------------------------------------------------------------------------
嵌套异常是:
E_fatalError (10500) 处理请求时发生了严重的技术错误。: Fault
code=Client Fault string=Client Error Fault actor=null Detail=null DispositionReport:
ErrCode=E_fatalError ErrInfoText=E_fatalError (10500) 处理请求时发生了严重的技术错误。
- XMethods 注册中心具有适当的过程来验证已发布的 Web Service,从而删除不能访问或不起作用的那些 Web Service。为了防止删除已发布的 Web Service,确保在因特网上可以访问 WSDL 文件内的所有 URL 引用。
- 在 findQualifier
等于“combineCategoryBags”(tModelKey 等于 UUID:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2)的情况下,“SAP UDDI 企业注册中心”将对按类别请求的查找企业返回
E_fatalError。将在状态窗口中显示下列错误消息。这是“SAP UDDI 企业注册中心”特有的问题。com.ibm.uddi4j.wsdl.client.UDDIWSDLProxyException:未能列示所有服务提供者。------------------------------------------------------------------------------
嵌套异常是:
处理请求时发生了严重的技术错误。: Fault code=Client Fault string=UDDI Error
Fault actor=null Detail=null DispositionReport: ErrCode=E_fatalError ErrInfoText= 处理请求时发生了严重的技术错误。在 com.ibm.uddi4j.wsdl.client.UDDIWSDLProxy.findAllServiceProviders(UDDIWSDLProxy.java:1626) 中
在 FindBusWithQualifier.main(FindBusWithQualifier.java:35) 中
- “SAP UDDI 企业注册中心”返回的发布器断言报告不包含任何状态。因此,对于 SAP 返回的报告,“Web Service 资源管理器”的“管理发布器断言表单”中的发布器断言状态列将为空白。这是“SAP UDDI 企业注册中心”特有的问题。
- 当尝试将企业、服务或服务接口发布至“XMethods UDDI 注册中心”时,将产生关于“SSL 握手失败”的错误消息。这是 IBM 和
XMethods 正在研究的已知问题。
“Web Service 资源管理器”不能建立与 SAP UDDI(测试)注册中心、NTT 通信注册中心以及 XMethods 注册中心的安全 SSL 连接。因此,要求用户提供凭证的任何操作都将以下列异常失败(不要求凭证的操作(例如,发现)将继续工作):
注册中心 |
错误 |
NTT 通信注册中心: |
NTT 通信注册中心:
IWAB0135E 发生了意外错误。UDDIWSDLProxyException
获取 [userid: <userid> ] 的认证令牌时出错
嵌套异常为:org.uddi4j.transport.TransportException:打开套接字时出错:javax.net.ssl.SSLHandshakeException:证书已到期
|
XMethods 注册中心: |
IWAB0135E 发生了意外错误。
UDDIWSDLProxyException
获取 [userid: <userid> ] 的认证令牌时出错
嵌套异常为:
org.uddi4j.transport.TransportException:打开套接字时出错:javax.net.ssl.SSLHandshakeException:握手失败
|
DADX Web Service
当从 DADX 文件生成 WSDL 文档时,下列限制适用。
- 不支持为具有多个输出参数的 DADX 调用操作生成 Java 代理。
- 当创建 DADX Web Service 时,偶尔会显示消息“IWAB0177E 从 DADX 文件生成 WSDL 时出错”。在大多数情况下,此消息指示存在一些与数据库有关的问题,应查阅服务器控制台日志以获取关于该问题的详细信息。另外,检查下列各项:
- DAD(*.dad)文件必须位于 DADX 组目录中。这是 WORF 运行时环境查找 DAD 文件的方式。
- 如果要尝试从“RDB 至 XML 映射”文件(.rmx)生成 DAD 文件,则确保 DAD 文件位于 DADX 文件所在的同一个文件夹中。
在 DADX 组中,可以指定 JDBC 网络驱动程序。对于 DB2®,网络驱动程序类为 COM.ibm.db2.jdbc.net.DB2Driver。对于较早版本的 DB2,需要将 db2java.zip 添加至服务器类路径,此压缩文件包含驱动程序。但是,对于 DB2 版本 8.1 和更高版本,也需要将文件 db2jcc.jar 添加至服务器类路径。该文件通常与 db2java.zip 文件位于同一目录中。确保您的机器上的 DB2 客户机级别与要连接至的 DB2 服务器处于同一修订包级别。
DADX Web Service 中的多个输出:通常,我们的工具不支持 Web Service 中有多个输出。但是,对于 DADX Web Service,如果将使用文档样式组属性设置为 true,则允许多个输出。在这种情况下,当文档样式为 true 时,将把多个输出组合为单个 XML 文档。
DADX 生成支持:尽管用户定义的函数列示在“生成 DADX”向导中,但当前不支持从用户定义的函数生成 DADX。只支持从 DAD 文件、存储过程和 SQL 语句生成 DADX。选择 UDF 将导致生成简单 DADX 框架文件。
使用数据源信息设置 DADX 组:如果要使用 WebSphere Application Server 来主管 DADX Web Service,并且 DADX 组被配置为通过数据源访问数据库,则该 DADX 组的 group.properties 文件应使用以下 initialContextFactory 属性:initialContextFactory=com.ibm.websphere.naming.WsnInitialContextFactory。
另外,包含 DADX 组的项目的 web.xml 文件包含需要添加下列内容。(假定数据源 JNDI 名称是 jdbc/hospital。)
<resource-ref id="ResourceRef_1058550453092">
<res-ref-name>jdbc/hospital</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>CONTAINER</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
将 Tomcat 服务器与 AXIS 运行时环境配合使用
如果使用 Tomcat 4.1 和 4.0 服务器,这些服务器将使用 Axis 的 Web 应用程序安装在 Linux 上,则您在 Web Service 向导中可能会遇到错误。如果启动了服务器并要求在 Web Service 向导中的某个位置重新启动,则向导可能会挂起,因为 Axis 会阻止 Tomcat 服务器停止。
变通方法是在启动 Web Service 向导之前停止服务器并在生成测试 Web Service 应用程序的向导页上取消选择“在服务器上运行”。
使用 Web Service 命令行时出现问题
- 目录中具有空格:避免从目录名称中包含空格的目录运行 WSDL2WebService。否则,不会编译生成的 compile.bat(或者在 Linux 上为 compile.sh)。
- 在运行 EJB2WebService 来创建
EJB Web Service 之后,如果使用 splitWsdl 选项,则生成的 EAR 不能在“单元测试环境”或远程服务器上运行。变通方法是将 EJB 项目的
META-INF 下面的整个 WSDL 目录复制到路由器 Web 项目的 WEB-INF 下面。
- 在运行 WSDL2WebService 以使用其中具有本地导入的 WSDL 创建 EJB Web Service 之后,生成的 EAR 不能在“单元测试环境”或远程服务器上运行。变通方法是将 EJB 项目的
META-INF 下面的整个 WSDL 目录复制到路由器 Web 项目的 WEB-INF 下面。
- 在将包含由使用 J2EE 1.4 的命令行工具生成的 EJB 客户机的 EAR 导入工作空间之后,您将看到编译错误。要修正这些错误,右键单击 EJB 项目并选择属性。转至 Java 构建路径,然后选择库选项卡。除去 EJBClientProject/imported_classes(类文件夹)条目。添加类文件夹 EJBServiceClient/imported_classes/Meta-inf/classess。单击确定。
- 在将包含由使用 J2EE 1.4 的命令行工具生成的应用程序客户机的 EAR 导入工作空间之后,运行客户机时将产生 ClassNotFoundException 错误。要修正这些错误,右键单击应用程序客户机项目,然后选择属性。转至 Java 构建路径,然后选择库选项卡。除去 ApplicationClientProject/imported_classes(类文件夹)条目。添加类文件夹 ApplicationClientProject/imported_classes/Meta-Inf/classess。单击确定。
使用 HTTP 基本认证导入 WSDL 文件
当从具有相对导入并且是受“HTTP 基本认证”保护的 WSDL 文件生成框架或客户机时,用户将看到一条错误消息,该消息指示不能解析 WSDL 文件,即使输入了正确的用户标识和密码也是如此。产生问题的原因是该用户标识和密码只能用于检索原始 WSDL 文件,不能用于检索它导入的文件。
要解决此问题,用户可以首先将 WSDL 文件及其导入的所有文件下载到工作台中,然后从下载的 WSDL 文件生成框架或客户机。
未看到资源首选项
使用 Apache Axis 1.0 运行时环境的时候,Axis 发射器每次都重新生成所有服务器/客户机 Java 文件 deploy.wsdd 和 undeploy.wsdd。仅当框架实现文件不存在时,服务生成方案的 WSDL2Java 才生成该框架实现文件。如果此实现已经存在,则它不会被覆盖。
在小组开发环境中工作时遇到问题
当在 ClearCase
® 小组环境中共享 Web 项目时,如果选择的 Web Service 运行时环境为 IBM WebSphere 或 Apache Axis 1.0,则将在 Web Service 和 Web Service 客户机创建期间打开几个
添加至源控制对话框。要消除这些对话框,执行下列操作:
- 从“窗口”菜单中选择首选项
- 展开左窗格中的小组。选择 ClearCase。
- 在右窗格中,将标注为在添加新资源时下拉菜单的值更改为自动添加至源控制。
- 单击确定。
- 转至 。
- 在打开的对话框中,选择缺省活动。单击确定。
Web Service 备忘单
在创建、测试和验证符合
WS-I 的“Web Service 备忘单”和从 WSDL 文件备忘单创建 Web Service 时,如果要使用来自 wsad_install/wstools/eclipse/plugins/com.ibm.etools.cs.wsdl.content_ver/examples 的 HelloService.wsdl 文件,则请根据不同的运行时环境修改服务端口位置,如下所示:
对于 IBM SOAP:
location="http://localhost:9080/HelloWorldSample/servlet/rpcrouter"
对于 Apache Axis 或 WebSphere 运行时环境
location="http://localhost:9080/HelloWorldSample/services/Hello_Port"
如果要导入您自己的
wsdl 文件,则应确保如上所述根据所选择的运行时环境正确设置了位置。
不能运行“供应链管理”样本
- 在“供应链管理”示例中,如果需要更改缺省 9080 端口,则需要在 SCM-Sample 项目中修改 config.jsp 文件,这将要求重新编译。由于构建路径中缺少 webservices.jar,您将在任务列表中发现 2 个编译错误。
- 此编译单元间接引用缺少的类型 javax.xml.rpc.ServiceException
- 不能解析导入 javax.xml.rpc
要将 webservices.jar 添加至 SCM-Sample 的构建路径,执行下列操作:SCM-sample -> 属性,选择 Java
构建路径,单击库选项卡,单击添加变量,选择 WAS_50_PLUGINDIR,单击展开,转至 lib 并选择 webservices.jar,单击确定并再次单击确定。