+

Search Tips   |   Advanced Search

Web Services Invocation Framework troubleshooting tips

A set of specific tips to help troubleshoot problems you experience with the Web Services Invocation Framework (WSIF).

This topic references one or more of the application server log files. As a recommended alternative, we can configure the server to use the High Performance Extensible Logging (HPEL) log and trace infrastructure instead of using SystemOut.log , SystemErr.log, trace.log, and activity.log files on distributed and IBM i systems. We can also use HPEL in conjunction with the native z/OS logging facilities. If we are using HPEL, we can access all of the log and trace information using the LogViewer command-line tool from the server profile bin directory. See the information about using HPEL to troubleshoot applications for more information on using HPEL.

For information about resolving WebSphere Application Server-level problems, see Diagnosing problems (using diagnosis tools).

To identify and resolve WSIF-related problems, we can use the standard WebSphere Application Server trace and logging facilities. If we encounter a problem that you think might be related to WSIF, we can check for error messages in the WAS administrative console, and in the application server stdout.log file. We can also enable the application server debug trace to provide a detailed exception dump.

A list of the WSIF runtime system messages, with details of what each message means, is provided in WSIF (Web Services Invocation Framework) messages.

A list of the main known restrictions that apply when using WSIF is provided in WSIF - Known restrictions.

Here is a checklist of major WSIF activities, with advice on common problems associated with each activity:

Create service

A handcrafted WSDL file can cause numerous problems. To help ensure that the WSDL file is valid, use a tool such as WebSphere Studio Application Developer (WSAD) to create the web service.

A handcrafted WSDL file can cause numerous problems. To help ensure that the WSDL file is valid, use a tool such as WebSphere Development Studio for System i (WDS) to create your web service.

Define transport mechanism

For the Java Message Service (JMS), check that we have set up the JNDI correctly, and created the necessary connection factories and queues.

For SOAP, verify the deployment descriptor file dds.xml is correct - preferably by creating it using WebSphere Studio Application Developer (WSAD) or similar tooling.

For SOAP, verify the deployment descriptor file dds.xml is correct - preferably by creating it using WebSphere Development Studio for System i (WDS) or similar tooling.

Create client - Java code

Follow the correct format for creating a WSIF service, port, operation and message. For examples of correct code, see Example: Use WSIF to invoke the AddressBook sample web service dynamically.

Compile code (client and service)

Check that the build path against code is correct, and that it contains the correct levels of JAR files.

Create a valid EAR file for the service in preparation for deployment to a web server.

Deploy service

When you install and deploy the service EAR file, check carefully any messages given when the service is deployed.

Server setup and start

Make sure the WAS server.policy file (in the /properties directory) has the correct security settings. For more information, see Secure WSIF.

WSIF setup

Check that the wsif.properties file is correctly set up. For more information, see wsif.properties file - Initial contents.

Run client

Either check that we have defined the class path correctly to include references to the client classes, WSIF JAR files and any other necessary JAR files, or (preferably) run the client by using the WAS launchClient tool.

Either check that we have defined the class path correctly to include references to the client classes, WSIF JAR files and any other necessary JAR files, or (preferably) run the client using the WAS launch client tool. For more information about this tool, refer to the Running application clients chapter of the Develop and deploying applications PDF book.

Here is a set of tips to help troubleshoot commonly-experienced problems:


No class definition errors received when running client code

This problem usually indicates an error in the class path setup. Check that the relevant JAR files are included.


Cannot find WSDL error

Some likely causes are:

We might also try the following checks:


Web service EAR file does not install correctly onto the application server

The EAR file is probably badly formed. Verify the installation by completing the following steps:


Permissions problem or security error

Check that the WAS server.policy file (in the /properties directory) has the correct security settings. For more information, see Secure WSIF.


Use WSIF with multiple clients causes a SOAP parsing error

Before you deploy a web service to WebSphere Application Server, decide on the scope of the web service. The deployment descriptor file dds.xml for the web service includes the following line:

We can set the Scope attribute to Application or Session. The default setting is Application, and this value is correct if each request to the web service does not require objects to be maintained for longer than a single instance. If Scope is set to Application the objects are not available to another request during the execution of the single instance, and they are released on completion. If the web service needs objects to be maintained for multiple requests, and to be unique within each request, set the scope to Session. If Scope is set to Session, the objects are not available to another request during the life of the session, and they are released on completion of the session. If scope is set to Application instead of Session, you might get the following SOAP error: 

SOAPException: SOAP-ENV:ClientParsing error, response was:
FWK005 parse might not be called while parsing.;
nested exception is:
 [SOAPException: faultCode=SOAP-ENV:Client; msg=Parsing error, response was:
 FWK005 parse might not be called while parsing.;          targetException=org.xml.sax.SAXException:
FWK005 parse might not be called while parsing.]


JNDI lookup errors occur when using the same names for JMS messaging queues and queue connection factories that run on application servers on different machines

You should not use the same names for messaging queues and queue connection factories that run on application servers on different machines, because WSIF always checks first for JMS destinations locally, and only uses the full JNDI reference if it cannot find the destination locally. For example, if you run a web service on a remote machine, and have an application server running locally that uses the same names for the messaging queues and queue connection factories, then WSIF will find and use the local queues even if the remote JNDI destination is provided in full in the WSDL service definition.


JAX-RPC client running on WebSphere Application Server Version 5 uses SOAP over JMS to invoke a web service running on a Version 5 application server

JAX-RPC client running on WebSphere Application Server Version 5 uses SOAP over JMS to invoke a web service running on a Version 5 application server. No user ID or password is required on the target MQ Series queue. After the application server is migrated to Version 6, and using Version 6 default messaging, client requests fail because basic authentication is now enabled.

The problem appears as a log message:

For the steps to take to resolve the problem, see the following service integration technologies troubleshooting tip: Migrate a Version 5.1 application server to WAS v7 or later


The current WSIF default SOAP provider (the IBM Web Service SOAP provider) does not interoperate fully with services that are running on the former (Apache SOAP) provider

This is because the IBM Web Service SOAP provider is designed to interoperate fully with a JAX-RPC compliant web service, and Apache SOAP cannot provide such a service. To enable interoperation, modify either the web service or the WSIF default SOAP provider as described in WSIF SOAP provider: working with existing applications.


Related tasks

  • Tracing and logging WSIF
  • Secure WSIF
  • Use High Performance Extensible Logging to troubleshoot applications

  • WSIF (Web Services Invocation Framework) messages
  • WSIF - Known restrictions
  • wsif.properties file - Initial contents Reference topic