Web services preferences

Before you begin developing Web services, you may want to set the Web services tools preferences to optimize and simplify your development experience.
To set any of the Web services preferences, follow these steps:
  1. Click Window > Preferences to open the Preferences notebook.
  2. Expand Web services or Web and XML, and click the preference category that you want to set
  3. Select the check boxes that you want to set as the default when creating your Web service.
  4. Click OK to apply the changes and close the Preferences notebook.
If you require more information on any of the options, select the option and press F1.

Web services tools enable you to define the following preferences:

Axis Emitter
This page allows you to set the following preferences used when creating or consuming Axis Web services.
WSDL2Java
  • Generate code for all elements: By default, WSDL2Java only generates code for those elements in the WSDL file that are referenced. For additional information regarding how referencing works refer to the Axis reference guide: http://ws.apache.org/axis/java/reference.html
  • Emits separate Helper classes for metadata: If you select this option WSDL2Java will create a separate helper class that contains the metadata rather than including it in the skeleton.
  • Prefers building beans to straight arrays for wrapped XML array types: The default behavior is to map this XML construct:
    <element name="array">
     <complexType>
      <sequence>
       <element name="item" type="xs:string"/>
      </sequence>
     </complexType>
    </element>
    to a Java String array (String[]). If you would rather a specific JavaBean class (ArrayOfString) be generated for these types of schemas, select this option.
  • Add scope to deploy.wsdd: 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.
  • Timeout in seconds: The default is 45. Use -1 to disable the timeout.
Java2WSDL
  • Look for allowed methods in inherited class: If this option is specified, the Java2WSDL parser will look into extended classes to determine the list of methods to export into the WSDL file.
  • Analyze the service class for compliance to JAX-RPC before generating code: If selected, the tools will examine the Java service class and its value types to determine if it satisfies important requirements of the JAX-RPC specification.
Popup Dialog Selection
The Dialogs preferences enable you to determine which dialog boxes that you want to see when running popup actions. If you have disabled any of the dialogs by selecting "Do not show this dialog again" on the first page of a Web services wizard, you can undo your change by clearing the check box beside the dialog that you have chosen to hide.
Profile Compliance and Validation
The WS-I Compliance preferences allow you to select your level of compliance with the WS-I Simple SOAP Binding Profile (SSBP) and WS-I Attachement Profile (AP). Note: if you change the level of WS-I compliance while WS-I incompliances are listed in the Task view, the Task view will not be automatically updated. The workspace must be revalidated before the warnings will be removed from the Task view. For more information on WS-I, refer to: http://www.ws-i.org/
For validation preferences, you can choose whether or not WSDL files consumed by the Web services wizards are validated, and whether or not the WSDL validation must complete before the wizard will move to the next step.
Project Topology
The Project Topology preferences allow you to:
  • Select the default client project type that the Web services wizards will create when generating a Web service client. You can also set the order in which the client project types will be listed in the wizard. Note that this selection is simply a default and an alternate project type can be selected in the wizard.
  • Select whether you want to generate the Web service and the Web service client in the same EAR project or different EAR projects. Generating the service and client into different EAR projects can reduce the chance of conflicts that occur when both exist in a single EAR project, but uses more system resources.
Resource Management
The Resource Management preferences enable you to determine the file and folder creation and overwriting defaults that you want to use when creating your Web service.
  • Overwrite files without warning: selecting this will allow the wizards to overwrite any existing files in the workspace without prompting. If it is not selected you will be prompted each time a file needs to be overwritten.
  • Create folders when necessary: selecting this enables the wizards to create any required folders.
  • Check out files without warning: select to check out files without receiving a warning message asking for confirmation.
  • Merge generated skeleton file: this check box is disabled by default. If this check box is enabled, when a skeleton file of the same name already exists in the workspace, the newly generated skeleton file will merge with the existing skeleton file. Enable this to preserve code that you have already modified in the existing skeleton files.

    Note that when this preference is enabled, if you change the return type of an interface, the resulting skeleton file will have a method returning the type as defined in the new interface but would have a method body from the original skeleton file (which would be returning a different type). This will result in an compilation error that the you will have to correct manually.

Scenario Defaults
The Scenario Defaults preferences enable you to set the following scenario defaults that you want to use when creating your Web service:
  • which type of Web service and client you want to be selected by default.
  • which phases of the Web service lifecycle you want to complete in the wizard.
  • if you want the Web Services Explorer to launch by default so that you can publish your Web service to a UDDI registry.
  • if you want the Web service SOAP traffic routed through a TCP/IP monitor so that you can monitor the SOAP packets and optionally test them for WS-I compliance.
Note that all these defaults can be overridden in the wizard.
Server and Runtime
Select the server, Web service run-time environment, and J2EE version that you want selected by default in the Web services wizard. Note that all these defaults can be overridden in the wizard.
Test Facility Defaults
can select whether to have the wizard automatically launch a test facility, and you can select your preferred type of test facility
WebSphere®
JAX-RPC Code Generation
The Code Generation preferences enable you to set the following preferences for Web services creation:
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 write 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 run-time environment and compilation errors.
  • Overwrite existing skeleton bean when creating a Web service: if you select this option the wizard will overwrite the skeleton bean it creates, erasing any changes you may have made to a previous version of it.
  • 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.
Private UDDI Registry
Use this page to set the UDDI category data column and string delimiters.
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 WebSphere Application Server 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.
SOAP Transports
Select your default transport: SOAP over HTTP or SOAP over JMS. This preference only applies if you are using Web services that use the WebSphere run-time environment.
WS-I BSP Compliance
Use this page to select the level of compliance with the WS-I Basic Security Profile. Suggest will generate an error message if your Web service is not compliant, while Require will not allow you to generate a non WS-I BSP compliant service. For more information on the WS-I BSP, refer to: Basic Security Profile Version 1.0.

Feedback