Web Services Invocation Framework troubleshooting tips

 

+

Search Tips   |   Advanced Search

 

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

For information about resolving WebSphere-level problems, Diagnosing and fixing problems.

To resolve SIF-related problems, you can use standard trace and logging facilities. Check for error messages in the console and in the appserver's log files. Enable the appserver debug trace to provide a detailed exception dump.

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

Handcrafted WSDL can cause numerous problems. To help ensure that your WSDL is valid, use a tool such as WebSphere Studio Application Developer (WSAD) to create your Web service.

Define transport mechanism

For the JMS, check that you have set up the JNDI correctly, and created the necessary connection factories and queues.

For SOAP, make sure that the deployment descriptor file dds.xml is correct - preferably by creating it using WSAD or similar tooling.

Create client - Java code

Follow the correct format for creating...

  • WSIF service
  • port
  • operation
  • message

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 your 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

Verify...

/properties/server.policy

...has the correct security settings.

WSIF setup

Check that the wsif.properties file is correctly set up.

Run client

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

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

Here is a set of tips to help you 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:

You might also try the following checks:

 

Your Web service EAR file does not install correctly onto the appserver.

It is likely that the EAR file is badly formed. Verify the installation by completing the following steps:

 

There is a permissions problem or security error.

Check that...

/properties/server.policy

...has the correct security settings.

 

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: 

    <isd:provider type="java" scope="Application" ......

You 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 your 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 may not be called while parsing.; nested exception is:

[SOAPException: faultCode=SOAP-ENV:Client; msg=Parsing error, response was:

FWK005 parse may not be called while parsing.; 
        targetException=org.xml.sax.SAXException:
FWK005 parse may not be called while parsing.]

 

Use the same names for JMS messaging queues and queue connection factories that run on appservers on different machines can cause JNDI lookup errors.

You should not use the same names for messaging queues and queue connection factories that run on appservers on different machines, because WSIF always looks 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 appserver 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.

 

A JAX-RPC client running on WAS V5 uses SOAP over JMS to invoke a Web service running on a Version 5 appserver. No user ID or password is required on the target MQ Series queue. After the appserver is migrated to V6, and using V6 default messaging, client requests fail because basic authentication is now enabled.

The problem appears as a log message:

SibMessage W [:] CWSIT0009W: A client request failed in the appserver with endpoint <endpoint_name> in bus <your_bus> with reason: CWSIT0016E: The user ID null failed authentication in bus <your_bus>.

To fix, see...

After you migrate an appserver to WAS V6, existing Web services clients can no longer use SOAP over JMS to access services hosted on the migrated server.

 

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

This restriction is due to the fact that 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 your Web service or the WSIF default SOAP provider as described in WSIF SOAP provider: working with legacy applications.

Sub-topics


WSIF (Web Services Invocation Framework) messages
WSIF - Known restrictions

 

Related tasks


Enable security for WSIF
Trace for WSIF
Install WSIF

 

Related Reference

wsif.properties file - Initial contents