WebSphere Application Server V6.1 Web Services Problem Determination
WebSphere Application Server V6.1 Web Services Problem Determination
Introduction
WebSphere Application Server V6.1 provides extensive support for Web
services standards. It can host both Web service client and provider applications.
Problems can occur due to coding errors, invalid requests, deployment code
generation, or the runtime configuration.
This activity covers the following types of Web services problems:
Problems that occur during development
Problems deploying Web services applications
Problems that occur during runtime
If you believe that you have a Web services gateway, service integration bus,
WSIF, or Web services security problem, go to The next step on page 47 for
information about online resources and contacting IBM.
a variety of ways, for example, with the WSDL2Java tool, by Rational Application
Developer, or by selecting an option during installation. However, the basis for
each of these methods is, once again, the WSDL2Java tool.
Symptoms of a Web services deployment problem generally appear in the
SystemOut log or, if using the wsdeploy command, in the command window. The
first indication is a WSWS0038E: Error from Web services deploy tool
message.
Problems deploying Web services applications on page 16 focuses on
problems that occur when deploying a Web service client or provider application
to WebSphere Application Server.
WSDL2Java
A WSDL file acts as a contract between client and provider. Client and provider
agree to send SOAP messages structured according to what the WSDL
describes. WSDL2Java is used for developing Java-based Web service client
and provider applications from a WSDL file.
Web service provider applications can run in the EJB and Web container. Web
service client applications can also run in the EJB and Web container, as well as
the J2EE client container. These types of clients are commonly known as
managed clients. A Web service client can also be a standalone Java application;
this is commonly known as an unmanaged client.
But whether client or provider and whether it runs in a container or not, any
application developed using WSDL2Java should comply with the JAX-RPC
Identify symptoms
Symptoms of a WSDL2Java problem covered in this topic include:
Error or warning messages with the WSWS prefix occur when WSDL2Java is
executed.
When WSDL2Java is used from the command line, the error messages
appear in the command window as it executes. When WSDL2Java errors
result during wizard execution in Rational Application Developer, the error is
displayed in a new error window.
WSDL2Java generates code that does not compile.
The compiler will report errors that occur during the compile of
WSDL2Java-generated code. If you are using Rational Application Developer
or the Application Server Toolkit, you will see the messages in the
workbench. If using the command-line (javac), you will see the messages
displayed to that interface (the DOS prompt or korn shell).
If you see your symptom in the following list, please refer to the relevant article in
the Information Center.
Compiler errors
Web services compiled bindings troubleshooting tips:
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.
websphere.nd.doc/info/ae/ae/rwbs_trbjavacompiler.html
Java code to Web Service Description Language (WSDL) mapping cannot be
reversed to the original Java code.
Command-line tools symptom list
Web services command-line tools troubleshooting tips:
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.
websphere.nd.doc/info/ae/ae/rwbs_trbcommand.html
The .Net client does not reflect a Web service method with Vector-type
parameters.
The following exception is displayed:
System.InvalidOperationException: Method
AnnuityInteropService.wsListAnnuityByHolder can not be reflected.
System.InvalidOperationException: There was an error reflecting
wsListAnnuityByHolderResult.
System.InvalidOperationException: The Form property might not be
unqualified when an explicit namespace property is available.
Multiprotocol port component restrictions with Web Services for J2EE
Version 1.0 and 1.1 Specifications:
Error in <module> : CHKW6030E: Implementation class <class>
referred to by port components<port1> and <port2>. (JSR109 1.0:
7.1.2).
Avoiding application errors after uninstalling an interim fix, a fix pack, or a
refresh pack.
Using a proxy server to access the Internet while running the WSDL2Java
command causes your connection to time out.
An emitter failure error occurs when running the WSDL2Java command
on a WSDL document containing a JMS-style endpoint URL:
WSWS3099E: Error: Emitter failure. Invalid endpoint address in
port <x> in service <y>: <jms-url-string>
WSWS3574E, WSWS3205E
The messages shown in Example 1 indicate that a relative URI has been used. If
you see these messages, go to targetNamespace is a relative URI on page 12.
Example 1 WSWS3574E, WSWS3205E
WSWS3574E: ---------- FATAL ERRORS ENCOUNTERED ---------GENERATION OF ARTIFACTS HAS BEEN SUSPENDED.
See messages to follow for more details.
WSWS3205E: Error: Type {relative.test.com}sayHelloRequestType is
referenced but not defined.
The same error in Rational Application Developer would appear during the
execution of a Web services wizard. It would appear in an error box (Figure 1).
WSWS3099E
If you have the emitter failure error WSWS3099E: Error: Emitter failure.
Invalid endpoint address in port <x> in service <y>: <jms-url-string>
when running the WSDL2Java command on a WSDL document containing a
JMS-style endpoint URL, see the Web services command-line tools
troubleshooting tips WebSphere Information Center article for more information,
available at:
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.
websphere.nd.doc/info/ae/ae/rwbs_trbcommand.html
10
</element>
<element name="testHelloRequest">
<complexType>
<sequence>
<element name="name" nillable="true" type="xsd:string"/>
</sequence>
</complexType>
</element>
</schema>
Workaround
To work around the compilation error, change the WSDL and schema
targetNamespace to use a traditional URI scheme, such as http, file, or urn. For
example, from:
hhttp://test.com
to:
http://test.com
Then invoke WSDL2Java to re-generate the classes. The resulting classes
should not contain any compilation errors.
<wsdl:message name="testHelloRequest">
<wsdl:part name="parameters" element="intf:testHelloRequest"/>
</wsdl:message>
<wsdl:message name="testHelloResponse">
11
Support preparation
If the work around or applying fix pack 6.1.0.9 does not resolve the problem,
collect the following data for use by IBM support:
WSDL and any referenced schema files
WSDL2Java command invocation, or a description of how Rational
Application Developer or the Application Server Toolkit was used to generate
the non-compiling classes
Go to The next step on page 47 for information about performing an online
search of Web services problems and for a list of useful technical articles. If
these resources do not help you resolve the problem, contact IBM support.
12
WSWS3574E: ---------- FATAL ERRORS ENCOUNTERED ---------GENERATION OF ARTIFACTS HAS BEEN SUSPENDED.
See messages to follow for more details.
WSWS3205E: Error: Type {relative.test.com}sayHelloRequestType is
referenced but not defined.
java.io.IOException: FATAL ERRORS encountered by WSDL2Java tool.
at com.ibm.ws.webservices.wsdl.Parser.generate(Parser.java:467)
at com.ibm.ws.webservices.wsdl.Parser.generate(Parser.java:394)
at com.ibm.ws.webservices.wsdl.Parser.run(Parser.java:299)
at com.ibm.ws.webservices.wsdl.WSDL2.run(WSDL2.java:318)
at com.ibm.ws.webservices.tools.WSDL2Java.main(WSDL2Java.java:492)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.ja
va:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso
rImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at com.ibm.ws.bootstrap.WSLauncher.main(WSLauncher.java:263)
This error happens because the WSDL contains an embedded schema with a
targetNamespace set to a relative URI.
13
Example
In this example, the WSDL definitions element contains the namespace
declarations shown in Example 7.
Example 7 WSDL namespace declarations
<wsdl:definitions targetNamespace="http://helloworld.com"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:tns1="relative.test.com"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
...>
Then the WSDL embeds an XML schema (Example 8).
Example 8 Embedded XML schema
<wsdl:types>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="relative.test.com">
<import namespace="http://schemas.xmlsoap.org/soap/encoding/"/>
<complexType name="sayHelloRequestType">
<sequence>
<element name="msg" type="xsd:string"/>
<element name="id" type="xsd:int"/>
</sequence>
</complexType>
<complexType name="sayHelloResponseType">
<sequence>
<element name="msg" type="xsd:string"/>
<element name="id" type="xsd:int"/>
</sequence>
</complexType>
</schema>
</wsdl:types>
14
<wsdl:message name="sayHelloRequest">
<part name="parameter" type="tns1:sayHelloRequestType"/>
</wsdl:message>
<wsdl:message name="sayHelloResponse">
<wsdl:part name="parameter" type="tns1:sayHelloResponseType"/>
</wsdl:message>
WSDL2Java requires that targetNamespaces be absolute URIs. Since the
WSDL has a targetNamespace of http://helloworld.com and the embedded
schema has a specified targetNamespace of relative.test.com, WSDL2Java tries
to make that relative URI absolute by appending it to the base URN the WSDL
targetNamespace.
In other words, given this WSDL targetNamespace http://helloworld.com and
schema targetNamespace relative.test.com, WSDL2Java would resolve the
targetNamespace of the embedded schema as:
http://helloworld.comrelative.test.com
However, the prefix tns1 is set to the relative URI relative.test.com, and the
schema complexTypes are referred to using that prefix shown (see Example 9).
In essence, tns1:sayHelloRequestType means the same as
{relative.test.com}sayHelloRequestType.
The WSDL messages reference the schema types using namespace
relative.test.com, but WSDL2Java resolved the targetNamespace of those
schema types as http://helloworld.comrelative.test.com. Therefore, it issues the
error message:
WSWS3205E: Error: Type {relative.test.com}sayHelloRequestType is
referenced but not defined.
15
One way to solve the error is to set the tns1 prefix to the expected URI,
http://helloworld.comrelative.test.com, as shown in Example 10.
Example 10 Modified namespace declaration
<wsdl:definitions targetNamespace="http://helloworld.com"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:tns1="http://helloworld.comrelative.test.com"
...>
But, the namespace http://helloworld.comrelative.test.com is most likely not what
was intended. So the best guideline is to avoid relative URIs altogether, as in
Example 11.
Example 11 targetNamespace modified to be absolute URI
<wsdl:types>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://relative.test.com">
</schema>
</wsdl:types>
Support preparation
If changing the schema targetNamespace URI from relative to absolute does not
alleviate the WSWS3205E error, collect the following data for use by IBM
support:
WSDL
WSDL2Java command invocation, or a description of how Rational
Application Developer or the Application Server Toolkit was used when the
error was encountered
Go to The next step on page 47 for information about performing an online
search of Web services problems and for a list of useful technical articles. If
these resources do not help you resolve the problem, contact IBM support.
16
Identify symptoms
Symptoms of a Web services deployment problem generally appear in the
SystemOut log or, if using the wsdeploy command, in the command window. The
first indication is the following message:
WSWS0038E: Error from Web services deploy tool
This message is followed by more specific error messages in the following
format:
WSWSxxxxE
17
Collect diagnostics
Collect SystemOut log. For information about collecting SystemOut see
Collecting JVM logs on page 44.
Analyze SystemOut
Scan the SystemOut log for WSWSxxxxE messages. See Example 12.
Example 12 WSWSxxxxE messages in SystemOut
Evaluate SystemOut
Information about messages with the WSWS prefix, including suggested actions,
can be found in the WebSphere Information Center in the Messages section
under References.
If you see WSWS3467E: WSDL2Java validation error, go to targetNamespace
contains a non-traditional URI scheme on page 10.
Otherwise, go to The next step on page 47 for information about performing
online searches and gathering information required by IBM support.
18
19
Example
In this example, the user receives the error message shown in Example 13.
Example 13 WSWS3467E
package com.test;
public class HelloWorldException extends java.lang.Exception {
private java.lang.String message;
private java.lang.Integer id;
private java.lang.String detail;
public HelloWorldException(java.lang.String message) {
this.message = message;
}
public java.lang.String getMessage() {
return message;
}
public java.lang.Integer getId() {
return id;
}
20
<element name="helloWorldException">
<complexType>
<sequence>
<element name="message" nillable="true" type="xsd:string"/>
<element name="id" nillable="true" type="xsd:int"/>
<element name="detail" nillable="true" type="xsd:string"/>
</sequence>
</complexType>
</element>
The helloWorldException element is referenced in the message with the same
name, as shown in Example 16.
Example 16 helloWorldException message defined in WSDL
<wsdl:message name="helloWorldException">
<wsdl:part name="fault" element="impl:helloWorldException"/>
</wsdl:message>
21
<wsdl:operation name="testHello">
<wsdl:input name="testHelloRequest"
message="impl:testHelloRequest"/>
<wsdl:output name="testHelloResponse"
message="impl:testHelloResponse"/>
<wsdl:fault name="helloWorldException"
message="impl:helloWorldException"/>
</wsdl:operation>
Note: The JAX-RPC specification says this about the mapping of WSDL faults
to Java exceptions:
A wsdl:fault is mapped to either a java.rmi.RemoteException (or its
subclass), service specific Java exception (described later in this section)
or a javax.xml.rpc.soap.SOAPFaultException.
JAX-RPC 1.1 goes on to elaborate on service specific exceptions:
A service specific Java exception (mapped from a wsdl:fault and the
corresponding wsdl:message) extends the class java.lang.Exception
directly or indirectly. The single message part in the wsdl:message
(referenced from the wsdl:fault element) may be either a type or an
element. If the former, it can be either a xsd:complexType or a simple XML
type. Each element inside the xsd:complexType is mapped to a getter
method and a parameter in the constructor of the Java exception.
Mapping of these elements follows the standard XML to Java type
mapping.
The full specification can be downloaded from:
http://java.sun.com/xml/downloads/jaxrpc.html
In the case of our example, the WSDL fault is clearly mapped to a
service-specific exception. The bolded text highlights the remarks relevant to the
WSWS3467E WSDL2Java validation error. The HelloWorldException class is
missing a constructor that takes three parameters that correspond to the three
elements inside of the helloWorldException element's complexType.
22
<element name="helloWorldException">
<complexType>
<sequence>
<element name="message" nillable="true" type="xsd:string"/>
<element name="id" nillable="true" type="xsd:int"/>
<element name="detail" nillable="true" type="xsd:string"/>
</sequence>
</complexType>
</element>
To be compliant with JAX-RPC, HelloWorldException should also implement a
constructor like that shown in Example 20.
Example 20 HelloWorldException class constructor - correct
public HelloWorldException(
java.lang.String message,
java.lang.Integer id,
java.lang.String detail) {
this.message = message;
this.id = id;
this.detail = detail;
}
Support preparation
If changing the exception constructor does not resolve the problem, collect the
following data for use by IBM support:
The complete Web services application that fails to deploy, including the
WSDL file and the Java source of the service specific exception.
A description of how the Web services application was deployed for
instance, invoking the wsdeploy tool or installing the application using the
administrative console.
23
If deploying the application using the administrative console, enable the Web
services trace to capture the WSWS3467E deployment error. Instructions for
enabling the Web services trace can be found in Enabling the Web services
trace on page 46.
If wsdeploy is used, then collect a simple text capture of the error sent to
standard output.
Go to The next step on page 47 for information about performing an online
search of Web services problems and for a list of useful technical articles. If
these resources do not help you resolve the problem, contact IBM support.
24
Identify symptoms
Symptoms of a Web services problem appear in a variety of ways depending on
the problem, the clients environment, and how the client was designed. For
example, if invoking an unmanaged client from the command-line console, the
error messages would be displayed to that interface. If the client is a Web
application that writes to an output stream that appears in the Web browser, then
the errors would be displayed to the browser. On the provider system, the
messages will appear in the application server SystemOut log.
Messages will, with a WSWS prefix indicate a Web services related error.
Problems may also occur that do not produce a Web services error message but
will appear as unexpected results in the application. A trace of the SOAP
messages often shows the error.
Specific symptoms covered in this activity include:
Client system
javax.xml.rpc.ServiceException with message code WSWS5055E or
WSWS5014E.
For more information about this symptom see targetNamespace contains
a non-traditional URI scheme on page 10.
WSWS3713E: Connection to the remote host localhost failed. Received
the following error: Connection refused.
Verify that the host and port used to call the provider are correct.
25
Collect diagnostics
If the symptoms are not apparent, you will need to collect the following:
If the problem occurs at the client:
Messages displayed.
Logs that the client application writes messages to.
If the client is a managed client running in the server, collect SystemOut
log.
If the problem occurs at the provider: SystemOut log.
For information about collecting the SystemOut log see Collecting JVM logs
on page 44.
TCPMonitor trace.
Using TCPMonitor to view messages will not always be applicable or relevant
in every case. Sometimes, runtime problems occur before the SOAP
message can be serialized and sent across the wire. Or problems may have
nothing to do with how a message appears.
However, for certain problems, it is important to have a copy of the SOAP
request/response exchange. In particular, capture the trace when:
There is an issue with an HTTP header, for example, it is not set to the
expected value or it does not appear at all.
There appears to be a deserialization problem. The message text or Java
stack trace usually contains the word deserialization if this is the case.
There is an issue with a SOAP message.
The message exchange can be captured by recreating the problem and
tracing it using TCPMonitor. For a quick reference on using TCPMonitor, see
Collecting trace data with TCPMonitor on page 45.
You may want to analyze the SystemOut log first before deciding whether you
should recreate the problem and collect this trace.
26
Glossary terms:
Serialization is the process of converting Java objects to XML.
Deserialization is the process of converting XML to Java objects.
Analyze diagnostics
To analyze the diagnostics:
1. Scan the SystemOut log for errors.
2. If captured, scan the TCPMonitor trace output for the message causing the
problem.
If your specific symptom is not addressed here, go to The next step on page 47
for information about performing online searches and gathering information
required by IBM support.
Analyze SystemOut
In the SystemOut log, look for and make a note of any of the following:
Error messages with WSWS as the prefix.
Review the user response for WSWS messages at:
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.
websphere.messages.doc/com.ibm.ws.webservices.multiprotocol.resource
s.mpMessages.html
Note that this is the first of five WSWS message topics.
javax.xml.rpc.ServiceException
org.xml.sax.SAXException
Java stack trace with any other errors
27
Prior to fix pack 6.0.2.19 for V6.0.2 and fix pack 6.1.0.9 for V6.1, this can be due
to a bug in the WSDL2Java tool that occurs when port names contain
non-alphanumeric characters.
For more information see Port name problem on page 31.
org.xml.sax.SAXException: WSWS3047E
WSWS3047E can appear on the client or provider system. If you see this
message see Improperly formed SOAP request or response on page 38.
When a Web service client sends a request to a WebSphere Application Server
Web service, you might observe a SOAP fault like in Example 21 as a response.
Example 21 WSWS3047E SOAP fault
<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:Header/>
<soapenv:Body>
<soapenv:Fault>
<faultcode>soapenv:Server.generalException</faultcode>
<faultstring><![CDATA[org.xml.sax.SAXException:
WSWS3047E: Error: Cannot deserialize element name of bean
com.test.TestHello.
Message being parsed:
<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:Header/>
<soapenv:Body>
<p585:testHello xmlns:p585="http://test.com">
<p585:name>Wendy</p585:name>
</p585:testHello>
</soapenv:Body>
</soapenv:Envelope>]]>
</faultstring>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
28
On the WebSphere Web service provider, the error might be manifested in the
server's SystemOut. See Example 22.
Example 22 WSWS3047E on the Web service provider
29
If the WebSphere Web service client is a managed one running in the Web or
EJB container, you might also see in the server's SystemOut a stack trace
beginning with text similar to Example 23.
Example 23 WSWS3047E on the Web service client
? 00000028 MCUtils
1 com.ibm.ws.webservices.engine.utils.MCUtils
interceptDeserializationException interceptDeserializationException:
org.xml.sax.SAXException: WSWS3047E: Error: Cannot deserialize element
name of bean com.test.TestHello. org.xml.sax.SAXException: WSWS3047E:
Error: Cannot deserialize element name of bean com.test.TestHello.
If the client is an unmanaged one and using the WebSphere environment, you
might see the stack trace displayed in standard out or standard err (such as the
command-line console). During development cycles, developers commonly use
Rational Application Developer to invoke unmanaged test clients, and might see
the WSWS3047E stack trace displayed in the RAD console.
Where to go from here:
If the problem appears to involve deserialization, the SOAP message
format, or the HTTP header, collect a TCPMonitor trace of the problem.
If you found errors not listed here, go to The next step on page 47.
<soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
30
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header/>
<soapenv:Body/>
</soapenv:Envelope>
Quick test
As a test to determine whether your problem is the same as the problem
discussed here, you can modify the wsdl_serviceLocator class, bearing in mind
that doing so is not an approved practice and just serves as a temporary work
around until the true solution can be applied.
The wsdl_serviceLocator.getPort2NamespaceMap() method should be modified
so that the XML QName local part of the WSDL port name is used as the key to
the namespace value.
For example, given the following WSDL port definition:
<wsdl:port name="Test-Service" binding="impl:TestSoapBinding">
<wsdlsoap:address
location="http://localhost:9080/TestHello/Test"/>
</wsdl:port>
change from:
port2NamespaceMap.put(
"TestService",
"http://schemas.xmlsoap.org/wsdl/soap/");
31
to:
port2NamespaceMap.put(
"Test-Service",
"http://schemas.xmlsoap.org/wsdl/soap/");
Save this modified class and then re-invoke client. The WSWS5055E error
should no longer occur.
Important: This is a temporary check only. If the client is re-deployed, then
this modified class will be overwritten.
Support preparation
If applying the fix pack and re-generating client deployment code does not
resolve the problem, collect the following data for use by IBM support:
Web services trace containing the javax.xml.rpc.ServiceException:
WSWS5055E or WSWS5014E error. See Enabling the Web services trace
on page 46 for instructions on collecting the trace.
Client application test case, including the WSDL file and Java source.
Go to The next step on page 47 for information about performing an online
search of Web services problems and for a list of useful technical articles. If
these resources do not help you resolve the problem, contact IBM support.
<wsdl:service name="Test-Service">
<wsdl:port name="Test-Service" binding="impl:TestSoapBinding">
<wsdlsoap:address
location="http://localhost:9080/TestHello/Test"/>
</wsdl:port>
</wsdl:service>
When invoked to generate client development code, WSDL2Java generates an
interface that extends the javax.xml.rpc.Service interface, and that maps to the
WSDL service. In this example, that interface is called com.test.TestService,
named after the WSDL service.
When emitting client deployment code, WSDL2Java emits a WebSphere
proprietary class that implements this interface. The convention used in naming
this class is the name of the interface mapped to WSDL service (again, in this
32
import com.test.Test;
import com.test.TestServiceLocator;
try {
Test stub = new TestServiceLocator().getTestService();
...
Test is the service endpoint interface (what will actually be returned is an instance
of another WSDL2Java-generated deployment class, TestSoapBindingStub,
which implements Test).
Examine the javax.xml.rpc.ServiceException stack trace in Example 27.
Example 27 javax.xml.rpc.ServiceException stack trace
33
com.test.Test _stub =
(com.test.Test) getStub(
testServicePortName,
(String)
getPort2NamespaceMap().get(testServicePortName),
com.test.Test.class,
"com.test.TestSoapBindingStub",
portAddress.toString());
getStub() is implemented in a parent class of TestServiceLocator,
com.ibm.ws.webservices.multiprotocol.AgnosticService. There is never any need
for you to examine internal engine code. However, for the purposes of
understanding this problem, it is meaningful to know that the second parameter
that AgnosticService.getStub() takes is the namespace of the WSDL port.
The way that getTestService() obtains that namespace is by calling the
getPort2NamespaceMap() method, implemented in TestServiceLocator:
...(String) getPort2NamespaceMap().get(testServicePortName)...
The testServicePortName variable is declared and initialized earlier in the class:
private java.lang.String testServicePortName = "Test-Service";
Notice how the string Test-Service matches the value of the WSDL port, defined
as a child of the WSDL service:
<wsdl:port name="Test-Service" >
Now look at the implementation of the getPort2NamespaceMap() method in
Example 29.
Example 29 getPort2NamespaceMap()
34
return port2NamespaceMap;
}
getPort2NamespaceMap() creates a map that uses the WSDL port as a key and
namespace as a value. It returns this map. Recall that getTestService() invokes
a get() on this returned map, passing in testServicePortName as a key to get the
namespace value:
...(String) getPort2NamespaceMap().get(testServicePortName)...
But remember that testServicePortName resolves to "Test-Service", yet the
getPort2NamespaceMap() method never added a mapping using "Test-Service"
as a key. It used the string "TestService" instead:
port2NamespaceMap.put(
"TestService",
"http://schemas.xmlsoap.org/wsdl/soap/");
Therefore, the returned namespace value is null, which is why the Web services
engine throws the javax.xml.rpc.ServiceException: WSWS5055E: Cannot find
a Service for namespace null exception.
The fix for the APAR corrects WSDL2Java so that it generates the
wsdl_serviceLocator class to use the XML QName local part of the WSDL port.
<wsdl:operation name="testHello">
<wsdl:input name="testHelloRequest" message="intf:testHelloRequest"/>
</wsdl:operation>
35
A Web service client developed from such a WSDL and running in the
WebSphere environment would send a message like that shown in Example 31.
Example 31 Message with empty SOAP Body
<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:Header/>
<soapenv:Body/>
</soapenv:Envelope>
Notice that the SOAP Body element is empty.
36
Also remember the input message, testHelloRequest? It does not contain a part:
<wsdl:message name="testHelloRequest"/>
Basic Profile Version 1.1: The Basic Profile Version 1.1 says this on the
matter of child elements in document/literal messages:
4.7.8 Child Element for Document-Literal Bindings
WSDL 1.1 is not completely clear what, in document-literal style bindings,
the child element of soap:Body is.
R2712 A document-literal binding MUST be serialized as an ENVELOPE
with a soap:Body whose child element is an instance of the global element
declaration referenced by the corresponding wsdl:message part.
In order for the request SOAP Body to contain any elements, the input message
must contain a part that references an element, globally defined in the schema.
See Example 33.
Example 33 Input message, now with a part
<wsdl:message name="testHelloRequest">
<wsdl:part name="parameters" element="impl:testHello"/>
</wsdl:message>
The testHello element is declared as in Example 34.
Example 34 testHello element
<element name="testHello">
<complexType>
<sequence>
<element name="name" nillable="true" type="xsd:string"/>
</sequence>
</complexType>
</element>
Remember that elements can be declared using anonymous complexTypes. The
complexType definition specifies that element testHello contains a child element,
called name.
It is also important to understand that changing the WSDL often necessitates
changing the Java code including development and deployment code. In this
particular example, a change to the input message changed the signature of the
mapped Java method, testHello(), and a slight change in the implementation in
both client and service applications. Web services deployment code also had to
be re-generated.
37
Example 35 shows the ensuing SOAP request message after the applications
were re-built and re-deployed.
Example 35 SOAP request message with SOAP Body containing child elements
<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:Header/>
<soapenv:Body>
<p585:testHello xmlns:p585="http://test.com">
<name>Wendy</name>
</p585:testHello>
</soapenv:Body>
</soapenv:Envelope>
In this example, the document/literal request message has an empty SOAP Body
because the input message has no part. However, this cause and effect pattern
is not limited to just the request, but also to the response. In other words, if the
output message similarly contains no part, then the response message's SOAP
Body will also not contain any elements.
Support preparation
If changing the WSDL and the application does not resolve the problem, collect
the following data for use by IBM support:
Complete test case, including WSDL and Java source
Web services trace that reflects the sending of the message with the empty
SOAP body
Go to The next step on page 47 for information about performing an online
search of Web services problems and for a list of useful technical articles. If
these resources do not help you resolve the problem, contact IBM support.
38
<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:Header/>
<soapenv:Body>
<p585:testHello xmlns:p585="http://test.com">
<p585:name>Wendy</p585:name>
</p585:testHello>
</soapenv:Body>
</soapenv:Envelope>
This request is sent to the target Web service testHello, running on WebSphere.
The testHello Web service operation is defined in the WSDL as shown in
Example 37.
Example 37 testHello Web service operation
<wsdl:operation name="testHello">
<wsdl:input name="testHelloRequest"
message="impl:testHelloRequest"/>
<wsdl:output name="testHelloResponse"
message="impl:testHelloResponse"/>
</wsdl:operation>
39
<wsdl:message name="testHelloRequest">
<wsdl:part name="parameters" element="impl:testHello"/>
</wsdl:message>
Now look at the element that the message part refers to. testHello is declared in
the WSDL's embedded schema. See Example 39.
Example 39 testHello global element
<schema targetNamespace="http://test.com"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<element name="testHello">
<complexType>
<sequence>
<element name="name" nillable="true" type="xsd:string"/>
</sequence>
</complexType>
</element>
</schema>
testHello is a global element. It is declared immediately under the schema
element, and not within a complexType definition. Therefore, it exists in that
schema's target namespace, http://test.com. The testHello element appears
correctly, according to the schema it is declared in:
...<p585:testHello xmlns:p585="http://test.com">...
Notice that testHello is prefixed with the string p585 and that p585 is set to
namespace http://test.com.
40
<p585:testHello xmlns:p585="http://test.com">
<p585:name>Wendy</p585:name>
</p585:testHello>
...
Notice that name is qualified, too, with prefix p585 that resolves to namespace
http://test.com.
Note: The W3C recommendation, "XML Schema Part 0: Primer Second
Edition," says the following about qualifying local elements:
Qualification of local elements and attributes can be globally specified by a
pair of attributes, elementFormDefault and attributeFormDefault, on the
schema element, or can be specified separately for each local declaration
using the form attribute. All such attributes' values may each be set to
unqualified or qualified, to indicate whether or not locally declared
elements and attributes must be unqualified.
In this case, name is a local element because it is not declared within the context
of the schema it is declared within a complexType definition. Because the
schema in which name is declared does not explicitly have the
elementFormDefault attribute, the default of unqualified is assumed. Therefore,
name should not be qualified in the SOAP message.
41
Example 41 shows how you should not specify name (qualified with p585).
Example 41 Incorrect specification of name
<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:Header/>
<soapenv:Body>
<p585:testHello xmlns:p585="http://test.com">
<p585:name>Wendy</p585:name>
</p585:testHello>
</soapenv:Body>
</soapenv:Envelope>
Example 42 shows the correct way to specify name (unqualified).
Example 42 Correct specification of name
<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:Header/>
<soapenv:Body>
<p585:testHello xmlns:p585="http://test.com">
<name>Wendy</name>
</p585:testHello>
</soapenv:Body>
</soapenv:Envelope>
42
Alternatively, the use of a default namespace (Example 43) is another way that
the message can be structured so that name is in the wrong namespace.
Example 43 Incorrect specification using the default namespace
<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:Header/>
<soapenv:Body>
<testHello xmlns="http://test.com">
<name>Wendy</name>
</testHello>
</soapenv:Body>
</soapenv:Envelope>
The appearance of the xmlns= attribute on parent element testHello indicates
that the default namespace is http://test.com. Therefore, its child element name
inherits this default namespace. But again, according to the schema, name does
not have a namespace.
Instead, the message should appear as shown in Example 44 to be valid.
Example 44 Correct specification using the default namespace
<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:Header/>
<soapenv:Body>
<testHello xmlns="http://test.com">
<name xmlns="">Wendy</name>
</testHello>
</soapenv:Body>
</soapenv:Envelope>
xmlns="" indicates that name exists in no default namespace at all.
The only way to resolve the WSWS3047E error is to fix the message so that local
elements are qualified or unqualified, according to the schema. Additionally,
whether elements are qualified using a prefix or default namespace, the
43
namespace must be the correct one. You should work with the Web services
vendor to accomplish this task.
Support preparation
If you still observe the WSWS3047E error after fixing the message, collect the
following data for use by IBM support:
Capture of SOAP request and response. These can be obtained using the
TCPMonitor tool. (See Collecting trace data with TCPMonitor on page 45.)
Web services engine trace reflecting the "org.xml.sax.SAXException:
WSWS3047E: Error: Cannot deserialize element <element_name> of bean
<bean_name>" error. See Enabling the Web services trace on page 46 for
information about collecting the trace.
Complete test case. If you cannot provide the test case, then the WSDLs with
all referenced schema files are needed.
Go to The next step on page 47 for information about performing an online
search of Web services problems and for a list of useful technical articles. If
these resources do not help you resolve the problem, contact IBM support.
44
45
where TCPMonitor is running and the listen port specified in the TCPMonitor
Listen Port text field.
For example, consider the following case:
The Web service provider is accessible at endpoint
http://hostA:9080/Hello/HelloWorld.
TCPMonitor is running on hostB and is listening on port 9085.
To redirect the client request through TCPMonitor, point the client to endpoint
http://hostB:9085/Hello/HelloWorld.
5. Invoke the client. You should observe both the SOAP request and response
in the two panels of the GUI. The messages can be saved to a text file by
clicking the Save button.
46
47
48
Explanation of messages
The WebSphere information center has a message reference that provides
message text and user response suggestions for each message prefix type.
The information center is at:
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp
Navigate to WebSphere package Reference Messages
message_prefix.
49
Contact IBM
If these steps do not resolve your problem, gather additional information and
raise a problem record with IBM. If instructions on what to gather were not
included for your particular problem area, use the MustGather information for
your problem to collect documentation: MustGather: Web services engine and
tooling problems for WebSphere Application Server V6.1, V6, V5.1 and V5.
http://www-1.ibm.com/support/docview.wss?rs=180&context=SSCR4XC&q1=Must
GatherDocument&uid=swg21198363&loc=en_US&cs=utf-8&lang=en
The following URL contains a list of all of the MustGather documentation for Web
services problems involving the Web services engine, WSIF, or Web services
gateway:
http://www-1.ibm.com/support/search.wss?rs=180&tc=SSEQTP&tc1=SSCR4XC&q=
MustGatherDocument
The following URL contains a list of the MustGather documentation for
WS-Security:
http://www-1.ibm.com/support/search.wss?rs=180&tc=SSEQTP&tc1=SSCNPY4&q=
MustGatherDocument
50
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information about the products and services currently available in your
area. Any reference to an IBM product, program, or service is not intended to state or imply that only that
IBM product, program, or service may be used. Any functionally equivalent product, program, or service that
does not infringe any IBM intellectual property right may be used instead. However, it is the user's
responsibility to evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document.
The furnishing of this document does not give you any license to these patents. You can send license
inquiries, in writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer
of express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this publication at
any time without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without
incurring any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm
the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on
the capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrates programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the
sample programs are written. These examples have not been thoroughly tested under all conditions. IBM,
therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy,
modify, and distribute these sample programs in any form without payment to IBM for the purposes of
developing, using, marketing, or distributing application programs conforming to IBM application
programming interfaces.
Copyright International Business Machines Corporation 2007. All rights reserved.
Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by
GSA ADP Schedule Contract with IBM Corp.
51
Redpaper
Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
Redbooks (logo)
i5/OS
z/OS
IBM
Rational
WebSphere
Other company, product, or service names may be trademarks or service marks of others.
52