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:
Supported software and specifications
The
Web Services Explorer supports the following Web browsers:
- Microsoft® Internet Explorer 6.0 or higher
- Mozilla 1.2.1 or higher
If you are launching the WORF test environment outside the workbench
using Mozilla, a Mozilla version of at least 1.3.1 is recommended. Output
from invoking your web service as well as description files may not be rendered
correctly in earlier versions of the Mozilla browser.
Problems encountered when using the
Web Services wizards
- If you specify an empty
EAR (an EAR with no modules) when creating your Web service, exceptions or
errors may result. It is recommended that you create at least one module with
an EAR that you are going to select when creating a Web service using the
wizards, or that you allow the wizards to create the EAR for you.
- If you select to customize
the namespace to package or package to namespace mapping for your Web service,
and then click Finish on the page of the wizard that
allows you to customize the mapping, your customized mappings will not be
used. This error only occurs when you click Finish on
that particular page. If you click Next to proceed
to the next page of the wizard and then click Finish your
custom mappings will be processed.
- 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 J2EE deployment
descriptors. These files should be deleted manually after you close the wizard.
Problems encountered when using WebSphere run-time
environment
- The IBM® WebSphere Web
service run-time 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.
- When creating Web service from Java bean
or EJB using the WebSphere run-time environment, do not use complex types
beans with package name that starts with Java primitive types (such as int, float,
double). Otherwise, the schema of the generated WSDL file might incorrectly
treat the complex type as a Java primitive type.
- You cannot mix SOAP encoding and
literal encoding for RPC style messages. However, this is the kind of WSDL
document that DADX will generate. Therefore, a WebSphere client
can not be properly created from a WSDL file which was generated for a DADX
Web service using RPC. To counteract this problem, create a DADX Web service
using DOC style. The WebSphere run-time environment can create
a client from this WSDL without a problem. To use DOC style DADX Web services,
set the useDocumentStyle parameter in the group.properties file
for the DADX group to true. This can also be done through the DADX group configuration
wizard.
- When creating a Web service from
a Java bean
or EJB, if the Java or EJB implementation has references to Java classes
that are located in different packages, then the generated WSDL, more specifically,
the <schema> sections of the WSDL file, may have missing <import> statements. Note:
this only affects Web services targeted to WebSphere Application Server v5.x - it does
not affect Web services using WebSphere Application Server v6.
- When generating a Java or
EJB skeleton from a WSDL file, if the WSDL file you use contains an XML type
that does not have a standard JAX-RPC mapping (for example, a <choice>
group), the generated skeleton implementation does not create the corresponding javax.xml.soap.SOAPElement correctly.
As a result, the Web service may return malformed SOAP responses.
The following
may fix this problem:
- Open the implementation class.
- Go to the line where the SOAPElement is instantiated (should look similar
to the following:createSOAPElement("http://schems.ibm.com/wswrapper",">D"
- Remove the > character.
- Save the it and restart the EAR project.
Note: this only affects Web services targeted to WebSphere Application
Server v5.x - it does not affect Web services using WebSphere Application
Server v6.
- After a Web service is deployed on
the WebSphere run-time
environment, if you change one of the classes used by the Web service, the
changes might not get refreshed and you may get a ClassCastException in the
server console. If that happens, right-click on the server in the Servers
view, select Restart project, then select the EAR containing
the project that has the classes that have changed. Note: this only
affects Web services targeted to WebSphere Application Server v5.x - it does
not affect Web services using WebSphere Application Server v6.
- If creating a Web services client using the WebSphere run-time
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.
- Array not supported in
RPC/literal: When creating a RPC/literal service, the method signature
cannot contain an array in it. If it does, the service cannot be invoked with
the generated client code. There is currently no workaround for this problem.
Please try to use document/literal or RPC/encoded if possible. Note:
this only affects Web services targeted to WebSphere Application Server v5.x - it does
not affect Web services using WebSphere Application Server v6.
- 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"/>
- When generating
skeleton EJB from WSDL file, if the WSDL file uses SOAP over JMS as transport,
ensure that the router project is an EJB project, not a Web project. Otherwise,
you will get an error message when go though Web service creation wizard.
- When generating
EJB skeleton, if a J2EE level 1.2 Web project is chosen as the Router project
in the Service Deployment Configuration page, make sure an existing level
1.1 EJB project contained in the same EAR as the Web project is chosen as
the EJB project before proceeding any further into the wizard. If you rely
on the wizard to automatically create the EJB project, the wizard will create
a level 2.0 EJB project, which is incompatible with a level 1.2 EAR and level
1.2 Web project.
- When generating EJB skeletons from
a WSDL file that uses types without any default JAX-RPC mappings, a run-time
environment exception will be returned when the user tries to invoke the Web
service. The problem is that the run-time has difficulties deserializing javax.xml.soap.SOAPElement.
java.xml.soap.SOAPElement is used when a type does not have any mappings associated
with it, as a result, is mapped as a document fragment. Note: this
only affects Web services targeted to WebSphere Application Server v5.x - it does
not affect Web services using WebSphere Application Server v6.
- When generating EJB skeletons from
a WSDL file with an operation that has inout parameters, errors will surface
when generating deployment codes for the EJB. The problem is that inout parameters
are mapped to javax.xml.rpc.holders.Holder classes. Since java.xml.rpc.holders.Holder
do not implement java.io.Serializable, they cause EJB deployment errors. Note:
this only affects Web services targeted to WebSphere Application Server v5.x - it does
not affect Web services using WebSphere Application Server v6.
Problems with using Apache Axis 1.0 run-time
environment
- Creating Web services
using the Apache Axis 1.0 run-time environment relies on the Java2WSDL and
WSDL2Java emitters provided in Axis 1.0. Support for document/literal and
document/literal (wrapped) is problematic in Axis 1.0, therefore the user
should use RPC/encoded when creating Web services using the Apache Axis 1.0
run-time environment.
- The file overwrite, folder creation and automatic file checkout preference
are not observed when creating Web services using the Axis run-time environment.
If a file already exists you will be prompted to overwrite; if you select Yes it
will be treated as if you selected Yes to all. Folder
creation is always allowed and automatic file checkout is never enabled.
- When using the
Apache Axis 1.0 run-time environment, the Axis emitters re-generate every
time all the server/client Java files, deploy.wsdd and undeploy.wsdd.
WSDL2Java for the service generation scenario will only generate the skeleton
implementation file if it does not already exist. If this implementation already
exists, it will not be overwritten.
- 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.
- When creating a Web service from
a Java bean
or EJB, if the Java or EJB implementation has references to Java classes
that are located in different packages, then the generated WSDL, more specifically,
the <schema> sections of the WSDL file, may have missing <import> statements.
- A Web service created with the Axis
run-time environment may not be interoperable. Axis does not respect the XSD
schema definition in WSDL files, therefore the responses generated by the
Web service may not match what is defined in the WSDL file. For example, if
you have complex types that contain a sequence of elements, the order of the
elements in the response message does not match the order defined in the WSDL
file.
- When generating a Java skeleton
from a WSDL file, if the WSDL file you use contains an XML type that does
not have a standard JAX-RPC mapping (for example, a <choice> group), the
generated skeleton implementation does not create the corresponding javax.xml.soap.SOAPElement correctly.
As a result, the Web service may return malformed SOAP responses.
The following
may fix this problem:
- Open the implementation class.
- Go to the line where the SOAPElement is instantiated (should look similar
to the following:createSOAPElement("http://schems.ibm.com/wswrapper",">D"
- Remove the > character.
- Save the it and restart the EAR project.
Permanent Limitations when using IBM SOAP run-time
environment
The IBM SOAP run-time environment should be use mainly for
backward compatibility reasons. It is strongly suggested that you use the
Web services wizard with the IBM WebSphere run-time environment for all production
purposes. When using the Web services wizard with the IBM SOAP run-time
environment, the user may run into the following permanent limitations:
- Generating a WSDL document from a Java bean
- char and
java.lang.Character require you to enter custom
mappings since default mappings from char or
java.lang.Character to WSDL XSD do not exist.
- The primitive wrapper types, java.lang.Boolean,
java.lang.Byte, java.lang.Short,
java.lang.Integer, java.lang.Long,
java.lang.Float, and java.lang.Double,
cannot co-exist with their corresponding individual primitive types boolean,
byte, short, int,
long, float, and
double, across all the input parameters of a
service bean. For example, a service bean in which java.lang.Integer and
int both appear anywhere as input parameter
types cannot be turned into a complete Web service. When an attempt is made
to use the Web Service wizard to create a Web service from this type of service
bean, a warning message will occur unless the methods containing the primitive
types or wrapper types are not selected in the Web Service Java Bean
Methods Page of the wizard. However, you must ensure these methods are not
selected the first time the Web Service Java Bean Methods page is encountered.
Going back to this page and clearing the problematic methods after having
seen the warning may produce an incomplete Web service. In this case, the
wizard should be restarted so that the proper method selections can be made
the first time the Web Service Java Bean Methods page is encountered.
- Multi-dimensional arrays are not
supported. An alternative in Java is to insert Java beans
in between the dimensions. For example, instead of MyType[][], the pattern
MyArray[] where MyArray has a property of type MyType[] will work.
- A method with an input argument list
containing a mixture of DOM Element and simple bean types requires the entry
of one or more custom mappings. The Web Services Definition Language (WSDL)
Version 1.1 specification supports one encoding style for all input parts
(parameters). The Simple Object Access Protocol (SOAP) Version 2.2 run-time
environment does not have default mapping support for DOM Element with SOAP
encoding for primitive types and beans with Literal XML encoding.
- When configuring a custom mapping,
if you try use serializer or deserializer class from the SOAP run-time environment
(that is, classes from package org.apache.soap.encoding.soapenc)
and receive the error "the selected serializer/deserializer class cannot be
loaded from this project", then soap.jar is
most likely not on your Web project build path. To correct the problem, cancel
the wizard, use the Web project properties dialog to add WS_installdir\wstools\eclipse\plugins\com.ibm.etools.webservice\run-time
environment\soap.jar to the build path of the web project,
then retry the Web service wizard.
- Custom mapping is not supported for
nested complex types. Although nested types will appear in the mapping page
of the wizard, custom mappings for those types will be ignored.
- When creating a Web service from
a Java class
whose interface contains an abstract Java type, the Web service Java to
XML Mappings page may incorrectly set the deserializer field for the abstract
type to org.apache.soap.encoding.soapenc.BeanSerializer.
This will fail at run-time environment since the deserializer code in the
BeanSerializer class will be unable to construct an instance of the abstract
type. To avoid this, choose the Custom mapping option for the type if necessary,
and change the deserializer field to the name of a class written to deserialize
the abstract type.
- The Web service tools currently do
not support the creation of Web services from Java Beans containing nested inner classes
(that is, inner classes defined within a top level class). To work around
this problem, you should move the inner classes to top level classes in seperate Java files.
- When creating a Web service from
a Java bean
that uses other Java Beans with properties of type Vector, Hashtable
or Map, XSD will be generated with complexTypes containing types "Vector"
and "Map" from the namespace "http://xml.apache.org/xml-soap". Because no
schema currently exists for this namespace, the XSD Validator will produce
errors and warnings like the following:
- Error src-resolve: Cannot resolve the name 'xsd2:Vector' to a(n) type
definition component.
- Warning src-import.0: Failed to read imported schema document 'null'.
These errors and warnings will not interfere with the correct processing
of the WSDL and XSD by the Web Services wizards. The "Map" and "Vector" types
will be correctly mapped to their Java counterparts. Note that other vendors
may have difficulties processing WSDL or XSD containing these types because
http://xml.apache.org/xml-soap is not a namespace recognized by the WSDL 1.1
or SOAP 1.1 specifications. To improve interoperability, consider adapting Java collection
classes to arrays and beans, and then building Web services from the adapters.
- Generating Java artifacts from a WSDL document
- Support
is limited to one part per input or
output element. Multiple logical parts in
an input or output message are not supported. The first such part will
be processed and the remaining ones will be ignored.
- When generating Web service skeletons
or proxies from WSDL that uses the type base64Binary from the xsd (http://www.w3.org/2001/XMLSchema)
namespace, the Web service run-time environment will actually use the xsi:type
base64 from the soapenc (http://schemas.xmlsoap.org/soap/encoding/) namespace.
In general, the two types are freely interchangeable. However, it is possible
the difference between the type in the message and the type in the schema
will cause some SOAP protocol run-time environments to reject the message.
Should this occur, you may hand-craft a serializer similar to Apache SOAP's
Base64Serializer but that writes xsd:base64binary instead of soapenc:base64.
- Java bean skeletons
will not compile if they are created from WSDL documents containing operation
and part names that are not valid Java identifiers. The WSDL operation and
part names must be valid Java identifiers in order for successful
creation of a Java bean skeleton.
- The Web services wizards
use "http" URIs by default when generating WSDL, however, some WSDL documents
from other tools may occasionally employ Web service, SOAP Action or Target
Namespace URIs that employ schemes other than "http", such as "urn". When
generating proxies or skeletons from WSDL that contain non-http URIs, the
Web service wizards may map the URIs to the Java package "com.example" rather than
to a more meaningful package. In some cases, the Web service wizards may fail
to handle such URIs entirely and produce the error "IWAB0234E An internal
error occured."
- When generating Java proxies
and Java skeletons
from WSDL, you now have the option of mapping the XSD intrinsic types boolean,
byte, short, int, long, float and double to the "java.lang" wrapper types
(for example, java.lang.Integer) instead of to the Java primitives (for example, int). By
default, the Web service wizards will map to the Java primitives. To instead have the wizards
map to the "java.lang" wrapper classes, open Windows® -> Preferences -> Web Services
-> Code Generation and check "Map simple XML data types to java.lang wrapper
classes."
- When specifying a custom
mapping from a Java type to an XSD type in when creating a Web service
from a Java bean
or EJB, the Bean class field is automatically set to the full name of the Java type
and cannot be edited. When custom mapping a Java array, the Bean class name will be
in array form, for example, "java.lang.String[]", and will be emitted as such
into the ".isd" and "dds.xml" deployment descriptor files. This form of class
name is not processed correctly by the SOAP run-time environment, and will
result in an error similar to the following:
Deployment
error in SOAP service http://tempuri.org/webservice.AddressBook: class name
java.lang.String[] could not be resolved: java.lang.String[]
As
a result, it is not possible to custom map the serializer for a Java array
on the service side. A partial workaround is to leave the Serializer class
field empty for the custom mapping. This will suppress the generation of the
array class name into the deployment descriptor and permit the service to
work. Note that the Deserializer class, and the ability to custom map the
deserializer, is not affected by this problem and workaround.
There is a limitation in the XSD Bean generator.
It cannot handle a duplicately named element. For example, if your schema
has the form:
<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>
then the XSD Bean generation will create
bean with multiple setters that have the same method name. If the type of
the aElem in the sequence changes, you will see a similar problem, with two
getters each returning different types but which have the same arguments.
- Run time considerations
- If you select the Web services code generation preference "Enable element-based
mapping" and you selected to deploy to a WebSphere Application Server V4, you may get
the following entry in the ISD file and dds.xml:
<isd:map encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:x="" qname="x:some-name" xml2JavaClassName="some-serializer"/>
The
XML editor may flag the following error:
The value of the
attribute "xmlns:x" is invalid. Prefixed namespace bindings may not
be empty.
This is harmless for the WebSphere Application
Server V4. However, do not attempt to deploy this dds.xml to other server
which uses Xerces 2.x (XML4J 4.x) or higher such as WebSphere Application
Server V5. Otherwise, you will get similar Xerces parse error when the server
loads the dds.xml file. You should regenerate dds.xml by going through the
Web service scenario and selecting the right server type. This will generate
the correct dds.xml for that server type.
Also, you would get similar
Xerces parse error when attempting to deploy Web service from that ISD file.
The workaround is to manually edit the file to the following format:
<isd:map encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" qname="some-name" xml2JavaClassName="some-serializer"/>
When invoking a Web service created from a Java bean
or EJB, if you get a SOAPException with a targetException such as: "java.lang.IllegalArgumentException:
Unable to instantiate ..." the problem may be that the method
exposed as a Web service contains a Java bean without a public default constructor
as a parameter and/or return type. A public default constructor is required
in order for the SOAP run-time environment to construct the object as part
of the deserialization process.
- The security file, cl-ver-config.xml
and sv-ver-config.xml, currently deployed into the Web project are the files
from WebSphere version
4.0 and do not precisely match the DTDs. But the files will work on both WebSphere version
4.0 and WebSphere version
5.0 despite the validation errors complaining that "xmlns:ds" or "xmlns:SOAP-SEC"
must be declared.
- If you create a bean which uses
two different complex types from the same package, when you create a SOAP-based
Web service from this bean, an XSD file is created for each complex type and
is given the same namespace. This results in validation errors in both the
Task list and the Web Services Explorer.
- ISD Web services
- After filling in a custom
mapping when creating Java or EJB Web services, the custom mapping
information, except the XSD Location URL, is stored in the ISD file. The information
is retrieved when creating Web services from that ISD file. Therefore, when
creating Web services from an ISD file, in the Web Service Java to
XML Mappings page of the wizard, you need to fill in the XSD location URL
manually.
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.
When generating
a Web service client for a URL Web Service, or for any WSDL that contains
only HTTP GET and POST bindings, use the IBM SOAP run-time environment for the client.
Any attempt to use the Axis or IBM WebSphere run-time environments may result
in incomplete generated code or an internal error (IWAB0234E An internal
error occured).
When generating a Web Service from a URL, the
WSDL produced has HTTP GET and HTTP POST bindings but no SOAP binding. The
Axis and IBM WebSphere run-time
environments do not support the HTTP GET and POST bindings in WSDL. Only the IBM SOAP
run-time environment supports the HTTP bindings. For more information on WSDL
bindings, see http://www.w3c.org/TR/wsdl
Web Services Explorer problems
- When the Web Services
Explorer loads WSDL files that use multiple inline schemas, warning messages
will be generated for types that are referenced across these schemas. The
warning message will be similar to: Reference of type <qualified_type_name>
isn't resolved. These are warnings and not errors, and therefore
can be safely ignored.
- When using the Web Services
Explorer with the Private UDDI Registry, the Manage Publisher Assertion Form
of a business node will not load in the following situations:
- You are not logged in to the registry node containing the business node.
- You are logged in to the registry node containing the business node, but
the business node is not owned by the User ID/Password that is used to log
in to the containing registry.
- You will not be able
to use the Web Service Explorer to query or publish through a basic authentication
enabled UDDI registry. An example of this kind of registry is a private registry
that is deployed on a server with basic authentication turn on. Please note
that all the public registries (IBM, Microsoft, SAP, NTT and XMethods) are
not affected by this problem.
- When an advanced search
is used in Web Services Explorer to find businesses in a WAS private UDDI
registry configured with a Cloudscape™ backend and one or more service
interfaces are specified as parameters, the search will fail and the status
window will show: com.ibm.uddi4j.wsdl.client.UDDIWSDLProxyException:
Could not list all service providers. ------------------------------------------------------------------------------
Nested exception is:
E_fatalError (10500)
Serious technical error has occurred while processing the request. : Fault
code=Client Fault string=Client Error Fault actor=null Detail=null DispositionReport:
ErrCode=E_fatalError ErrInfoText=E_fatalError (10500) Serious technical error
has occurred while processing the request.
- The XMethods registry has procedures in place to verify published Web
services deleting those which are not accessible or not working. To prevent
a published Web service from being deleted, ensure that all URL references
inside the WSDL files are accessible on the internet.
- The SAP UDDI Business Registry will
return a E_fatalError for a find business by category request with findQualifier
equals to "combineCategoryBags" (tModelKey equals to UUID:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2).
The following error message will be displayed in the status window. This is
a problem unique to the SAP UDDI Business Registry. com.ibm.uddi4j.wsdl.client.UDDIWSDLProxyException:
Could not list all service providers. ------------------------------------------------------------------------------
Nested exception is:
A serious technical error has occurred
while processing the request. : Fault code=Client Fault string=UDDI Error
Fault actor=null Detail=null DispositionReport: ErrCode=E_fatalError ErrInfoText=A
serious technical error has occurred while processing the request. at com.ibm.uddi4j.wsdl.client.UDDIWSDLProxy.findAllServiceProviders(UDDIWSDLProxy.java:1626)
at FindBusWithQualifier.main(FindBusWithQualifier.java:35)
- Publisher assertion
reports return by the SAP UDDI Business Registry do not contain any status.
As a result, the publisher assertion status column in the Web Services Explorer's
Manage Publisher Assertion Form will be blanked out for reports returned by
SAP. This is a problem unique to the SAP UDDI Business Registry.
- When attempting to publish
a business, service or service interface to the XMethods UDDI Registry, you
will get an error message regarding an "SSL Handshake Failure". This is a
known problem which IBM and XMethods are investigating.
The Web Services
Explorer cannot establish a secure SSL connection with the SAP UDDI (test)
registry, the NTT communications registry and the XMethods registry. As a
result, any operations that require a credential from the user will fail with
the following exceptions (operations that do not require credentials, such
as discovery, will continue to work):
Registry |
Error |
NTT communications registry: |
NTT communications registry:
IWAB0135E An
unexpected error has occurred. UDDIWSDLProxyException
Error getting
authentication token for [userid: <userid> ]
Nested exception is:
org.uddi4j.transport.TransportException: Error opening socket: javax.net.ssl.SSLHandshakeException:
certificate expired
|
XMethods registry: |
IWAB0135E An unexpected error has occurred.
UDDIWSDLProxyException
Error
getting authentication token for [userid: <userid> ]
Nested exception
is:
org.uddi4j.transport.TransportException: Error opening socket: javax.net.ssl.SSLHandshakeException:
handshake failure.
|
Private UDDI Registry problems
DADX Web services
The following
restrictions apply when generating a WSDL document from a DADX file:
- Generating a Java proxy
for DADX call operations with multiple output parameters is not supported.
- When creating a DADX
web service, occasionally the message "IWAB0177E Error generating WSDL from
a DADX file." will appear. In most cases this message is an indication of
some database related problem and the server console log should be consulted
for details on the problem. Also, check the following:
- The DAD (*.dad) files need to be located in the DADX group directory.
This is how the WORF run-time environment locates DAD files.
- If you are trying to generate a DAD file from a RDB to XML Mapping file
(.rmx), make sure the DAD file is located in the same folder as the DADX file.
In a DADX group you can specify
a JDBC net driver. For DB2® the net driver class is COM.ibm.db2.jdbc.net.DB2Driver.
For earlier versions of DB2, db2java.zip needed to be added to the server classpath,
and this zip file contains the driver. However, with DB2 version 8.1 and later, the file db2jcc.jar
also needs to be added to the server classpath. The file is usually located
in the same directory as the db2java.zip file. Ensure that The DB2 client level
on your machine is at the same fixpack level as the DB2 server that you are connecting to.
Multiple
outputs in DADX Web services: Normally, multiple outputs in a Web service
is not supported by our tools. However, in the case of DADX Web services,
multiple outputs are allowed if the Use Document Style group property is
set to true. In this case, when document
style is true, multiple outputs are combined
together into a single XML document.
DADX generation support: Although
user defined functions are listed in the Generate DADX wizard, there is currently
no support for generating DADX from user defined functions. Support is only
available for DADX generation from DAD files, stored procedures and SQL statements.
Selecting a UDF will cause a simple DADX skeleton file to be generated.
Setting
up a DADX group with datasource information:If the WebSphere Application Server is being used
to host a DADX Web service and the DADX group is configured to access the
database via a datasource, then the group.properties file for the DADX group
should use the following initialContextFactory property: initialContextFactory=com.ibm.websphere.naming.WsnInitialContextFactory
Also, the web.xml file for the project containing the DADX group needs
to have the following added. (Given that the datasource JNDI name is 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>
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.
- There
is a known issue when trying to use the Universal Test Client to access an
EJB's remote interface after generating a Web service for the bean. The workaround
for this issue is to run the Web service client in a different EAR than the
EAR which the EJB project resides in, and then run each EAR on a different
server.
Using Tomcat server with AXIS run-time
environment
If using Tomcat
4.1 and 4.0 servers that have Web applications using Axis installed on Linux,
you may encounter an error in the Web services wizards. If the server was
started and requires a restart aat some point in Web services wizard, the
wizard may hang because Axis blocks the Tomcat server from stopping.
The
workaround is to stop the server before starting the Web service wizard and
deselecting "Run on Server" on the wizard page that generates the test Web
service application.
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.
Importing WSDL files with
HTTP basic Authentication
When generating skeletons or clients from a WSDL file
that has relative imports and is HTTP Basic Authentication protected, the
user will see an error message indicating that the WSDL file cannot be resolved
even if the correct user ID and password are entered. The problem is that
the user ID and password are only used to retrieve the original WSDL file,
and not the files that it imports.
To overcome this problem, the user
can download the WSDL file and all the files that it imports to the workbench
first, and then generate skeleton or client from the downloaded WSDL file.
Resource preferences not observed
When using the Apache Axis 1.0 run-time environment,
the Axis emitters re-generate every time all the server/client Java files,
deploy.wsdd and undeploy.wsdd. WSDL2Java for the service generation scenario
will only generate the skeleton implementation file if it does not already
exist. If this implementation already exists, it will not be overwritten.
Problems encountered when working in a Team
Development Environment
When Web projects are being shared in a ClearCase
® team
environment, several
Add to Source Control dialogs will open
during Web service and Web service client creation if the Web service run-time
environment selected is IBM WebSphere or Apache Axis 1.0. In order to
suppress these dialogs, do the following:
- From the Window menu, select Preferences
- Expand Team in the left-hand pane. Select ClearCase.
- In the right-hand pane, change the value of the drop-down labeled When
new resources are added to Automatically add to source
control.
- Click OK.
- Go to .
- In the dialog that opens, select a default activity. Click OK.
Web services cheat sheet
In
the Create ,test and validate a WS-I compliant Web Service Cheat sheet and
Create a Web Service from a WSDL file CheatSheet, if you are using the HelloService.wsdl
file from the wsad_install/wstools/eclipse/plugins/com.ibm.etools.cs.wsdl.content_ver/examples,
please modify the service port location according to the different run-time
environment as follows:
For IBM SOAP:
location="http://localhost:9080/HelloWorldSample/servlet/rpcrouter"
For
Apache Axis or WebSphere run-time environment
location="http://localhost:9080/HelloWorldSample/services/Hello_Port"
If
you are importing your own wsdl file, make sure that the location is set properly
according to the run-time environment selected as mentioned above.
Supply Chain Management sample cannot be run
- In the Supply Chain
Management Example, if you need to change ports from the default 9080 port,
you need to modify the config.jsp file in the SCM-Sample project, This will
require a recompile. You will find 2 compile errors in the task list due to
missing webservices.jar in your build path.
- This compilation unit indirectly references the missing type javax.xml.rpc.ServiceException
- The import javax.xml.rpc cannot be resolved
To add the webservices.jar into the build path of the SCM-Sample, do
the following: SCM-sample->Properties select java
Build Path , click the Libraries tab, click Add
Variables select WAS_50_PLUGINDIR, click Extend go
to lib and select the webservices.jar, click OK,
and OK again.