WebSphere Web services preferences

The WebSphere® Web services preferences page allows you to set the following preferences used when creating or consuming WebSphere Web services.

 

Security

Show only FIPS compliant algorithms:

Select this if you only want the FIPS compliant algorithms to be shown in the Data Encryption method algorithm and Key Encryption method algorithm drop-down lists. Use this option if you expect this application to be run on a WAS that has set the Use the Federal Information Processing Standard (FIPS) option in the Global security panel of the WebSphere administrative console.

Show '*' instead of letters for passwords

 

Private UDDI Registry

Use this section to set the UDDI category data column and string delimiters.

 

JAX-RPC Code Generation

In addition to the information in this topic, several articles have been published on developerWorks® which contain more detailed information on a few of the JAX-RPC Web services preferences.

Java2WSDL

  • Style and use: specifies which style and use combinations are generated into the WSDL file. The combinations are RPC/encoded, RPC/literal, or document/literal.

  • Target namespace: enter a default target namespace for the WSDL being generated.

  • Wrapped: specifies whether to generate the WSDL file according to wrapped rules. This option is valid if use is literal only. The option defaults to true. For additional information on which style of WSDL to use, refer to the developerWorks article: Which Style of WSDL Should I Use?.

  • Use WSDL 1.1. Mime attachments exclusively: if the MIME type cannot map to WSDL 1.1 standards, the command fails.

  • SOAP action: this option is used to set the soapAction field in the generated WSDL. Default sets the soapAction field according to the deployment information. None sets the soapAction field to double quotes (""). Operation sets the soapAction field to the operation name.

  • Void return: this field is for a Web service method with return type of void that describes whether a response is expected from the Web service. Methods with void returns are one-way. This argument is the default for a JMS transport. Methods with void returns are two-way. This argument is the default for an HTTP transport.

  • Default bindings: specifies the list of binding types written to the output WSDL file. Each binding generator in the Java2WSDL command supports specific binding types. The valid binding type values are HTTP (SOAP over HTTP), JMS (SOAP over JMS) and EJB (local or remote EJB invocation).

  • Validate Java classes for compliance to JAX-RPC: if this is selected the wizard will validate that the Java classes are compliant to JAX-RPC before generating any code.

WSDL2Java

  • Default Service Scope: this indicates how to deploy the server implementation. Application uses one instance of the implementation class for all requests. Request creates a new instance of the implementation class for each request. Session creates a new instance of the implementation class for each session.

  • Use -noWrappedOperations for Skeleton Generation: disables wrapped operations detection. Java beans for the request and response messages are generated.

  • Disable data binding and use SOAPElement: disables the binding of XML types to Java types. Instead, each XML type is mapped to a javax.xml.soap.SOAPElement interface defined by the SOAP with Attachments API for Java (SAAJ) 1.2 specification. The JAX-RPC specification defines Java mappings for a subset of XML types. Several XML types cannot be mapped to Java beans or primitives. In this situation, the WSDL2Java command maps the type to an SAAJ SOAPElement. A SAAJ SOAPElement is a generic representation of the element in the message. The methods on the SOAPElement can be used to examine the element and its children.

  • Generate SDO facades from Java classes: this partially disables the JAX-RPC schema to Java mappings that the wizards use by default and instead use the Java Eclipse EMF SDO representation of XML Schema. This can be useful if your XML schema contains content that the JAX-RPC mappings do not handle gracefully. You must select Disable data binding and use SOAPElement if you want to generate SDO facades.

  • Do not overwrite loadable Java classes: when selected, the Web service wizards will not write any Java classes to the target project that both:

    • do not already exist in the project

    • do exist in a project, module or JAR file that will be loadable from the target project when the application is running on the server.
    If this option is not selected, the wizards may write Java classes to the target project that will mask preexisting classes with the same name in other projects, modules or JAR files. This can result in runtime environment and compilation errors.

  • Preserve Web services metadata: selecting this will place the Web services metadata in a folder called .backup in your current workspace. To replace project metadata files with files in the .backup folder of the project:

    1. Select the files in the .backup folder, right-click, then select

      Copy.

    2. Select the folder in the project where the metadata file resides, right-click and select

      Paste. If you are prompted to overwrite files, select

      Yes.

    Note: within a given view of the project, in order to view a file in the .backup folder in the project, ensure that the .*resources filter has not been applied to the view (View Menu > Customize view).

  • Generate Java files for all types: selecting this will generate Java files for all types described in the WSDL file, including unreferenced files.

  • Use -noWrappedArrays for Skeleton Generation: disables wrapped array detection

  • Generate hashcode() and equal() methods: indicates that each generated Java bean has equals and hashCode methods. The default is false.

  • Generated beans should implement java.io.Serializable: indicates that each generated Java bean implements the java.io.Serializable. The default is false.

  • Allow relative namespace: select this checkbox to allow relative namespaces when creating Web services. Using relative namespaces is not recommended because they cause interoperability issues. Any Web service using relative namespaces will be considered WS-I incompliant.

