Limitations of Web services

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

• Problems encountered when using the Web Services wizards

• Problems encountered when using WebSphere run-time environment

• Problems with using Apache Axis 1.0 run-time environment

• Permanent Limitations when using IBM SOAP run-time environment

• Limitations when creating a Web service client

• Web Services Explorer problems

• Private UDDI Registry problems

• DADX Web services

• Using the Universal Test Client

• Using Tomcat server with AXIS run-time environment

• Problems when using Web services command line

• Importing WSDL files with HTTP basic Authentication

• Resource preferences not observed

• Problems encountered when working in a Team Development Environment

• Web services cheat sheet

• Supply Chain Management sample cannot be run

 

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:

  1. Open the implementation class.

  2. Go to the line where the SOAPElement is instantiated (should look similar to the following:createSOAPElement("http://schems.ibm.com/wswrapper",">D"

  3. Remove the > character.

  4. 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 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:

  1. Open the implementation class.

  2. Go to the line where the SOAPElement is instantiated (should look similar to the following:createSOAPElement("http://schems.ibm.com/wswrapper",">D"

  3. Remove the > character.

  4. 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, 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

• On Linux, in order to use DB2 as a back-end system for the Private UDDI Registry with WebSphere Application Server v6 , both the Rational Developer product and WebSphere Application Server v6 must be started as root in a command prompt from the directory in which the db2profile is sourced. For example, if your DB2 instance is called db2inst1 and the Rational Developer product is installed in /opt/IBM/RAD, the correct way to start them would be:
  1. Open a command prompt.

  2. In the prompt, type . /home/db2inst1/sqllib/db2profile (Note the space after the dot)

  3. In the same prompt, type /opt/IBM/RAD/runtimes/base_v6/bin/startServer.sh server1

  4. In the same prompt, type /opt/IBM/RAD/rationalsdp.bin

• On Linux, in order to use DB2 as a back-end system for the Private UDDI Registry with WebSphere Application Server v5.1 , the Rational Developer product must be started as the DB2 instance user (db2inst1 by default).

• 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 (That is, 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.

• After creating or updating a Cloudscape-based Unit Test UDDI registry on Linux, you may get a red warning in the server console that states: Cloudscape (instance <uuid>) is attempting to boot the database <UDDI DB location> even though Cloudscape (instance <uuid>) may still be active. Only one instance of Cloudscape should boot a database at a time. Severe and non-recoverable corruption can result and may have already occurred.

  This warning is a false alarm. More details can be found at: http://www.ibm.com/support/docview.wss?rs=636&context=SSCVRP&q=&uid=swg21051601&loc=en_US&cs=utf-8&lang=en+en

 

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:

  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.

• 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:

1. From the Window menu, select Preferences

2. Expand Team in the left-hand pane. Select ClearCase.

3. In the right-hand pane, change the value of the drop-down labeled When new resources are added to Automatically add to source control.

4. Click OK.

5. Go to ClearCase > Set Current Activity.

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