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 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
- By default the workbench will display an asterisk "*" rather than
letters for passwords.
Private UDDI Registry
Use this section to
set the UDDI category data column and string delimiters.
- The default column delimiter is #
- The default string delimiter is "
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: This
is only intended for the JAX-RPC bottom-up Web service wizard. When
the option is selected, the wizard 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. Note that this setting does not apply to the Web services Java or EJB skeleton wizards. It
apples only the JAX-RPC bottom-up Web services wizard.Note: This checkbox
is independent of "Overwrite files without warning" checkbox found
in the Web services wizards. Selecting that checkbox will not cause
this setting to be ignored. However when running bottom-up scenarios, Java code auto-generated form WSDL
using the WSDL2Java emitter will follow the setting of the "Overwrite
files without warning" checkbox. This includes such files as the proxy
and service endpoint interface.
- 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:
- Select the files in the .backup folder, right-click, then select Copy.
- 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 version 6.0.2, WebSphere Application
Server introduced a jar capable of building and running Java SE JAX-RPC Web service clients. 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 WebSphere Application Server 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.
- Generate serializable JAXB classes: In WebSphere Application Server
v7.0 and v8.0 when you enable the Java 6
facet, you can choose to generate JAXB classes which implement java.io.Serializable.
Classes that do not implement this interface will not have any of
their state serialized or deserialized.
- 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: When
deploying to WebSphere Application
Server v7.0 or later, you can generate JAX-WS 2.1 compliant code,
and when using WebSphere Application
Server v8.0 you can generate JAX-WS 2.2 compliant code. Previous versions
of the server only support JAX-WS 2.0.
- 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 serializable JAXB classes: In WebSphere Application Server
v7.0 and v8.0 when you enable the Java 6
facet, you can choose to generate JAXB classes which implement java.io.Serializable.
Classes that do not implement this interface will not have any of
their state serialized or deserialized.
- 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 WebSphere Application Server 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.
- Generate overriddenEndpointURI template: When
enabled, results in the generation of a WebSphere extended deployment descriptor
which overrides the endpoint URL used by clients when invoking a Web
service. This only takes effect when the client is using JSR-109 (that
is, has a client service-ref deployment descriptor). Otherwise, the
client runs in unmanaged form and ignores this setting. If you generate
deployment descriptors and try to use a TCP/IP monitor, the endpoint
is fixed, and the TCP/IP monitor will not see any traffic.
- Enable MTOM support: If you select this
check box the SOAP Message Transmission Optimization Mechanism will
be enabled.
- Version of JAX-WS code to be generated: When
deploying to WebSphere Application
Server v7.0 or later, you can generate JAX-WS 2.1 compliant code.
Previous versions of the server only support JAX-WS 2.0.