Web services tools - release notes

1.0 Introduction
2.0 Supported software and specifications
3.0 Changes from the previous release
4.0 Known problems and limitations
   4.1 Generating a WSDL document from a Java bean
   4.2 Generating a Java artifact from a WSDL document
   4.3 Web Services Explorer
   4.4 Run-time considerations (WebSphere Application Server, Apache Tomcat)
   4.5 URI restrictions
   4.6 ISD Web services
   4.7 Private UDDI Registry
   4.8 Interoperability
   4.9 Generating a WSDL document from a DADX file
   4.10 Web tools JSP Generator
   4.11 Web Services JSP Sample
   4.12 Hospital/Insurance Scenario
   4.13 Using the Universal Test Client
   4.14 Web service sample JSP fails to open
   4.15 Multiple output allowed in certain cases with DADX Web services
   4.16 JDBC driver preference is for use on Linux only
   4.17 Need up to update DAD example files if XML extender is not installed in default directory
   4.18 DADX Web services issues

1.0 Introduction

The Web service tools feature enables you to discover, create, and publish Java bean, DADX, enterprise bean, and URL Web services. This readme file describes the known problems, limitations, and workarounds that are associated with the following Web service tools functions:

2.0 Supported software and specifications

Web Services Explorer requires the use of Netscape Version 6.0 or higher or Microsoft Internet Explorer 5.0 or higher

This release of the Web service tools generates code that complies with the following specifications:

This release of the Web service tools supports the Simple Object Access Protocol (SOAP) Version 2.2 and Version 2.3 run-time environments.

3.0 Changes from the previous release

The following features are new in Web services development:

4.0 Known problems and limitations

4.1 Generating a WSDL document from a Java bean

4.2 Generating a Java artifact from a WSDL document

4.3 Web Services Explorer

4.4 Run-time considerations (WebSphere Application Server, Apache Tomcat)

4.5 URI restrictions

4.6 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.

4.7 Private UDDI Registry

4.8 Interoperability

4.9 Generating a WSDL document from a DADX file

4.10 Web tools JSP Generator

The generated Web tools Java bean JSPs do not support special types BigDecimal, Date, GregorianCalendar, BigInteger and URL. Also not supported are maps, collections, arrays and complex types. You may hand-edit the JSPs to support these types, or you may generate the Web service Sample JSPs instead, which do support these types. Visit Windows > Preferences > Web Services > Dialogs to choose your preferred style of generated Sample JSPs.

4.11 Web Services JSP Sample

You may run into a sample compilation error if you generate WSDLs, proxy and sample for a Java bean, then modify the Java bean (e.g. change the signature of one of its methods). If you then delete the previously generated proxy before regenerating WSDLs, proxy and sample for the modified Java bean, the newly generated sample may not compile since the sample is using data from the original Java bean before it is modified.

4.12 Hospital/Insurance Scenario

The Hospital/Insurance example assumes that the server is listening to port 9080. If this is not the case, you will need to update the following two proxy files.

For each of these files, change "http://localhost:9080..." to "http://localhost:NEW_PORT...", where NEW_PORT is the port number your server is listening to.

4.13 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 v5 port of 2809. If you are using a WebSphere v4 server or 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:

  1. Double click the server you are using. This will bring up the server properties.
  2. Select the ports tab.
  3. Copy the Orb bootstrap port.
  4. Open the JNDI properties window in the Universal Test Client.
  5. Paste the bootstrap port into the Provider URL text iput box.

4.14 Web service sample JSP fails to open

The Web service sample JSP may fail to open in the Browser when the server is reloading. Click the Refresh icon in the Browser to reload the sample JSP or re-launch the URL.

4.15 Multiple output allowed in certain cases with 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.

4.16 JDBC driver preference is for use on Linux only

A new Web services Preferences (Windows > Preferences > Web Services) category called JDBC drivers has been added. Although this preference is available on all platforms, it is intended for use only on Linux. On Linux, it can be difficult to determine the location of the JAR file containing JDBC drivers. Therefore, this preference page was added so that you can specify which JAR file to use. Currently, only the DADX validation code uses this JAR file information.

4.17 Need up to update DAD example files if XML extender is not installed in default directory

The DAD files located the the WSinstall_dir\wstools\eclipse\plugins\com.ibm.etools.webservice_<version>\samples\DADX_examples directory may need to be modified in two places to reflect your particular system configuration.

Near the top of the file is a line similar to the following:

<!DOCTYPE DAD SYSTEM "c:\dxx\dtd\dad.dtd">

If the XML extender has been loaded into a different location than c:\dxx then this string needs to be updated to reflect the actual location. This applies to Linux machines as well, where the location is usually /usr/IBMdb2xml.

The second part of the DAD file that needs to be updated is the following line:

<doctype>!DOCTYPE Order SYSTEM "c:\dxx\samples\dtd\getstart.dtd"</doctype>

If the XML extender is located in a different directory the getstart.dtd path will need to be changed accordingly.

4.18 DADX Web services issues

Return to the main readme file