V6 Thin Client

Starting in v6.0.2, WAS introduced a jar capable of building and running Java SE JAX-RPC Web service clients. In Rational® Application Developer 7.5, the WebSphere v6 thin client options enable you to register the thin client for use as a classpath variable which will be added to Java projects during the creation of IBM® WebSphere v6 JAX-RPC Web service clients in standalone Java projects.

Once you have selected to enable and register the WebSphere v6 thin client jar in the Web services preferences page, you can create a Java project which uses WAS v6.x as its JRE and has the Java 1.4 facet enabled, and generate a Web service client into this project.

  • Use WebSphere V6 thin client: Select this if you want to use a Java SE thin client for your Web service.

  • Path: Enter the fully-qualified path to the to the ibm-jaxrpc-client.jar. Click

    Detect if you want Rational Application Developer to try to find this jar for you, or manually enter the path.

 

JAX-WS Code generation

Top Down

  • Copy WSDL into project: Select this to copy the WSDL file from which the Web service is being created into the Web service project. This is a convenient option if you plan to create the client at a later time or publish the WSDL for other users.

  • Enable wrapper style: For WSDL documents that implement a document/literal wrapped pattern, a root element is declared in the XML schema and is used as an operation wrapper for a message flow. Separate wrapper element definitions exist for both the request and the response. More simply, the element whose name is the same as the operation (the wrapper element) is broken apart so that each of its content elements becomes a parameter of the generated Java method signature.

  • Enable MTOM support: If you select this check box the SOAP Message Transmission Optimization Mechanism will be enabled.

  • Generate schema library project from XSD file: Selecting this will run the JAX-WS Schema to Java compiler to generate schema code into a schema library.

  • Generate Web service deployment descriptor: For JAX-WS Web services deployment information is generated dynamically by the runtime; static deployment descriptors are no longer required. Selecting this checkbox will generate them.

  • Version of JAX-WS code to be generated: Starting with WAS v7.0, you can generate JAX-WS 2.1 compliant code. Previously only JAX-WS 2.0 was supported.

Bottom Up

  • Enable SOAP 1.2 support: You can choose between SOAP 1.1 and SOAP 1.2 bindings.

  • Enable MTOM support: If you select this check box the SOAP Message Transmission Optimization Mechanism will be enabled.

  • Java to WSDL mapping style: This specifies the style of Java to WSDL mapping. Style defines encoding style for messages sent to and from the Web service. Parameter style determines whether the method's parameters represent the entire message body or whether parameters are elements wrapped inside a top-level element named after the operation. The combinations are RPC, Document/Wrapped, or Document/Bare.

  • Generate WSDL into the project: Select this to generate a WSDL file into the Web service project. This is a convenient option if you plan to create the client at a later time or publish the WSDL for other users.

  • Generate Web service deployment descriptor: For JAX-WS Web services deployment information is generated dynamically by the runtime; static deployment descriptors are no longer required. Selecting this checkbox will generate them.

Client

  • Enable asynchronous client support: If you select to enable an asynchronous client, for each method in the Web service two additional methods will be created. These are polling and callback methods which allow the client to function asynchronously.

  • Generate portable client: Selecting this checkbox would allow you to move your Web service client code from one machine to another or from one instance of WAS to another. If this option is selected, the WSDL document and all the XML Schema and other WSDL documents that it depends upon will be copied into the client project under WEB-INF/wsdl and a file:relativeURL pointing to this copy will then be injected into the JAX-WS Service class’s static initialization block.

  • Generate Web service deployment descriptor: For JAX-WS Web services deployment information is generated dynamically by the runtime; static deployment descriptors are no longer required. Selecting this checkbox will generate them.

  • Version of JAX-WS code to be generated: Starting with WAS v7.0, you can generate JAX-WS 2.1 compliant code. Previously only JAX-WS 2.0 was supported.