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
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:
- Generating a WSDL document from a Java bean, DADX document, enterprise bean, ISD file, and URL.
- Generating a Java proxy or skeleton from a WSDL document.
- Creating and deploying a Web service from a Java bean, DADX, enterprise bean, or URL.
- Discovering and publishing Web services.
- Generating a sample Web application from a Java proxy.
- Interoperability issues.
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:
- Simple Object Access Protocol (SOAP) Version 1.1
- Universal Description, Discovery, and Integration (UDDI) Version 2.0
- Web Services Definition Language (WSDL) Version 1.1
- Web Services Inspection Language (WSIL) Version 1.0
This release of the Web service tools supports the Simple Object Access Protocol (SOAP) Version 2.2 and Version 2.3 run-time environments.
The following features are new in Web services development:
- Interoperability enhancements
- Use of XSD-aware serializers and deserializers for serializing and deserializing Java beans so that the case and the order of elements in XSD files are respected in SOAP messages.
- Fully enabled code generation preference to optionally turn on the generation of element-based mapping so that you can deserialize SOAP messages whose elements do not have "xsi:type" properties.
- Web Services Explorer enhancements
- The Web Services Explorer now runs in the embedded browser by default.
- The default favorites has now replaced the read-only XMethods registry with a new read/write version. Also, the NTT Communications registry is newly available.
- Dramatic improvement in the performance for finding services and service interfaces in UDDI.
- Added code generation preference to map simple XML data types to java.lang wrapper classes.
- 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 method(s) containing the primitive type(s) or wrapper type(s) 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 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 runtime (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\runtime\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 runtime 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.
- When creating Web services from a Java bean containing Object classes from the JDK (ie. java.net.URL), the tool will create a mapping entry for this object as if it were a valid Java bean. A further consequence will be an invalid generated bean (i.e. "java.net.URL") in the client project. It is recommended that methods containing these types in its signature be omitted from the method selections.
- The Web service tools currently do not support the creation of Web services from Java Beans containing nested inner classes (ie. 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.
- 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.
- If the "File overwrite" preference in the Web Service Preference page is enabled, and the "Use V4 mapping style" preference is disabled (default), the Java bean(s) generated by the Web Service Client wizard will overwrite the original Java bean(s) in the Java Source directory if you go through the wizard and create a WSDL file from Java bean(s) and use the same project to generate the Java proxy from the WSDL files using the Web Service Client wizard. To avoid this situation, copy the WSDL files to another Web project before running the Web Service Client wizard.
- 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 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 runtimes 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.
- When generating Web service skeletons or proxies from WSDL, com.ibm.etools.webservice.runtime.XSDAnyTypeSerializer is automatically used as serializer and deserializer for Java beans and complex types instead of org.apache.soap.encoding.soapenc.BeanSerializer. This serializer is XSD-aware and would serialize and deserialize elements on SOAP messages according to the case and order defined in the original XSD file.
- 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 (eg. 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 a bottom-up scenario, 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 runtime, 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.
- 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.
- Users may encounter a rare race condition when launching the Web Services Explorer. The result is a browser window containing a "Page not found" error. The problem may be resolved by relaunching the Web Services Explorer or by restarting WebSphere Studio and then relaunching the Web Services Explorer.
- 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.
- When performing an advanced find or publish in the UDDI page of the Web Services Explorer, the items in the drop down list for picking a language in conjunction with a name or description is sorted according to the operating system's locale settings. On Windows, this order may be managed through the Control Panel. To do this:
- Open the Control Panel
- Launch the Regional Options control panel applet
- In the General tab of the resulting dialog, there may be a "Sorting order" dropdown list. If so, pick a sorting order and then click Apply followed by OK.
- In the Web Services Explorer, the new sorting order comes into effect once the page reloads. This can be accomplished by pressing the back followed by the forward arrows in the main toolbar.
Note: The instructions above apply to Windows 2000. On Windows XP, the tab mentioned in step 3 is called "Regional Options". Beside the language dropdown, there is a Customize... button. When this is clicked, a new dialog appears. A sorting tab will allow users to pick the sorting method if applicable.
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)
- The Microsoft Test and Production UDDI registries may return no results when multiple valid service interfaces are specified in a search for services. Microsoft has acknowledged the problem and will be making a fix in the future.
- 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 launching the Web Services Explorer from the Web Service client wizard, the Next button on the WSDL Selection page (second page of the Web Service client wizard) is incorrectly enabled. Nothing will happen when the Next button is clicked, the wizard will stay on the same page. This does not affect the functionality of the wizard or the Web Services Explorer. To launch the Web Services Explorer, click on the Finish button.
- Adding a Web project that contains a Web service to both the WebSphere Application Server and the Apache Tomcat server is not supported. The deployment artifacts generated into the Web project differ according to the server environment.
- When creating and deploying multiple Java Bean or EJB Web services in a single Web project, insure that each Web service has a unique Web service URI. If two or more Web services share the same URI, only the last one listed in the generated dds.xml file will be reachable via the Web service SOAP runtime.
- If you select the Web Services code generation preference "Enable element-based mapping" and you selected to deploy to a WAS V4 server, 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 WAS V4 server. However, do not attempt to deploy this dds.xml to other server which uses Xerces 2.x (XML4J 4.x) or higher such as WAS V5 server). 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 runtime 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 the Server Configuration is opened in an editor, Web service wizard may fail to start the server due to Web Service Web project not added to the Server Configuration. Closing the Server Configuration editor will resolve the problem.
- Do not use the Web Services backward compatibility preference -> use V4 mapping style, if you have underscore or other strange characters not allowable as Java identifier as:
- names for bean attribute when creating Web services from Java bean or EJB
- element names in complex types in XSD files when creating Web service client proxy
Use the V4 mapping style instead.Otherwise, if you have a bean called Bean with attribute called some_name and specify using the V4 mapping style, you may run into the following error at run-time:
exception: [SOAPException: faultCode=SOAP-ENV:Client; msg=Unable to unmarshall mappings.BeanContentType. Unable to find setter method with method name setSomeName for class mappings.BeanContentType.]
- The TCP/IP monitoring server does not work with the SOAP runtime on Linux. Any attempt to insert the monitoring server between a Web Service and a Web Service client (for example, the Web service sample JSPs, Web tools Java bean JSPs and Universal Test Client) will interfere with communications between the client and the service. In particular, the client will hang indefinitely on the first response from the service. To recover from this condition in the sample JSPs or the UTC, close all browsers, then launch a new browser from outside of WebSphere Studio and type in the appropriate URL for the generated sample JSPs or the Universal Test Client.
To monitor SOAP traffic on Linux, try another monitoring tool such as the TCP/IP tunnel included with the Apache SOAP runtime which can be downloaded from http://ws.apache.org/soap/index.html.tool. Start the tunnel and invoke a Web service client operation. The request and response traffic should appear in the tunnel, however, the client will appear to suspend. Stop the tunnel. This will cause the client to unblock and the operation to complete. Restart the tunnel before attempting the next call.
- The Web Service creation wizard may fail during generation of WSDL if the hostname "localhost" is not defined on the computer. The UTC may also fail to launch successfully if "localhost" is not defined.
In Windows, the following entry must be present in the [INSTALL-DRIVE]\WINNT\system32\drivers\etc\hosts file:
127.0.0.1 localhost
In Linux, the following entry must be present in the /etc/hosts file:
127.0.0.1 localhost
- URIs are restricted to allowable, printable characters of US-ASCII. For more information refer to RFC 2396.
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.
- 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.
- The Private UDDI Registry should only be configured with the Cloudscape backend for very basic testing purposes (i.e. do not use this backend for production work as there are currently difficulties with actions such as complex queries). For more information on the private UDDI Registry, please refer to the Network Deployment documentation in the WAS V5 InfoCenter.
- Generating WSDL with complex parameters may cause problems with Microsoft tools that consume WSDL. The Microsoft tools do not handle XSD include statements properly, so it may be necessary to inline XSD schemas into generated WSDL. This can be done by selecting
Windows > Preferences > Web Services > Code Generation > use inline schema.The Web services wizards is now fully enabled to generate element-based mappings, in addition to any of the normal type-based mappings, if the "Enable element-based mapping" checkbox is checked. From the WSAD main menu, this checkbox is found on the following preferences page:
Windows > Preferences > Web Services > Code Generation.If this preference is not enabled, which is the default, the Apache/IBM SOAP runtime may not interoperate with other vendors' Web service runtimes that send messages whose elements do not have "xsi:type" properties. Web service runtimes from other vendors follow various policies on the inclusion of xsi:type properties. Some always include them. Some never do. Some provide a configuration choice. Some omit xsi:types for certain types, like arrays.
The typical error produced by the IBM/Apache SOAP runtime is:
targetException=java.lang.IllegalArgumentException: No Deserializer found to deserialize a ':MyElement' using encoding style 'http://schemas.xmlsoap.org/soap/encoding/'.
When enabled, element-based mappings are generated into:
- the deployment descriptor file for bottom-up Java bean/EJB scenarios and WSDL Skeleton scenarios, and
- the Proxy in client scenarios.
Element-based mappings are of the form:
<isd:map
encodingStyle="encoding style"
xmlns:x="some-namespace"
qname="x:some-local-name"
xml2JavaClassName="some-deserializer-class-name"/>An element based mapping is generated for:
- Each part defined in each wsdl:message input.
- Each part defined in each wsdl:message output, for Skeleton and Proxy scenarios only.
- Each root element or local element in each complex type referenced by parts in the WSDL file
The WSAD Web service wizards follow the SOAP and XSD specifications to determine whether or not the element name in an element-based mapping should be qualified (ie. have a namespace) or unqualified.
WSAD Web services follows these rules for deciding between qualified and unqualified element names:
- Part names in WSDL yield unqualified names.
- Root elements in XSD yield qualified names.
- Local elements in XSD yield unqualified names if the schema specifies elementFormDefault="unqualified", which is also the default if the schema has no elementFormDefault attribute.
- Local elements in XSD yield qualified names if the schema specifies elementFormDefault="qualified".
Some runtimes are known to generate unqualified elements in SOAP messages despite a schema that specifies the use of qualified elements via the XSD schema's "elementFormDefault" attribute. In such cases, you may need to hand-edit a service's WSDL or XSD and change elementFormDefault to "unqualified".
An example of a non-namespace qualified element-based mapping is:
<isd:map
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:x=""
qname="x:name"
xml2JavaClassName="org.apache.soap.encoding.soapenc.StringDeserializer"/>An example of a namespace qualified element-based mapping is:
<isd:map
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:x="http://www.ibm.com/"
qname="x:name"
xml2JavaClassName="org.apache.soap.encoding.soapenc.StringDeserializer"/>Please note that only one element based mapping will be generated for a given element name. That is, if the schema uses the same element name more than once but with different types, only one of the elements will be selected, effectively at random, as the basis for one element-based mapping. The other identically-named elements of different types will fail to deserialize. The same is true if the schema uses the same name for an element and for a WSDL part.
- When beginning with a service bean which returns an array of Map or an array of Hashtable, and the "element-based mapping" option is enabled, the generated SOAP Proxy will incorrectly map the return type to a java.lang.String[]. A ClassCastException will occur during run-time. To work around this problem, run the Web service client wizard with the newly created WSDL and regenerate the SOAP proxy into the client project.
- 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:
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.
- 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'.
- In order to improve interoperability with Microsoft Web services, the DADX runtime has been updated so that they can generate document style web services. To enable this feature, use the DADX configuration wizard to open the property page for a DADX group that is to be used. At the bottom of the property page ensure that the "Use document style" entry field is set to true.
- Generating a Java proxy for DADX call operations with multiple output parameters is not supported.
- When creating a DADX web service, occassionally 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 runtime 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.
- The DADX schema no longer uses the WSDL document tag for documentation. This tag is now a part of the DADX schema. This may cause validation problems with old DADX files that have not been migrated to using the updated schema. For example, if your old DADX file contained the following XML:
<wsdl:documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
Provides queries for part order information at myco.com.
</wsdl:documentation>the new document entry would be:
<documentation>
Provides queries for part order information at myco.com.
</documentation>
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.
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.
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.
- HospitalProj/Java Source/proxy/soap/com/ibm/b2b/examples/insurance/InsuranceServiceBeanProxy.java
- HospitalProj/Java Source/proxy/soap/WSDLserviceProxy.java
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.
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=WsnNameServiceThe 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.
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.
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.
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.
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.
- On the Web service DADX group property page of the Web services wizard, changes may not take effect immediately. Therefore, we recommended that changes to DADX group properties be done using the DADX Group Configuration Wizard.
- After editing and validating a DADX file, you may get a message in the Tasks view that states that the project needs to be rebuilt. If this situation arises, right-click the appropriate project and click Rebuild project. You may need to do this a second time to remove the message from the Tasks view.
Return to the main readme file