WSDL Bindings for Jms
Overview
WSIF defines extra WSDL extensions that are not part of WSDL4J itself. Amongst
others, these WSDL extensions are needed for JMS. You should use WSIF to read
in your WSDL, rather than using WSDL4J directly, because WSIF adds in its
own extension registries that understand these extra WSDL extensions. For example
you can use WSIFUtils.readWSDL to do this. This page describes WSIF's WSDL
extensions for JMS. Currently, these WSDL extensions are valid for Soap over Jms,
Axis over Jms and NativeJms. The jms namespace must be
xmlns:jms="http://schemas.xmlsoap.org/wsdl/jms/"
Jms address
<jms:address describes a target port that is accessible via JMS.
<jms:address jmsVendorURI="xxx"
jndiDestinationName="xxx"
destinationStyle="xxx"
jndiConnectionFactoryName="xxx"
initialContextFactory="xxx"
jndiProviderURL="xxx"
jmsProviderDestinationName="xxx"
jmsImplementationSpecificURI="xxx" />
- this must go in the port
- jmsVendorURI is optional and unused by WSIF. It allows to the client
to check the JMS implementation.
- either destinationStyle or jmsImplementationSpecificURI must be
specified, but not both.
- jmsImplementationSpecificURI specifies the queue manager and queues
in a implementation specific format. This is currently unimplemented by WSIF.
- destinationStyle must either be queue or topic, but topics aren't yet
implemented by WSIF.
- if destinationStyle is specified, then either jndiDestinationName or
jmsProviderDestinationName must be specified but not both.
- jndiDestinationName is the JNDI name of the JMS queue that WSIF will
send requests to.
- jmsProviderDestinationName is the JMS name of the JMS queue that WSIF
will send requests to.
- if jndiDestinationName is specified then jndiConnectionFactoryName must
also be specified.
- if jmsProviderDestinationName is specified then jndiConnectionFactoryName may
also be specified. jndiConnectionFactoryName would be needed if the JNDI name
of a replyTo queue is passed to WSIF.
- jndiConnectionFactoryName is the JNDI name of the connection factory
that WSIF will use.
- if destinationStyle is specified then either both jndiProviderURL and
initialContextFactory or neither must be specified.
WSIF uses the following order to lookup queues and queue managers in JNDI
- Lookup java:comp/env/<name> in the default (local) JNDI
- Lookup java:comp/env/<name> in the JNDI specified by the WSDL
- Lookup <name> in the default (local) JNDI
- Lookup <name> in the JNDI specified by the WSDL.
This allows a client administrator to override the JNDI definition specified
in the WSDL.
Jms binding
TODO
Jms property
<jms:property name="<name>" part="<part>" />
- this must go in the input or output section of the binding operation.
Output jms properties are not yet implemented in WSIF.
- the <name> may be the name of a property defined by JMS, or
the name of a property defined by the JMS implementation, or the name of
a user property.
- the <part> must be the name of a part in the message.
- JMS user properties that are objects are not implemented by WSIF.
- When using stubs to invoke WSIF, this property appears as a parameter
on the stub's signature, but will not appear on the web service's
method signature.
Jms property value
<jms:propertyValue name="<name>" type="<type>"
value="<value>" />
- this must go in either the <jms:address or in the input section
of the binding operation.
- the <name> may be the name of a property defined by JMS, or
the name of a property defined by the JMS implementation, or the name of
a user property.
- the <type> is the datatype of the <value> that hardcodes
the value of this property in the WSDL.
- JMS user properties that are objects are not implemented by WSIF.
JMS properties can also be set on the message context, without being
defined in the WSDL.
Jms fault, fault property and fault indicator
TODO