This file contains a comprehensive list of limitations,
both permanent and temporary, that affect web services.
The limitations that you may encounter while working with
web services are divided into the following sections:
Problems encountered when
using a secured WebSphere Application
Server
You may encounter the following error message: SSLSocketFactory
error message: java.net.SocketException: java.lang.ClassNotFoundException:
Cannot find the specified class com.ibm.websphere.ssl.protocol.SSLSocketFactory
Before
using the Web Services Explorer, generating sample JSPs, creating
a web service or client from an HTTPS WSDL file, or deploying an Axis
web service, you must configure the workbench to communicate with
a server using Secure Sockets Layer (SSL). Information about this
task can be found here: Problems working with a secured server using SSL connections.
You may encounter the following error message: Error
opening socket: javax.net.ssl.SSLHandshakeException: unknown certifcate
If
you want to use the web services wizard to retrieve an HTTPS WSDL
or if you want to use the web services Explorer against a secured WebSphere® Application Server,
you must complete the steps in: Configuring the IBM® JRE
to talk to a secured WebSphere Application
Server
Problems encountered when
using the web services wizards
- If you click Cancel part
way through any of the web services wizards, you may be left with
files generated by the wizards in your workspace, and web service
entries in the deployment descriptors. These files should be deleted
manually after you close the wizard.
- web service wizards fail to publish EARs:
Problem: When a remote
server is created using the stub runtime the EAR will not get published.
Cause:
The web service wizard has no way to find out whether a server can
be started or not.
Solution: In any perspective where the Servers
view is available, right-click the remote server and select Add
and Remove Projects. Select the project and add it to
the server.
- web service wizards unable to consume the chosen project type:
Problem:
If you attempt to run the web service wizards on and EAR that contains
a J2EE application client project with the Install service
on server option selected, or an EJB project that does
not contain an EJB, the wizard will not allow you to generate the
web service.
Cause: The web service wizards perform a check
to ensure that they can consume the type of project selected on page
three of the wizard. If they cannot, the wizard prevents you from
continuing.
Solution: If you cancel out of the wizard and rerun
with Install service on server not selected,
or add an EJB to the EJB project, you will be able to progress in
the wizard.
- If a WSIL
file is selected in the workspace and then the web services wizard
is launched, the wizard will state that the selection is invalid.
This is because a WSDL file needs to be selected from the WSIL file.
To resolve this, click Browse in the web services
wizard to select a specific WSDL file.
- The web services
wizard may produce an error during creation of a web service if the
name of the target Web project includes non-latin-1 characters. The
problem occurs because the web services code generators calculate
HTTP URLs based on the project name, and non-Latin-1 characters are
not permitted in HTTP URLs. To resolve this, use project names that
contain only latin-1 characters.
- If you have
more than one EAR project in the workspace, and you select an Enterprise Java™ Bean in an EJB project and
launch the web service wizard the selected Enterprise bean may not
be selected when the wizard launches. In the Select Service Implementation
dialog box the EAR project that is selected will be the first EAR
in the workspace alphabetically, not the EAR that the EJB project
containing the bean is associated with. To resolve this in the Select
Service Implementation dialog box, manually select the desired EAR
project.
- When you select
to monitor web services traffic on the first page of the web services
wizard, occasionally the TCP/IP Monitor view will not display automatically.
You can open the view manually by selecting . The request and response for the
web service will be shown on that view.
- The JAX-RPC bottom-up (BU) web services
generation wizard generates a NullPointerException when it is used
on a Java bean in the same target JEE1.3/Web2.3 web project.
Problem:
A NullPointerException is raised when you use the JAX-RPC bottom-up
(BU) web services generation wizard in RAD/WAS on a Java bean in the
same target JEE1.3/Web2.3 web project.
Cause: The Use
WSDL 1.1 Mime Attachments exclusively
option on the Service Endpoint Interface Selection was not selected.
For J2EE 1.3 Web Services and Clients, RAD retains the WAS v5.1.1
emitter as the com.ibm.websphere.webservice.rt.v5.1.1 plug-in. When
the Use WSDL 1.1 Mime Attachments exclusively option
on the Service Endpoint Interface Selection is not selected, the mime
style is set to swaRef. Although this setting is
accurate since emailSend() is sending an application
or PDF file, the WAS v5.1.1 emitter that is retained by RAD for J2EE
1.3 Web Services and Clients does not support swaRef. swaRef is
no longer supported on WAS v5.x.
Solution: To prevent the NullPointerException,
ensure that the Use WSDL 1.1 Mime Attachments exclusively
option on the Service Endpoint Interface Selection is selected.
Problems encountered when using WebSphere JAX-WS runtime environment
and JAXB
Problems encountered when
using WebSphere JAX-RPC
runtime environment
- It is possible to
create WSDL documents that, when regenerated into Java using the web services wizards or WSDL2Java
tool, create uncompilable output. This is because the JAX-RPC mapping
from Java to WSDL is not reversible.
If you encounter this problem, check the WSDL file and modify it as
necessary to get the desired results, or choose to define custom namespace
to package mappings.
- The IBM WebSphere JAX-RPC runtime environment cannot
handle Java beans that use the
default Java package. The result
is that an exception will be thrown during server startup and the
web service will not work at run time.
- If creating a web services client using the WebSphere JAX-RPCruntime environment, the
client's deployment descriptors are not available in the Universal
Test Client. As a result, JNDI lookups of the client proxy do not
work in the Universal Test Client. To use the UTC you must construct
and use the Locator class, or use the generated Proxy class with useJNDI set
to false (which internally constructs and uses the Locator). Note
that if client-side deployment descriptors are not processed then
certain metadata such as WS-Security and Handlers will not be available.
An example of such client configuration is security. Use the sample
JSPs instead of the Universal Test Client to test the proxy.
- WSDL import: WSDL
import statement can only have absolute URLs or relative URLs in the
same directory. For example, relative import in the following form
is not supported: <import namespace="http://someNamespace/"
location="../someFile.wsdl"/>
Problems with using Apache Axis runtime
environment
- The web services Ant tasks targeting the Axis runtime handle the
generation of web services, but not the deployment of them. As a result,
Axis web services created using the Ant tasks will not be reachable
on the running server until you manually deploy your services using
the Apache Axis native "AdminClient" utility. Deploy the generated
deploy.wsdd (this can be found in subdirectories under the WebContent/WEB-INF
directory of the Web project) to Axis manually using the Axis AdminClient
tool . Refer to the "Using the AdminClient " section of the Axis 1.3
User's Guide for more detail.
- The Axis run-time environment has a limitation in its ability
to handle Java classes with
non-conventionally named identifiers. After the WSDL is generated
from the original bean, the operation names in the WSDL are correct.
However, after Axis generates the bean from the WSDL file, the method
name is changed to lowercase to support Java conventions.
The web services wizards discard the generated skeleton and use the
original bean. This causes a mismatch between the bean name and the
WSDL file.
For example, if the bean method name is BodyMassIndex,
the Axis deployment descriptor operation name would be bodyMassIndex (where
'b' is lowercase) to make it follow standard Java naming conventions.
There are two possible
solutions:- Change the original bean's method name.
- Modify deploy.wsdd and redeploy the service.
This is not a recommended solution unless you are familiar with the
Axis deployment tools.
- If
you create an Axis web service or web service client in a project
migrated from RAD v6.x, new files will be generated and new JARs will
be copied into the WebContent/WEB-INF/lib directory of the Web project.
Generated code for any pre-existing web services may no longer compile
correctly due to the updates made to the JARs in WEB-INF/lib. You
can safely ignore those compile errors or delete the files.
Limitations when creating a web
service client
When deploying a web service client to an EJB project, the
proxy configuration page will include a combo box that lets you pick
which EJB this web service client will be scoped to. This is a requirement
defined by JSR-109 where the component-name of a component-scoped-refs element
must match the ejb-name of an EJB in the module.
When
there is at least one EJB in the project, no errors will occur. However,
if there are no EJBs in the project, the combo box in the proxy configuration
page will be editable and have a default value equal to the service
name from the WSDL suffixed by "EJB". Furthermore, the client wizard
will display a warning dialog indicating that the deployment is incomplete
because the web services client is not scoped to an existing EJB.
The user can fix this by creating an EJB with the same name as the
component-name used in webservicesclient.xml.
However,
if you choose to abort the client creation by canceling out from the
wizard, the wizard will not remove the incomplete component-scoped-refs from webservicesclient.xml.
You should remove the incomplete component-scoped-refs manually
before redeployment.
Limitations of the web service sample
JSPs
- web service sample JSPs
have no support for methods that take in arrays or collections as
parameters, and such methods will be omitted from the sample JSP's
Methods pane.
Web Services Explorer problems
Private UDDI Registry problems
- Publisher assertions
of the Private UDDI Registry may be visible to all businesses in the
registry. A business may see publisher assertions that are associated
with the business itself, for example, the business's key is neither
the from keys nor the to keys of the publisher assertions.
- When the Unit
Test UDDI registry is configured with the Cloudscape database backend,
UDDI find by name methods will perform case-sensitive searches by
default. This goes against the UDDI specification and is a limitation.
Using the Universal Test Client
When launching
the Universal Test Client from the web services wizard, the JNDI Provider
URL is set to the default WebSphere port
of 2809. If you have changed the port number, you would not be able
to search the JNDI directory. If you try to access the JNDI directory,
you will get the following error: IWAD0403E Could not
construct the JNDI tree: Caught CORBA.COMM_FAILURE when resolving
initial reference=WsnNameService
The workaround
is:
- Double-click the server you are using. This will bring up the
server properties.
- Select the ports tab.
- Copy the Orb bootstrap port.
- Open the JNDI properties window in the Universal Test Client.
- Paste the bootstrap port into the Provider URL text iput box.
Problems when using web services
command line
- Directory
with space: Avoid running WSDL2WebService from a directory
containing a space in the directory name. Otherwise, the compile.bat
(or compile.sh on Linux) that
is generated does not compile.
- After running
EJB2WebService to create an EJB web service, the generated EAR cannot
be run on Unit Test Environment or remote server if the splitWsdl
option is used. The workaround is to copy the whole WSDL directory
under META-INF of the EJB project to WEB-INF of the router Web project.
- After running
WSDL2WebService to create an EJB web service with a WSDL that has
local import in it, the generated EAR cannot be run on Unit Test Environment
or remote server. The workaround is to copy the whole WSDL directory
under META-INF of the EJB project to WEB-INF of the router Web project.
- After you import
an EAR containing an EJB Client generated by the command line tools
using J2EE 1.4 into the workspace, you will see compilation errors.
To fix the errors, right-click the EJB project and select Properties.
Go to Java Build Path, and select the Libraries tab.
Remove the EJBClientProject/imported_classes(class folder) entry.
Add class folder EJBServiceClient/imported_classes/Meta-inf/classess.
Click OK.
- After you import
an EAR containing an Application Client generated by the command line
tools using J2EE 1.4 into the workspace, you will get a ClassNotFoundException error
when running the client. To fix the errors, right-click the Application
Client project, select Properties. Go to Java
Build Path, and select the Libraries tab.
Remove the ApplicationClientProject/imported_classes(class
folder) entry. Add class folder ApplicationClientProject/imported_classes/Meta-Inf/classess.
Click OK.
- The
Web Services Ant tasks targetting the Axis runtime handle the generation
of web services, but not the deployment of them. As a result, Axis
web services created using the Ant tasks will not be reachable on
the running server until you manually deploy your services using the
Apache Axis native "AdminClient" utility. Deploy the generated deploy.wsdd
(this can be found in subdirectories under the WebContent/WEB-INF
directory of the Web project) to Axis manually using the Axis AdminClient
tool . Refer to "Using the AdminClient " section of the Axis 1.3
User's Guide for more detail.