Please refer to the errata for this document, which may include normative corrections.
See also translations .
Copyright
©
2011
2012
W3C
®
(
MIT
,
ERCIM
,
Keio
),
All
Rights
Reserved.
W3C
liability
,
trademark
and
document
use
rules
apply.
This document specifies how SOAP binds to a messaging system that supports the Java Message Service (JMS) [ Java Message Service ]. Binding is specified for both SOAP 1.1 [ SOAP 1.1 ] and SOAP 1.2 [ SOAP 1.2 Messaging Framework ] using the SOAP 1.2 Protocol Binding Framework. This specification also describes how to use WSDL documents to indicate and control the use of this binding.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/ .
This
is
the
Proposed
Recommendation
of
the
SOAP
over
Java
Message
Service
1.0
specification.
It
has
been
produced
by
the
SOAP-JMS
Binding
Working
Group
,
which
is
part
of
the
W3C
Web
Services
Activity.
The
previous
version
of
this
document
was
not
a
Candidate
Recommendation.
The
document
is
moving
directly
from
Last
Call
Announcement
to
Call
for
Review
of
a
Proposed
Recommendation.
This
change,
which
was
referenced
in
the
previous
Status
of
this
Document
section,
was
made
because
the
move
back
to
Last
Call
was
done
mainly
to
change
a
namespace
that
was
missing
in
the
previous
LC-CR
move.
This
document
is
based
on
the
W3C
Submission
SOAP
over
Java(tm)
Message
Service
1.0.
A
list
of
changes
is
available
in
I
Change
Log
,
and
the
status
.
Only
editorial
changes
were
made
as
a
result
of
issues
raised
since
the
previous
version
can
be
seen
in
the
Working
Group's
disposition
of
comments
document
Proposed
Recommendation
phase
(See
diff
).
The
authors
of
this
document
consider
it
to
be
stable,
and
invite
reviewers
and
implementors
to
send
comments
to
the
public-soap-jms@w3.org
mailing
list
(
public
archive
).
W3C
Advisory
Committee
Representatives
are
invited
to
submit
their
formal
review
per
the
instructions
in
the
Call
for
Review
(see
Advisory
Committee
questionnaires
)
by
13
January
2012
.
Publication
as
a
Proposed
Recommendation
does
not
imply
endorsement
This
document
has
been
reviewed
by
W3C
Members,
by
software
developers,
and
by
other
W3C
groups
and
interested
parties,
and
is
endorsed
by
the
Director
as
a
W3C
Membership.
This
Recommendation.
It
is
a
draft
stable
document
and
may
be
updated,
replaced
used
as
reference
material
or
obsoleted
by
other
documents
at
any
time.
It
cited
from
another
document.
W3C's
role
in
making
the
Recommendation
is
inappropriate
to
cite
this
document
as
other
than
work
in
progress.
draw
attention
to
the
specification
and
to
promote
its
widespread
deployment.
This
enhances
the
functionality
and
interoperability
of
the
Web.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy .
1
Introduction
1.1
Background
1.2
Out
of
Scope
1.3
Context
1.4
Notational
Conventions
1.4.1
XML
Namespaces
1.5
Assertions
1.6
Conformance
2
The
SOAP/JMS
Underlying
Protocol
Binding
2.1
Introduction
2.2
Properties
Affecting
Binding
2.2.1
Connection
to
a
destination
2.2.2
JMS
Message
Header
properties
2.2.2.1
Setting
JMS
Message
Header
properties
2.2.3
JMS
Message
properties
2.2.3.1
Setting
JMS
Message
properties
2.2.4
Binding
of
Properties
to
URI
2.2.5
Other
Properties
2.3
Authentication
for
SOAP/JMS
2.4
The
JMS
Message
Body
2.4.1
Considerations
For
Using
TextMessage
2.5
Supported
Message
Exchange
Patterns
2.5.1
Support
for
Topic
destinations
2.6
Request-Response
Message
Exchange
Pattern
2.6.1
Behaviour
of
Requesting
SOAP
Node
2.6.1.1
Init
2.6.1.2
Requesting
2.6.1.3
Sending
+
Receiving
2.6.1.4
Success
and
Fail
2.6.2
Behaviour
of
Responding
SOAP
Node
2.6.2.1
Init
2.6.2.2
Receiving
2.6.2.3
Receiving
+
Sending
2.6.2.4
Success
and
Fail
2.7
One-way
Message
Exchange
Pattern
2.7.1
Behaviour
of
Sending
SOAP
Node
2.7.2
Behaviour
of
Receiving
SOAP
Node
2.8
Faults
3
WSDL
Usage
3.1
Overview
3.2
WSDL
1.1
Extensions
Overview
3.3
WSDL
1.1
Extensions
Detail
3.3.1
Example
3.3.2
WSDL
1.1
Transport
Identification
3.3.3
WSDL
1.1
SOAP
Action
3.3.4
Specifying
Properties
In
WSDL
1.1
3.3.5
Specifying
Properties
Via
the
JMS
URI
3.4
Properties
A
References
A.1
Normative
References
A.2
Informative
References
B
Schema
C
Complete
WSDL
1.1
Example
(Non-Normative)
D
SOAP/JMS
Underlying
Protocol
Binding
Examples
(Non-Normative)
D.1
SOAP
Request
without
attachments
D.2
SOAP
Request
with
attachments
E
JAX-WS
@BindingType
annotation
values
(Non-Normative)
F
WSDL
2.0
(Non-Normative)
F.1
WSDL
2.0
Extensions
Overview
F.2
WSDL
2.0
Extensions
Detail
F.2.1
Relationship
to
WSDL
2.0
Component
Model
F.2.1.1
Precedence
G
Acknowledgements
(Non-Normative)
H
Assertion
Summary
(Non-Normative)
I
Change
Log
(Non-Normative)
The work described in this and related documents is aimed at a set of standards for the transport of SOAP messages over JMS [ Java Message Service ]. The main purpose is to ensure interoperability between the implementations of different Web services vendors. This will also enable customers to implement their own Web services for part of their infrastructure, and to have this interoperate with vendor provided Web services. The main audience will be implementers of Web services stacks; in particular people who wish to extend a Web services stack with an implementation of SOAP/JMS. This will enable them to write a SOAP/JMS implementation that will interoperate with other SOAP/JMS implementations, and that will not be dependent on any specific JMS implementation.
A motivational example is a customer who has different departments that use Web services infrastructure from two different vendors, VendorA and VendorB. The customer has a need for reliable Web services interaction between the departments. Where both these vendors provide support for SOAP/JMS according to this standard, it ought be possible for a client running using VendorA to interoperate with a service using VendorB.
The standards will also be of interest to providers of Web services intermediary services such as routing gateways; or SOAP/HTTP to SOAP/JMS gateways. We do not discuss any details of how such gateways might be designed and configured, but adherence to the standard will help the gateway ensure proper interoperation with SOAP/JMS clients and services.
The documents cover three major areas.
The JMS calls that have to be made to construct and interpret SOAP/JMS messages in 2 The SOAP/JMS Underlying Protocol Binding .
The WSDL binding that describes SOAP/JMS services in 3 WSDL Usage .
How SOAP over JMS uses the Uniform Resource Identifier (URI) [ IETF RFC 3986 ] specification for JMS endpoints (JMS URI) [ IETF RFC 6167 ].
Note that the URI specification is in a separate document.
It is important to stress what this standard does NOT provide.
It does NOT provide any mechanism for interoperation between two different JMS providers. In the example above, VendorA and VendorB are different providers of a Web services infrastructure, but the customer still needs to use a single implementation of JMS at both client and service side.
It does NOT define any (wire) format for SOAP/JMS messages.
It does NOT define how the Web services themselves will be presented to the application programmer. For example, it does not describe how the programmer will characterise a one-way message.
This document specifies how SOAP binds to a messaging system that supports JMS. Binding is specified for both SOAP 1.1 [ SOAP 1.1 ] and SOAP 1.2 [ SOAP 1.2 Messaging Framework ] using the SOAP 1.2 Protocol Binding Framework.
The approach taken for this specification is to model it on the binding specifications that have been created for SOAP 1.2. The first of these was for a SOAP HTTP Binding, described in section 7, SOAP HTTP binding , [ SOAP 1.2 Part 2: Adjuncts ]. A second binding for Email [ SOAP 1.2 Email Binding ] is also available.
The keywords " MUST ", " MUST NOT ", " REQUIRED ", " SHALL ", " SHALL NOT ", " SHOULD ", " SHOULD NOT ", " RECOMMENDED ", " MAY ", and " OPTIONAL " in this document are to be interpreted as described in RFC 2119 [ IETF RFC 2119 ].
Parenthetic remarks about fault subcodes are mentioned throughout the document where a conformance issue could result in an error. The section 2.8 Faults discusses the treatment of these subcodes.
This specification uses a number of namespace prefixes throughout; they are listed in Table Prefixes and Namespaces used in this specification . Properties are named with XML qualified names . Property values are determined by the Schema type of the property, as defined in the specification which introduces the property. Note that the choice of any namespace prefix is arbitrary and not semantically significant (see [ XML Namespaces ]).
Prefix | Namespace | Specification |
---|---|---|
soapjms
|
http://www.w3.org/2010/soapjms/
|
Defined by this specification |
xsd
|
http://www.w3.org/2001/XMLSchema
|
[ XML Schema Structures ] |
wsdl11
|
http://schemas.xmlsoap.org/wsdl/
|
[ WSDL 1.1 ] |
wsdl20
|
http://www.w3.org/ns/wsdl
|
[ WSDL 2.0 Core Language ] |
wsoap
|
http://www.w3.org/ns/wsdl/soap
|
[ WSDL 2.0 Adjuncts ] |
wsdl11soap11
|
http://schemas.xmlsoap.org/wsdl/soap/
|
[ WSDL 1.1 ] |
wsdl11soap12
|
http://schemas.xmlsoap.org/wsdl/soap12/
|
[ WSDL 1.1 for SOAP 1.2 ] |
The
binding
defined
by
this
specification
is
identified
by
the
XML
namespace
URI
[
XML
Namespaces
]
http://www.w3.org/2010/soapjms/
.
It is the intent of the W3C SOAP JMS Binding Working Group that the SOAP/JMS XML namespace URI will not change arbitrarily with each subsequent revision of the corresponding XML Schema documents as the specifications transition through Candidate Recommendation, Proposed Recommendation and Recommendation status. However, should the specifications revert to Working Draft status, and a subsequent revision, published as a WD, CR or PR draft, results in non-backwardly compatible changes from a previously published WD, CR or PR draft of the specification, the namespace URI will be changed accordingly.
Editorial note: plh | 20080501 |
The above paragraph will need to be removed for the publication of the Recommendation. |
Assertions in this specification are marked by a dagger symbol (†) at the end of a sentence. Each assertion has been assigned a unique identifier that consists of a descriptive textual prefix and a unique numeric suffix. The numeric suffixes are assigned sequentially and never reused so there could be gaps in the sequence.
The assertions and their identifiers are summarized in section H Assertion Summary .
This specification defines two features, each of which has conformance criteria associated with it. A conforming implementation MUST work with JMS. †
Feature:
soapjms:Protocol
[
http://www.w3.org/2010/soapjms/Protocol
]
A conforming implementation MUST implement all the requirements of 2 The SOAP/JMS Underlying Protocol Binding . † Conforming implementations MUST implement all the requirements of the JMS URI. †
Feature:
soapjms:WSDL11
[
http://www.w3.org/2010/soapjms/WSDL11
]
Support for WSDL 1.1 is optional and as such an implementation MAY implement it. However, a conforming implementation of this feature MUST implement all the requirements of 3.3 WSDL 1.1 Extensions Detail . †
This section is normative.
This
section
describes
the
required
feature:
soapjms:Protocol
[
http://www.w3.org/2010/soapjms/Protocol
]
This section covers the SOAP/JMS binding, and implicitly the JMS calls that need to be made. One might think of the JMS calls as the SOAP/JMS message format. This is almost correct, but not completely. JMS is strictly an API and does not define a message format. Also, this document covers how the SOAP/JMS implementation connects to the JMS service and selects the appropriate destination.
This part covers details such as how JMS connections and destinations are handled. It also covers the message content, including how properties and headers such as priority, soapAction and targetService are handled within the SOAP/JMS implementation.
There are a number of properties that affect how the binding behaves. The following properties are grouped into related sets.
Some of the properties are optional. Properties can be obtained from a number of sources. If a given property is specified in more than one of these, the following list specifies the precedence: the first MUST be used in preference to the second. †
The environment (for example local program variables, system environment variables etc).
WSDL elements or attributes (including those specified in an endpoint URI within the WSDL). The precedence rules for properties specified in a WSDL document are defined in 3.3.4 Specifying Properties In WSDL 1.1 and 3.3.5 Specifying Properties Via the JMS URI .
If a given property is specified more than once in the JMS URI the last instance of the property MUST be used. †
Since the underlying JMS URI scheme defines an open-ended scheme for identifying and connecting to a destination, it is not possible to enumerate all the ways that connection information can be set. However, in the interest of specifying context information such as JNDI connection properties in such a way that they can apply to multiple services or endpoints, this specification enumerates specific properties.
Specifies the technique to use for looking up the given destination name.
MUST
be
specified
in
the
JMS
URI,
as
the
jms-variant
portion
of
the
syntax.
†
The
jms-variant
:
jndi
MUST
be
supported.
†
[
Definition
:
A
fault
MUST
be
generated
with
subcode
unsupportedLookupVariant
if
the
JMS
URI
specifies
a
lookupVariant
that
is
not
supported
by
the
implementation.
†
]
Specifies the name of the destination, for lookup as per the lookupVariant . If the variant is "jndi", this is the Java Naming and Directory Interface (JNDI) name of the destination (queue or topic).
MUST
be
specified
in
JMS
URI,
as
the
jms-dest
portion
of
the
syntax.
†
Specifies the JNDI name of the connection factory.
optional in URI, optional in WSDL, optional in environment
Specifies
the
fully
qualified
Java
class
name
of
the
InitialContextFactory
to
use.
This
is
mapped
to
the
java.naming.factory.initial
property
(defined
by
the
constant
javax.naming.Context.INITIAL_CONTEXT_FACTORY
)
to
be
set
in
the
HashMap
sent
to
an
InitialContext
constructor.
optional in URI, optional in WSDL, optional in environment
Specifies
the
JNDI
provider
URL,
which
is
mapped
to
the
java.naming.provider.url
property
(defined
by
the
constant
javax.naming.Context.PROVIDER_URL
)
to
be
set
in
the
HashMap
sent
to
an
InitialContext
constructor.
optional in URI, optional in WSDL, optional in environment
Provides
mechanism
to
set
additional,
arbitrary
JNDI
environment
properties,
other
than
jndiURL
and
jndiInitialContextFactory,
in
the
java.util.Hashtable
sent
to
the
InitialContext
constructor
for
the
JNDI
provider.
A property that can be specified more than once. When determining precedence rules for multiple occurrences of the jndiContextParameter property, the property is not considered to occur more than once unless the name attribute is identical in multiple jndiContextParameter properties.
Specifies
a
JNDI
property
name
and
value
pair
to
be
added
to
the
java.util.Hashtable
sent
to
the
InitialContext.
In
XML
form
the
JNDI
property's
name
is
defined
by
the
name
attribute
of
the
jndiContextParameter
element,
and
the
JNDI
property
value
is
defined
by
the
value
attribute.
When
indicated
in
a
URI,
the
name
of
the
JNDI
property
is
derived
from
dropping
the
'jndi-'
prefix
from
any
parameter
name
starting
that
way,
and
the
value
comes
from
the
parameter
value.
The
value
is
added
as
a
java.lang.String
.
optional in URI, optional in WSDL, optional in environment
<!-- Enable tracing for the ACME Corporation JNDI provider --> <soapjms:jndiContextParameter name="com.acme.jndi.enable.tracing" value="true" /> <!-- Include the standard JNDI property to ignore JNDI provider referrals --> <soapjms:jndiContextParameter name="java.naming.referral" value="ignore" />
This set of properties provide information that will set the values of corresponding JMS Header fields. This specification assumes that the JMS provider validates the values set for the respective message header properties, rather than being explicitly constrained by this specification.
indicates whether the request message is persistent or not. The valid values are "PERSISTENT" and "NON_PERSISTENT". The default value is "PERSISTENT" (defaulted by JMS)
optional in URI, optional in WSDL, optional in environment
if
specified
MUST
appear
in
the
JMS
message
in
the
header
named
JMSDeliveryMode
.
If
the
value
of
this
property
is
"PERSISTENT"
then
the
JMSDeliveryMode
integer
value
MUST
be
set
to
DeliveryMode.PERSISTENT
.
If
the
value
of
this
property
is
"NON_PERSISTENT"
then
the
JMSDeliveryMode
integer
value
MUST
be
set
to
DeliveryMode.NON_PERSISTENT
.
†
the lifetime, in milliseconds, of the request message. A value of 0 indicates an infinite lifetime. The default value is 0 (defaulted by JMS).
optional in URI, optional in WSDL, optional in environment.
if
specified,
this
MUST
be
used
to
generate
the
value
of
the
JMS
header
JMSExpiration
.
†
the JMS priority associated with the request message. Valid values are integers between 0 (lowest priority) and 9 (highest priority). The default value is 4 (defaulted by JMS).
optional in URI, optional in WSDL, optional in environment
if
specified,
MUST
appear
in
the
JMS
message
in
the
header
named
JMSPriority
.
†
Specifies the name of the destination to which a response message will be sent. If the replyToName property has a value it is used to lookup a destination using the lookupVariant . If the variant is "jndi", this is the Java Naming and Directory Interface (JNDI) name of the destination (queue or topic). If the variant is "queue" or "topic", this refers to the name of a JMS queue.
optional in URI, optional in WSDL, optional in environment
if
specified,
this
MUST
be
used
to
derive
the
value
to
be
used
in
the
JMS
header
JMSReplyTo
.
†
Specifies the name of the topic destination to which a response message will be sent.
as defined by [ IETF RFC 6167 ], the topicReplyToName only makes sense if the URI variant is "queue" or "topic".
if the replyToName is specified in the URI, WSDL, or environment, topicReplyToName is not relevant and MUST be ignored.
optional in URI, optional in WSDL, optional in environment
if
specified
and
if
relevant,
this
MUST
be
used
to
derive
the
value
to
be
used
in
the
JMS
header
JMSReplyTo
.
†
This section is non-normative and is intended to give an example of how a JMS Message Header property can be set.
import java.naming.Context; import javax.jms.DeliveryMode; import javax.jms.Destination; import javax.jms.Message; import javax.jms.MessageProducer; ... class ... { // add appropriate error checking for your use.... public void someMethod(Context ctx, MessageProducer producer, Message jmsMessage, String deliveryModeStr, String replyToName, int priority, long timeToLive) { // Set the reply destination, first looking it up using JNDI Destination replyDestination = ctx.lookup(replyToName); jmsMessage.setJMSReplyTo(replyDestination); // set the delivery mode to the appropriate constant value. int deliveryMode = deliveryModeStr.equals("PERSISTENT") ? DeliveryMode.PERSISTENT: DeliveryMode.NON_PERSISTENT; producer.setDeliveryMode( deliveryMode ); // set the default priority on the producer. producer.setPriority(priority); // set when the message is set to expire. producer.setTimeToLive(timeToLive); // and finally, send the message. producer.send(jmsMessage); // Alternately, instead of changing the producer's default settings, the // header properties could be set on a per-message basis by passing them // to the MessageProducer.send() method, like so: // producer.send(jmsMessage, deliveryMode, priority, timeToLive); } }
Used by the service implementation to dispatch the service request.
optional in URI
[
Definition
:
if
specified
MUST
appear
in
the
JMS
message
in
the
JMS
property
named
SOAPJMS_targetService
.
Use
fault
subcode
missingTargetService
if
specified
and
SOAPJMS_targetService
does
not
appear.
†
]
Specifies the version of SOAP JMS binding that is being used.
fixed
value
"1.0"
in
the
implementation,
MUST
appear
in
a
JMS
property
named
SOAPJMS_bindingVersion
.
†
[ Definition : A fault MUST be generated with subcode unrecognizedBindingVersion if the value of the soapjms:bindingVersion property does not match the fixed value. † ]
Note
that
the
contentType
value
also
indicates
the
MIME
type
of
the
primary
message
payload.
This
message
property,
then,
identifies
whether
the
message
payload
uses
SOAP
1.1,
SOAP
1.2,
SOAP
Messages
With
Attachments
[
SOAP
Messages
with
Attachments
]
or
MTOM
[
SOAP
1.1
Binding
for
MTOM
1.0
]
[
SOAP
MTOM
]
as
the
primary
payload.
Describes the content of the SOAP message, this has the same values as the MIME Content-Type specified for a SOAP message over HTTP [ IETF RFC 2045 ].
If
the
value
of
the
property
is
text/xml
or
application/soap+xml,
a
charset
parameter
might
be
present;
if
the
value
of
the
property
is
multipart/related,
a
type
parameter
might
be
present.
[
Definition
:
If
the
charset
parameter
is
specified,
it
is
checked
to
ensure
that
it
matches
the
encoding
value
from
the
supplied
XML.
A
fault
MUST
be
generated
with
subcode
contentTypeMismatch
if
the
encoding
values
do
not
match.
†
]
The charset parameter is optional and can take the values "utf-8" or "utf-16". If the charset parameter is omitted, the character set rules for freestanding [ XML 1.0 ] apply to the body of the JMS message.
[
Definition
:
The
contentType
value
MUST
appear
in
the
JMS
message
in
the
JMS
property
named
SOAPJMS_contentType
.
A
fault
MUST
be
generated
with
subcode
missingContentType
if
the
SOAPJMS_contentType
property
is
missing.
†
]
As with SOAP/HTTP
Optional in WSDL, optional in environment
[
Definition
:
If
specified
MUST
appear
in
the
JMS
message
in
the
JMS
property
named
SOAPJMS_soapAction
.
Fault
subcode
missingSoapAction
MAY
be
used
if
SOAPJMS_soapAction
does
not
appear.
†
]
[
Definition
:
If
using
SOAP
1.2,
and
the
contentType
property
has
an
action
parameter,
that
parameter
value
is
compared
with
the
SOAPJMS_soapAction
value.
A
fault
MUST
be
generated
with
fault
subcode
mismatchedSoapAction
if
the
SOAP
1.2
action
does
not
match
the
SOAPJMS_soapAction
value.
†
]
This property indicates whether a SOAP/JMS message corresponds to a SOAP fault.
For
senders,
this
property
is
set
to
true
when
responding
with
a
SOAP
fault.
When
this
property
is
true
,
the
sending
software
MUST
set
a
boolean
JMS
Message
property
named
SOAPJMS_isFault
with
a
value
of
true
,
as
in:
Message.setBooleanProperty("SOAPJMS_isFault",
true)
.
†
For
receivers,
this
property
is
derived
from
the
boolean
JMS
Message
property
named
SOAPJMS_isFault
—
if
present
and
containing
a
value
of
true
,
the
value
of
soapjms:isFault
is
true
.
If
omitted,
or
present
with
a
value
of
false
,
the
value
of
soapjms:isFault
is
false
.
Specifies the JMS URI of the service. The client MUST create the requestURI by taking the supplied URI, leaving the destinationName as-is, and removing the targetService and replyToName query parameters if they are specified. The client SHOULD also remove deliveryMode, jndiConnectionFactoryName, jndiInitialContextFactory, jndiURL, jndiContextParameter, timeToLive, and priority properties. The client MAY remove other query parameters not explicitly mentioned above (for example client security related properties). †
A required property
[
Definition
:
Appears
in
the
JMS
message
in
the
JMS
property
named
SOAPJMS_requestURI
.
A
fault
MUST
be
generated
with
fault
subcode
missingRequestURI
if
the
SOAPJMS_requestURI
property
is
missing
from
the
message.
†
]
[
Definition
:
A
fault
MUST
be
generated
with
subcode
malformedRequestURI
when
the
SOAPJMS_requestURI
violates
the
expected
syntax.
†
].
[
Definition
:
A
fault
MUST
be
generated
with
subcode
targetServiceNotAllowedInRequestURI
when
targetService
parameter
is
included
in
the
SOAPJMS_requestURI
).
†
]
Identifies the transformation that has been applied to the message payload body. Contains one of the values defined by IANA for the Content-Coding values of [ IANA HTTP PARAMS ]. Defaults to "identity" if the property is not present.
Corresponds to the JMS Message property named SOAPJMS_contentEncoding
[ Definition : If the content encoding is specified, it is checked to ensure that it matches the content encoding values supported. A fault MUST be generated with subcode contentEncodingNotSupported if the encoding values do not match. † ]
Restriction: the meaning of the property is not defined for composite messages (messages with a Content-Type of "multipart" or "message"), only for discrete messages (Content-Type "application" or "text", for this specification).
This section is non-normative and is intended to give an example of how a JMS Message property can be set.
import javax.jms.Message; import javax.mail.internet.ContentType; ... class ... { public void anotherMethod(Message jmsMessage, String targetService, ContentType type, URI requestURI) { jmsMessage.setStringProperty("SOAPJMS_targetService", targetService); // at least for this definition of the binding, the version here is always "1.0" jmsMessage.setStringProperty("SOAPJMS_bindingVersion", "1.0"); // set the content type using the ContentType value already defined by javax.mail. jmsMessage.setStringProperty("SOAPJMS_contentType", type.toString() ); //According to Basic Profile SOAP 1.2 HTTP binding does not use the SOAPAction header //However the soapAction is mandatory with SOAP 1.1 hence setting to empty string jmsMessage.setStringProperty("SOAPJMS_soapAction", ""); // for the first message in an exchange, not a fault1 jmsMessage.setBooleanProperty("SOAPJMS_isFault", false);jmsMessage.setStringProperty("SOAPJMS_requestURI, requestURI.toString() );jmsMessage.setStringProperty("SOAPJMS_requestURI", requestURI.toString() ); } }
Implementations of this specification need to allow for the setting of the above properties. Some properties, as mentioned above can be inferred from context, or provided by the application environment. Some might be put into WSDL. In many cases, it is desirable to represent those properties as part of a URL-like representation. In particular, this section describes how the properties above are used in the URI. Note that the URI scheme also defines query parameters, and where the query parameter names are the same, the same meaning is intended here.
For
brevity,
properties
are
shown
without
the
SOAPJMS
prefix.
The
"URI
representation"
column
describes
how
the
property
is
carried
in
the
URI.
Specification Property | URI Representation |
---|---|
deliveryMode |
as
deliveryMode
query
parameter
|
destinationName |
as
jms-dest
portion
of
URI
syntax
|
jndiConnectionFactoryName |
as
jndiConnectionFactoryName
query
parameter
|
jndiInitialContextFactory |
as
jndiInitialContextFactory
query
parameter
|
jndiURL |
as
jndiURL
query
parameter
|
jndiContextParameter | as a query parameter combining the string "jndi-" with the jndiContextParameter's name attribute |
replyToName |
as
replyToName
query
parameter
|
topicReplyToName |
as
topicReplyToName
query
parameter
|
priority |
as
priority
query
parameter
|
targetService |
as
targetService
query
parameter
|
timeToLive |
as
timeToLive
query
parameter
|
Security, and in particular authentication, is a critical concern in most if not all environments where this binding will be utilized. There are at least two places where authentication might need to occur — 1) authenticating to the registry (i.e. JNDI) where JMS Destinations are located, and 2) authenticating to the JMS system itself. Credentials such as usernames and passwords might be required to access directories and to obtain JMS Connections from ConnectionFactories. This specification does not mandate how an implementation might obtain these credentials, although typically they can be available as API parameters, environment variables, or in thread context storage.
Implementers of this binding are encouraged to consider the most appropriate way to expose authentication functionality to their users such that it meshes smoothly with the models exposed by their environments.
Note:
Although technically possible, the specification of userid and/or password related properties in the URI is not recommended.
The
contents
of
the
JMS
Message
body
MUST
be
the
SOAP
payload
as
a
JMS
BytesMessage
or
TextMessage
.
†
While
the
requesting
node
can
support
either
BytesMessage
or
TextMessage
,
the
receiving
node
MUST
support
both
BytesMessage
and
TextMessage
.
†
If
the
message
is
formatted
as
a
JMS
BytesMessage
,
then
the
sender
and
receiver
MUST
use
the
writeBytes()
and
readBytes()
methods,
respectively.
†
[
Definition
:
A
fault
MUST
be
generated
with
subcode
unsupportedJMSMessageFormat
when
the
arriving
message
format
is
not
BytesMessage
or
TextMessage
.
†
]
After
being
decoded
according
to
the
contentEncoding
property,
the
bytes
or
characters
of
the
JMS
Message
payload
correspond
to
the
MIME
format
as
indicated
by
the
definition
of
the
contentType
property.
In
this
way,
the
SOAP
node
determines
the
proper
formatting
of
the
SOAP
payload
irrespective
of
the
underlying
JMS
message
type,
and
specifies
an
appropriate
value
for
the
contentType
property
which
describes
it
to
the
receiving
SOAP
node.
Specifically,
if
the
payload
is
formatted
as
a
MIME
multipart
message,
then
the
first
byte
or
character
encountered
in
the
JMS
Message
body
MUST
be
the
start
of
the
MIME
boundary
for
the
start
of
the
first
part
—
what
MIME
Part
One
[
IETF
RFC
2045
]
section
2.5
calls
a
"Body
Part".
†
If
the
message
is
formatted
as
"
text/xml
"
or
"
application/soap+xml
",
then
the
first
byte
or
character
of
the
JMS
Message
body
MUST
be
the
start
of
a
conforming
XML
document.
†
While
the
use
of
TextMessage
might
be
attractive
in
some
scenarios,
there
are
some
considerations
that
go
along
with
it.
Since the message is already in text format the "encoding" attribute in the XML header has to be ignored.
Messages
with
attachments
will
need
to
use
Content-Transfer-Encoding
for
attachment
parts.
Depending
on
the
range
of
characters
used
by
the
SOAP
message,
using
TextMessage
might
more
than
double
the
memory
requirements
to
receive
a
message.
The impact on network consumption ought to be measured for particular scenarios and JMS providers.
Use of the contentEncoding property is not defined, since the underlying message payload is not raw bytes.
Since
binary
data
needs
to
be
encoded
to
be
carried
as
text,
SOAP
attachments
via
a
TextMessage
have
the
same
concerns
as
the
MIME
specification
carrying
messages
over
a
7-bit
channel
[
IETF
RFC
2045
].
The
attachments
will
need
to
be
encoded
using
one
of
the
Content-Transfer-Encoding
options
specified
by
MIME.
If
the
data
is
truly
binary,
such
as
a
picture,
a
base64
encoding
might
be
appropriate.
In
typical
scenarios,
using
TextMessage
will
almost
certainly
dramatically
increase
the
memory
requirements.
This
happens
as
a
consequence
of
the
JMS
API
TextMessage.getText()
,
which
returns
a
Java
String.
The
Java
String
class
uses
a
UTF-16
representation
to
represent
the
data.
This
in
memory
representation
will
generally
be
larger
than
the
corresponding
BytesMessage
representation.
For
example,
if
the
message
contains
only
US-ASCII
characters,
and
is
encoded
into
XML
using
UTF-8,
the
Java
String
representation
of
the
message
will
take
exactly
twice
as
much
memory.
The
in
memory
UTF-16
representation,
coupled
with
base64
encoding
of
an
attachment,
will
consume
much
more
memory
than
the
equivalent
BytesMessage
payload.
To
begin
with,
a
base64
conversion
yields
a
ratio
of
33%
more
characters
than
bytes.
Combined
with
a
UTF-16
representation
of
those
characters,
the
bytes
required
in
memory
will
be
167%
more
than
the
original
binary
data
(an
8/3
ratio).
As
a
consequence,
carefully
consider
any
scenarios
that
use
attachments
with
a
TextMessage
.
As
significant
as
the
concerns
around
memory
consumption
might
be,
the
effects
on
network
payload
size
are
more
difficult
to
predict.
Since
the
JMS
API
does
not
specify
exactly
how
messages
are
handled,
the
effects
on
network
traffic
are
JMS
provider-specific.
A
JMS
provider
might
be
encoding
a
TextMessage
with
UTF-8,
and
could
further
compress
such
messages.
With
these
two
techniques,
the
data
transferred
via
network
calls
could
end
up
being
no
larger
than
a
corresponding
BytesMessage
representation,
even
with
attachments.
However,
only
actual
monitoring
will
determine
specific
effects
of
specific
scenarios.
Clients
of
this
specification
who
are
using
TextMessage
are
encouraged
to
do
such
monitoring.
In the case of SOAP 1.1 there is no formal specification of Message Exchange Patterns. A conforming SOAP-JMS Binding instance MUST support both the generic "request/response" and "one-way" patterns as specified in this document. †
In the case of SOAP 1.2 a conforming SOAP-JMS Binding instance MUST support the following message exchange patterns: †
http://www.w3.org/2003/05/soap/mep/request-response/
(defined
in
Request-Response
Message
Exchange
Pattern
)
http://www.w3.org/2006/08/soap/mep/one-way/
(defined
in
[
SOAP
1.2
Part
3:
One-Way
MEP
])
There are tables of JMS properties, and explanations of their values, in the remainder of this section. Note that only the relevant properties (i.e. ones affected by this specification) have been included — other properties will continue to follow the normal JMS specification. For instance, the JMSMessageID header will be present on all messages, and automatically generated by the underlying JMS implementation.
Topics can be used as destinations for SOAP messages over JMS. However, due to the potential complexities around how topics might interact with message-exchange patterns, this specification provides no guidelines as to how that message exchange might work. In particular, the "request-response" exchange clearly means something different when an unknown number of responses might be received. Even the "one-way" exchange over a JMS topic differs in subtle ways from the same exchange over HTTP, including the fundamental question of whether the message is received at all, by any listeners.
For these reasons, implementers and clients of this specification are advised to use caution when dealing with JMS topics. We strongly encourage implementers to carefully document their choices around the use and support of topic destinations.
For binding instances using the Request-Response Message Exchange Pattern :
A
SOAP
Node
instantiated
at
the
JMS
interface
can
take
on
the
role
(i.e.
the
property
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role
)
of
RequestingSOAPNode
.
A
SOAP
Node
instantiated
at
the
JMS
interface
can
take
on
the
role
(i.e.
the
property
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role
)
of
RespondingSOAPNode
.
The
remainder
of
this
section
consists
of
descriptions
of
the
MEP
state
machine.
In
the
state
descriptions
following,
the
states
are
defined
as
values
for
the
property
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/State
.
Failure
reasons
as
specified
in
the
tables
represent
values
of
the
property
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason
-
their
values
are
qualified
names.
If
an
implementation
enters
the
"Fail"
state,
the
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason
property
will
contain
the
value
specified
for
the
particular
transition.
In the "Init" state, a JMS request is formulated and transmission of the request is initiated. The message is created as a JMS BytesMessage or TextMessage as defined in 2.4 The JMS Message Body .
A number of the message header properties are implicitly created by the use of the JMS API. The following table shows how the binding properties described earlier explicitly affect the message constructed.
Field | Value Set by Conforming Client |
---|---|
JMS Message Header | |
JMSDeliveryMode | the value of the deliveryMode property or not set if not specified |
JMSExpiration | calculated from the value of the timeToLive property or not set if not specified |
JMSPriority | the value of the priority property or not set if not specified |
JMSDestination | derived from the destinationName property |
JMSReplyTo | if the replyToName property is specified, this is the JMS Destination object derived from that name. Otherwise the implementation has to determine the reply queue, and use the JMS Destination object which represents that queue; the queue can be a temporary queue generated as described in the JMS specification. |
JMS Message properties | |
SOAPJMS_requestURI | this is derived from the requestURI property |
SOAPJMS_bindingVersion | this is copied from the bindingVersion property |
SOAPJMS_soapAction | the value of the soapAction property or not set if not specified |
SOAPJMS_targetService | the value of the targetService property or not set if not specified |
SOAPJMS_contentType | inferred from the SOAP Envelope and presence of attachments |
JMS Message Body | |
body |
A
SOAP
envelope
is
serialized
according
to
the
media
type
specified
in
the
JMS
Message
property
SOAPJMS_contentType
|
In
the
"Requesting"
state,
sending
of
the
request
continues
while
waiting
for
the
start
of
the
correlated
response
message.
A
correlated
response
message
is
defined
as
follows:
If
the
JMSCorrelationID
header
field
is
set
in
the
request
message
then
a
correlated
response
message
is
one
where
the
value
of
the
JMSCorrelationID
header
field
is
the
same
as
the
value
of
the
JMSCorrelationID
of
the
request
message.
If
the
JMSCorrelationID
header
field
is
not
set
in
the
request
message
then
a
correlated
response
message
is
one
where
the
value
of
the
JMSCorrelationID
header
field
is
the
same
as
the
value
of
the
JMSMessageID
header
of
the
request
message.
The
JMSReplyTo
header
MUST
be
assigned
a
value.
†
The
response
message
will
be
received
on
the
JMS
Destination
specified
in
the
JMSReplyTo
header
above,
and
that
Destination
is
where
implementations
need
to
listen.
If a correlated response message is received then a transition to "Sending + Receiving" is made.
If,
for
whatever
reason
(for
example
a
timeout),
no
correlated
response
message
is
received
then
a
failure
reason
receptionFailure
is
set
and
a
transition
to
"Fail"
is
made.
Receive
a
correlated
message
body
that
is
assumed
to
contain
a
SOAP
envelope
serialised
according
to
the
rules
for
carrying
a
SOAP
message
in
the
media
type
specified
in
the
JMS
Message
property
SOAPJMS_contentType
.
If a well formed response message is received a transition to "Success" is made, and otherwise transition to "Fail".
Receive and validate the inbound request message.
If a well formed request message is received a transition to the local SOAP node is made followed by a transition to the "Receiving" state.
If a malformed request message is received a transition to "Fail" is made.
Waiting for Response Message to become available in Message Exchange Context as a result of processing the Request Message (note Request Message fully received on exit from Init state).
Completing Request Message reception and Response Message transmission. (Response Message sent on exit from Receiving State).
The
JMS
response
is
formulated
and
transmission
of
the
response
is
initiated.
The
Response
Message
MUST
be
created
using
the
same
type
as
the
corresponding
Request
Message,
i.e.
as
a
JMS
BytesMessage
or
TextMessage
.
†
The
message
MUST
be
sent
to
the
JMS
Destination
in
the
JMSReplyTo
header
of
the
Request
Message.
†
If
the
JMSCorrelationID
is
set
in
the
request
message,
then
the
JMSCorrelationID
header
field
in
the
response
message
MUST
be
set
to
the
same
value
as
the
JMSCorrelationID
header
field
in
the
request
message.
If
the
JMSCorrelationID
header
field
is
not
set
in
the
request
message,
then
the
JMSCorrelationID
header
field
in
the
response
message
MUST
be
set
to
the
value
of
the
JMSMessageID
header
in
the
request
message.
†
A number of the message header properties are implicitly created by the use of the JMS API. The following table shows how the binding properties described earlier explicitly affect the message constructed.
Field | Value Set by Conforming Client |
---|---|
JMS Message Header | |
JMSDeliveryMode | this ought to be the same as that specified on the request |
JMSExpiration | this is derived from the request. It is up to the responding node to decide whether to degrade for processing time. |
JMSCorrelationID |
this
is
copied
from
the
request
JMSCorrelationID
if
it
is
set,
or
the
request
JMSMessageID
if
the
request
JMSCorrelationID
is
not
set
|
JMSDestination |
this
is
copied
from
the
JMSReplyTo
property
in
the
request
|
JMS Message properties | |
SOAPJMS_requestURI | this is copied from the requestURI property in the request message |
SOAPJMS_bindingVersion | this is copied from the bindingVersion property |
SOAPJMS_contentType | inferred from the SOAP Envelope and presence of attachments |
SOAPJMS_isFault |
set
to
true
if
the
response
is
a
SOAP
fault,
otherwise
it
can
be
absent
|
JMS Message Body | |
body |
A
SOAP
envelope
is
serialized
according
to
the
media
type
specified
in
the
JMS
Message
property
SOAPJMS_contentType
.
|
If a response message is successfully sent a transition to the "Success" state is made.
If
there
is
a
failure
to
send
a
response
message
then
failure
reason
transmissionFailure
is
set
and
a
transition
to
"Fail"
is
made.
The SOAP One-way MEP defines properties for the exchange of a SOAP/JMS message which does not solicit a response. For JMS messages sent to a Queue destination this MEP results in a SOAP message which will be received by zero or one receiver. For JMS messages sent to a Topic destination this MEP results in SOAP message(s) which will be received by zero, one, or many receivers.
This
message
exchange
pattern
is
identified
by
the
URI
http://www.w3.org/2006/08/soap/mep/one-way/
.
For binding instances conforming to this specification:
A
SOAP
Node
instantiated
at
the
sending
JMS
interface
takes
on
the
role
(i.e.
the
property
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role
,
defined
in
Table
2,
Property
definitions
supporting
the
description
of
MEPs
),
of
SendingSOAPNode
.
A
SOAP
Node
instantiated
at
the
receiving
JMS
interface
takes
on
the
role
(i.e.
the
property
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role
)
of
ReceivingSOAPNode
.
The
remainder
of
this
section
consists
of
descriptions
of
the
MEP.
Failure
reasons
represent
values
of
the
property
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason
—
their
values
are
qualified
names.
If
a
MEP
instance
terminates
with
a
fault,
then
the
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason
property
will
contain
an
value
identifying
the
fault.
The message is created as a JMS BytesMessage or TextMessage as defined in 2.4 The JMS Message Body
The
JMSReplyTo
header
MUST
NOT
be
assigned
a
value.
†
If
the
Sender
receives
a
message
transmission
failure,
then
the
http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason
property
is
set
to
transmissionFailure
and
the
message
exchange
is
terminated
with
a
fault.
A number of the message header properties are implicitly created by the use of the JMS API. The following table shows how the binding properties described earlier explicitly affect the message constructed.
Field | Value Set by Conforming Client |
---|---|
JMS Message Header | |
JMSDeliveryMode | the value of the deliveryMode property or not set if not specified |
JMSExpiration | calculated from the value of the timeToLive property or not set if not specified |
JMSPriority | the value of the priority property or not set if not specified |
JMSDestination | derived from the destinationName property |
JMS Message properties | |
SOAPJMS_requestURI | this is derived from the requestURI property |
SOAPJMS_bindingVersion | this is copied from the bindingVersion property |
SOAPJMS_soapAction | the value of the soapAction property or not set if not specified |
SOAPJMS_targetService | the value of the targetService property or not set if not specified |
SOAPJMS_contentType | inferred from the SOAP Envelope and presence of attachments. |
JMS Message Body | |
body |
A
SOAP
envelope
is
serialized
according
to
the
media
type
specified
in
the
JMS
Message
property
SOAPJMS_contentType
.
|
The receiving node follows the rules defined in [ SOAP 1.2 Part 3: One-Way MEP ].
The SOAP fault subcodes listed throughout this document, and consolidated here, include:
The
above
subcodes
are
the
local
name
in
the
soapjms
namespace,
appearing,
for
example,
as
soapjms:malformedRequestURI
.
In
SOAP
1.2,
the
subcodes
above
are
used
as-is
in
the
env:Value
element
of
the
env:Subcode
for
a
SOAP
Fault.
The
following
shows
an
example
of
a
SOAP
1.2
Fault
payload
with
the
contentTypeMismatch
subcode:
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope" xmlns:soapjms="http://www.w3.org/2010/soapjms/" xmlns:xml="http://www.w3.org/XML/1998/namespace"> <env:Body> <env:Fault> <env:Code> <env:Value>env:Sender</env:Value> <env:Subcode> <env:Value>soapjms:contentTypeMismatch</env:Value> </env:Subcode> </env:Code> <env:Reason> <env:Text xml:lang="en">The content type of the JMS payload does not match the XML.</env:Text> </env:Reason> </env:Fault> </env:Body> </env:Envelope>
This
specification
does
not
mandate
any
particular
text
for
the
env:Text
child
element
of
the
env:Reason
element.
The
SOAP
1.1
specification
does
not
support
subcodes
directly.
In
that
scenario,
the
faultcode
element
uses
a
QName
that
matches
the
subcode
for
SOAP
1.2.
The
faultstring
element
can
contain
textual
fault
information.
The
same
error
as
above,
shown
in
SOAP
1.1:
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <env:Fault xmlns:soapjms="http://www.w3.org/2010/soapjms/"> <faultcode>soapjms:contentTypeMismatch</faultcode> <faultstring>The content type of the JMS payload does not match the XML.</faultstring> </env:Fault> </env:Body> </env:Envelope>
These next sections describe how to indicate the use of SOAP over JMS in WSDL. We begin with complete examples, and then describe the individual pieces and parts in the sections which follow.
The section 2 The SOAP/JMS Underlying Protocol Binding above contains the actual rules by which SOAP messages are sent and received using JMS. This section indicates how WSDL can be used to indicate the use and control the operation of that binding.
For general information on extending SOAP bindings in WSDL, please refer to section 3, SOAP Binding , WSDL 1.1 . For information about accepted SOAP 1.2 bindings, see [ WSDL 1.1 for SOAP 1.2 ].
The
transport
attribute
of
the
wsdl11soap11:binding
or
wsdl11soap12:binding
element
gets
a
new
URL
reflecting
a
JMS
transport.
Allows use of SOAPAction header, even though it is explicitly disallowed by WSDL specification.
Defines how to set various properties to control the behavior (connection parameters, runtime setting) of the binding.
Locates the service using a JMS URI.
This section is normative.
This
section
describes
the
optional
feature:
soapjms:WSDL11
[
http://www.w3.org/2010/soapjms/WSDL11
].
To
focus
on
the
salient
details,
all
of
the
WSDL
examples
in
this
section
show
only
a
portion
of
a
WSDL
file
in
question.
The WSDL 1.1 specification includes in section 1.2, WSDL Document Example , the example Example 1 SOAP 1.1 Request/Response via HTTP .
The following example illustrates a new service description which assumes the original service available over HTTP is also made available over JMS.
Lines
14-33
are
a
new
binding
for
specifying
that
JMS
is
to
be
used,
line
15
shows
the
transport
URI
in
<wsdl11soap11:binding>
,
and
lines
17-22
show
the
extension
properties
in
the
<wsdl11soap11:binding>
.
Lines
40-42
are
also
additions
to
specify
the
location
at
which
this
new
implementation
exists.
Line
41
shows
the
JMS
URI
Scheme
jms:
in
the
<wsdl11soap11::address>
.
1 <wsdl11:binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType"> 2 <wsdl11soap11:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> 3 <wsdl11:operation name="GetLastTradePrice"> 4 <wsdl11soap11:operation soapAction="http://example.com/GetLastTradePrice"/> 5 <wsdl11:input> 6 <wsdl11soap11:body use="literal"/> 7 </wsdl11:input> 8 <wsdl11:output> 9 <wsdl11soap11:body use="literal"/> 10 </wsdl11:output> 11 </wsdl11:operation> 12 </wsdl11:binding> 13 14 <wsdl11:binding name="StockQuoteSoapJMSBinding" type="tns:StockQuotePortType" xmlns:soapjms="http://www.w3.org/2010/soapjms/"> 15 <wsdl11soap11:binding style="document" transport="http://www.w3.org/2010/soapjms/"/> 16 17 <!-- We want this binding to use a particular CF class --> 18 <soapjms:jndiConnectionFactoryName> 19 sample.jms.ConnectionFactory 20 </soapjms:jndiConnectionFactoryName> 21 <!-- Specify PERSISTENT delivery mode --> 22 <soapjms:deliveryMode>PERSISTENT</soapjms:deliveryMode> 23 24 <wsdl11:operation name="GetLastTradePrice"> 25 <wsdl11soap11:operation soapAction="http://example.com/GetLastTradePrice"/> 26 <wsdl11:input> 27 <wsdl11soap11:body use="literal"/> 28 </wsdl11:input> 29 <wsdl11:output> 30 <wsdl11soap11:body use="literal"/> 31 </wsdl11:output> 32 </wsdl11:operation> 33 </wsdl11:binding> 34 35 <wsdl11:service name="StockQuoteService"> 36 <wsdl11:documentation>My first service</wsdl11:documentation> 37 <wsdl11:port name="StockQuotePort" binding="tns:StockQuoteSoapBinding"> 38 <wsdl11soap11:address location="http://example.com/stockquote"/> 39 </wsdl11:port> 40 <wsdl11:port name="StockQuotePort_jms" binding="tns:StockQuoteSoapJMSBinding"> 41 <wsdl11soap11:address location="jms:jndi:myQueue?targetService=stockquote &priority=8&replyToName=interested&userprop=mystuff"/> 42 </wsdl11:port> 43 </wsdl11:service>
The key points to notice are:
The
transport
URI
in
<wsdl11soap11:binding>
(line
15)
The
jms:
URI
in
the
<wsdl11soap11:address>
(line
41)
The
extension
properties
in
the
<wsdl11soap11:binding>
(lines
17-22)
For
each
of
SOAP
1.1
and
SOAP
1.2,
the
transport
attribute
of
the
wsdl11soap11:binding
element,
and
the
wsdl11soap12:binding
element,
respectively,
indicate
the
transport
value.
To
indicate
that
this
SOAP/JMS
binding
is
in
use,
the
transport
attribute
MUST
be
set
to
the
value
http://www.w3.org/2010/soapjms/
.
†
The
wsdl11soap11:operation
portion
of
the
WSDL
specification
explicitly
disallows
use
of
the
soapAction
attribute
in
non-HTTP
bindings.
This
specification
supersedes
that
requirement,
and
allows
the
use
of
soapAction
in
the
wsdl11soap11:operation
element
for
SOAP/JMS
bindings.
This
value
corresponds
to
the
property
soapAction
.
Various
JMS
properties
described
in
the
SOAP/JMS
binding
specification
can
be
set
in
four
places
in
the
WSDL
—
the
binding,
the
service,
the
port,
and
the
URI
for
the
port.
Values
specified
at
the
service
will
propagate
to
all
ports.
Values
specified
at
the
binding
will
propagate
to
all
ports
using
that
binding.
For
example,
the
jndiInitialContextFactory
can
be
indicated
for
a
wsdl11:service
,
and
it
is
then
implied
for
all
of
the
contained
wsdl11:port
elements.
If a property is specified at multiple levels within the WSDL document, the most specific setting MUST take precedence (URI specified in the address element's location attribute first, then other properties set on the port, then service, then binding). †
In
the
following
example,
notice
the
timeToLive
property
—
for
the
quickPort
port,
the
value
will
be
10
(specified
at
the
port
level).
For
the
slowPort
port,
the
value
will
be
100
(specified
at
the
service
level).
The
setting
in
the
binding
is,
in
this
example,
always
overridden.
<wsdl11:binding name="exampleBinding"> ... <soapjms:timeToLive>200</soapjms:timeToLive> </wsdl11:binding> <wsdl11:service name="exampleService"> <soapjms:jndiInitialContextFactory> com.example.jndi.InitialContextFactory </soapjms:jndiInitialContextFactory> <soapjms:timeTolive>100</soapjms:timeToLive> ... <wsdl11:port name="quickPort" binding="tns:exampleBinding"> ... <soapjms:timeToLive>10</soapjms:timeToLive> </wsdl11:port> <wsdl11:port name="slowPort" binding="tns:exampleBinding"> ... </wsdl11:port> </wsdl11:service>
Some
of
the
above
information
can
be
put
in
the
JMS
URI.
When
expressing
properties
from
the
SOAP/JMS
binding
in
the
URI,
you
do
not
need
the
namespace
prefix
—
just
use
the
property
name,
such
as
"
priority
".
This
URI
is
found
as
the
value
of
the
location
attribute
on
the
<wsdl11soap11:address>
or
<wsdl11soap12:address>
element
when
using
SOAP
1.1
and
SOAP
1.2,
respectively.
The
value
of
the
location
attribute
MUST
be
a
URI
corresponding
to
a
JMS
Destination,
and
SHOULD
be
a
"jms"
scheme
URI.
†
The
characters
in
the
URI
need
to
be
encoded
("%20"
for
space,
for
example)
as
per
normal
URI
escaping
rules,
and
the
resulting
URI
needs
to
be
encoded
as
per
normal
XML
rules
("&"
for
&)
when
serialized
into
an
XML
attribute.
The XML elements jndiConnectionFactoryName , jndiInitialContextFactory , jndiURL , deliveryMode , priority , timeToLive , and replyToName , in the soapjms namespace, MUST be supported when used in the context of the WSDL service, port, and binding elements. † This specification does not define any use outside of those elements.
<?xml version="1.0" encoding="utf-8"?> <xs:schema targetNamespace="http://www.w3.org/2010/soapjms/" xmlns:soapjms="http://www.w3.org/2010/soapjms/" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:complexType name="jndiContextParameterType"> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="name" type="xs:string" use="required"/> <xs:attribute name="value" use="required"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:minLength value="1"/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:simpleType name="deliveryModeType"> <xs:restriction base="xs:string"> <xs:enumeration value="PERSISTENT"/> <xs:enumeration value="NON_PERSISTENT"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="priorityType"> <xs:restriction base="xs:int"> <xs:minInclusive value="0"/> <xs:maxInclusive value="9"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="FaultCodesType"> <xs:restriction base="xs:QName"> <xs:enumeration value="soapjms:contentTypeMismatch"/> <xs:enumeration value="soapjms:malformedRequestURI"/> <xs:enumeration value="soapjms:mismatchedSoapAction"/> <xs:enumeration value="soapjms:missingContentType"/> <xs:enumeration value="soapjms:missingRequestURI"/> <xs:enumeration value="soapjms:missingSoapAction"/> <xs:enumeration value="soapjms:missingTargetService"/> <xs:enumeration value="soapjms:targetServiceNotAllowedInRequestURI"/> <xs:enumeration value="soapjms:unrecognizedBindingVersion"/> <xs:enumeration value="soapjms:unsupportedJMSMessageFormat"/> <xs:enumeration value="soapjms:unsupportedLookupVariant"/> <xs:enumeration value="soapjms:contentEncodingNotSupported"/> </xs:restriction> </xs:simpleType> <xs:element name="jndiContextParameter" type="soapjms:jndiContextParameterType"/> <xs:element name="jndiConnectionFactoryName" type="xs:string"/> <xs:element name="jndiInitialContextFactory" type="xs:string"/> <xs:element name="jndiURL" type="xs:anyURI"/> <xs:element name="deliveryMode" type="soapjms:deliveryModeType"/> <xs:element name="priority" type="soapjms:priorityType"/> <xs:element name="timeToLive" type="xs:long"/> <xs:element name="replyToName" type="xs:string"/> <xs:element name="topicReplyToName" type="xs:string"/> </xs:schema>
<?xml version="1.0"?> <wsdl11:definitions name="StockQuote" targetNamespace="http://example.com/stockquote.wsdl" xmlns:tns="http://example.com/stockquote.wsdl" xmlns:stockquote="http://example.com/stockquote.xsd" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:wsdl11soap11="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsdl11="http://schemas.xmlsoap.org/wsdl/" xmlns:soapjms="http://www.w3.org/2010/soapjms/" xmlns="http://schemas.xmlsoap.org/wsdl/"> <wsdl11:types> <xsd:schema targetNamespace="http://example.com/stockquote.xsd"> <xsd:element name="TradePriceRequest"> <xsd:complexType> <xsd:all> <xsd:element name="tickerSymbol" type="xsd:string" /> </xsd:all> </xsd:complexType> </xsd:element> <xsd:element name="TradePrice"> <xsd:complexType> <xsd:all> <xsd:element name="price" type="xsd:float" /> </xsd:all> </xsd:complexType> </xsd:element> </xsd:schema> </wsdl11:types> <wsdl11:message name="GetLastTradePriceInput"> <wsdl11:part name="body" element="stockquote:TradePriceRequest"/> </wsdl11:message> <wsdl11:message name="GetLastTradePriceOutput"> <wsdl11:part name="body" element="stockquote:TradePrice"/> </wsdl11:message> <wsdl11:portType name="StockQuotePortType"> <wsdl11:operation name="GetLastTradePrice"> <wsdl11:input message="tns:GetLastTradePriceInput"/> <wsdl11:output message="tns:GetLastTradePriceOutput"/> </wsdl11:operation> </wsdl11:portType> <wsdl11:binding name="StockQuoteSoapHTTPBinding" type="tns:StockQuotePortType"> <wsdl11soap11:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl11:operation name="GetLastTradePrice"> <wsdl11soap11:operation soapAction="http://example.com/GetLastTradePrice"/> <wsdl11:input> <wsdl11soap11:body use="literal"/> </wsdl11:input> <wsdl11:output> <wsdl11soap11:body use="literal"/> </wsdl11:output> </wsdl11:operation> </wsdl11:binding> <wsdl11:binding name="StockQuoteSoapJMSBinding" type="tns:StockQuotePortType" > <wsdl11soap11:binding style="document" transport="http://www.w3.org/2010/soapjms/"/> <!-- We want this binding to use a particular CF class --> <soapjms:jndiConnectionFactoryName> sample.jms.ConnectionFactory </soapjms:jndiConnectionFactoryName> <!-- Specify PERSISTENT delivery mode --> <soapjms:deliveryMode>PERSISTENT</soapjms:deliveryMode> <wsdl11:operation name="GetLastTradePrice"> <wsdl11soap11:operation soapAction="http://example.com/GetLastTradePrice"/> <wsdl11:input> <wsdl11soap11:body use="literal"/> </wsdl11:input> <wsdl11:output> <wsdl11soap11:body use="literal"/> </wsdl11:output> </wsdl11:operation> </wsdl11:binding> <wsdl11:service name="StockQuoteService"> <wsdl11:documentation>My first service</wsdl11:documentation> <wsdl11:port name="StockQuotePort" binding="tns:StockQuoteSoapHTTPBinding"> <wsdl11soap11:address location="http://example.com/stockquote"/> </wsdl11:port> <wsdl11:port name="StockQuotePort_jms" binding="tns:StockQuoteSoapJMSBinding"> <wsdl11soap11:address location="jms:jndi:myQueue?targetService=stockquote &priority=8&replyToName=interested&userprop=mystuff"/> </wsdl11:port> </wsdl11:service> </wsdl11:definitions>
This section contains examples of the SOAP request messages which will be sent for the SOAP/JMS service described by the WSDL document in C Complete WSDL 1.1 Example . The WSDL contains the following URI:
jms:jndi:myQueue?targetService=stockquote &priority=8 &replyToName=interested &userprop=mystuff
The URI is augmented by the following SOAP/JMS properties from the StockQuoteSoapJMSBinding in the WSDL:
jndiConnectionFactoryName=sample.jms.ConnectionFactory
deliveryMode=PERSISTENT
The JMS messages that invoke this service have three parts. The first part is the Message Header that contains a set of fields defined in the JMS specification, the second part is a set of properties that represent optional header fields, and the last part is the Message Body.
The SOAP/JMS properties described in the Example JMS URI and C Complete WSDL 1.1 Example are used in the JMS message as follows:
Field | value | comments |
---|---|---|
JMSMessage class | jms_bytes | a fixed value |
JMSType | null | |
JMSDeliveryMode | 2 | |
JMSExpiration | 0 | |
JMSPriority | 8 | |
JMSMessageID |
ID:d438e0000001
|
|
JMSTimestamp |
1092110476167
|
|
JMSCorrelationID | null | |
JMSDestination |
A
Destination
object
|
resolved
by
JNDI
from
the
destination
name
myQueue
|
JMSReplyTo |
A
Destination
object
|
resolved
by
JNDI
from
the
destination
name
interested
|
JMSRedelivered | false |
Field | value | comments |
---|---|---|
SOAPJMS_bindingVersion | 1.0 | |
SOAPJMS_targetService | stockquote | this is derived from the targetService property |
SOAPJMS_requestURI | jms:jndi:myQueue?userprop=mystuff | this is derived from the requestURI property |
SOAPJMS_contentType | application/soap+xml | inferred from the SOAP Envelope and absence of attachments. In this case it is SOAP 1.2 |
The following example shows a textual representation of the JMS message contents:
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Body> <tns:TradePriceRequest xmlns:tns="http://example.com/stockquote.xsd"> <tickerSymbol>TickerSymbolValue</tickerSymbol> </tns:TradePriceRequest> </env:Body> </env:Envelope>
The SOAP/JMS properties described in the Example JMS URI and C Complete WSDL 1.1 Example are used in the JMS message as follows:
Field | value | comments |
---|---|---|
JMSMessage class | jms_bytes | a fixed value |
JMSType | null | |
JMSDeliveryMode | 2 | |
JMSExpiration | 0 | |
JMSPriority | 8 | |
JMSMessageID |
ID:d438e0000001
|
|
JMSTimestamp |
1092110476167
|
|
JMSCorrelationID | null | |
JMSDestination |
A
Destination
object
|
resolved
by
JNDI
from
the
destination
name
myQueue
|
JMSReplyTo |
A
Destination
object
|
resolved
by
JNDI
from
the
destination
name
interested
|
JMSRedelivered | false |
Field | value | comments |
---|---|---|
SOAPJMS_bindingVersion | 1.0 | |
SOAPJMS_targetService | stockquote | this is derived from the targetService property |
SOAPJMS_requestURI | jms:jndi:myQueue?userprop=mystuff | this is derived from the requestURI property |
SOAPJMS_contentType | multipart/related type="application/xop+xml"; boundary="MIME_boundary"; charset=utf-8 | inferred from the SOAP Envelope and use of MTOM. In this case it is SOAP 1.2 |
The following example shows a textual representation of the JMS message contents:
--MIME_boundary Content-Type: "application/xop+xml"; charset=utf-8; type="text/xml" Content-Transfer-Encoding: 8bit Content-ID: <945414389.1092086011970> <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"> <env:Header> <myHdr> <xop:Include href="cid:XXX" xmlns:xop="http://www.w3.org/2004/08/xop/include"/> </myHdr> </env:Header> <env:Body> <tns:TradePriceRequest xmlns:tns="http://example.com/stockquote.xsd"> <tickerSymbol>tickerSymbolValue</tickerSymbol> </tns:TradePriceRequest> </env:Body> </env:Envelope> --MIME_boundary content-type:application/octet-stream content-transfer-encoding:base64 content-id:<XXX> YmxhaA== --MIME_boundary--
The Java API for XML Web Services [ JAX-WS ] specification defines the @BindingType annotation for use with a JAX-WS endpoint implementation class. This annotation is used to specify the binding to be used by the endpoint, with the default being SOAP 1.1/HTTP. For example, the following annotation specifies the SOAP 1.2/HTTP binding:
@WebService @BindingType("http://www.w3.org/2003/05/soap/bindings/HTTP/") public class MyEndpointImpl { ... }
In addition to the @BindingType annotation, the JAX-WS specification also defines the specific values to be used with the annotation:
javax.xml.ws.soap.SOAPBinding.SOAP11HTTP_BINDING = "http://schemas.xmlsoap.org/wsdl/soap/http"
javax.xml.ws.soap.SOAPBinding.SOAP12HTTP_BINDING = "http://www.w3.org/2003/05/soap/bindings/HTTP/"
Implementations of the SOAP/JMS binding specification which also support the JAX-WS specification are encouraged to support the use of the following @BindingType annotation values to indicate the use of the SOAP 1.1/JMS and SOAP 1.2/JMS bindings, respectively:
SOAP 1.1/JMS: "http://www.w3.org/2010/soapjms/soap1.1"
SOAP 1.2/JMS: "http://www.w3.org/2010/soapjms/soap1.2"
This section describes using WSDL 2.0 in conjunction with SOAP/JMS. For information about SOAP bindings in WSDL 2.0 see [ WSDL 2.0 Adjuncts ].
The
wsoap:protocol
attribute
of
the
binding
element
gets
a
new
URL
reflecting
a
JMS
transport.
Defines how to set various properties to control the behavior (connection parameters, runtime setting) of the binding.
Locates the service using a JMS URI.
Due to insufficient testing by implementations, the working group chose to create this non-normative section that describes a WSDL 2.0 binding.
Section 3.3 WSDL 1.1 Extensions Detail illustrates how a service originally available over HTTP is made available over JMS using WSDL 1.1. This section illustrates how to indicate the configuration for using SOAP over JMS with WSDL 2.0
(01) <wsdl20:binding (02) name="StockQuoteSoapJMSBinding" interface="tns:StockQuoteInterface" (03) type="http://www.w3.org/2006/01/wsdl/soap" (04) wsoap:protocol="http://www.w3.org/2010/soapjms/" xmlns:soapjms="http://www.w3.org/2010/soapjms/"> (05) (06) <!-- We want this binding to use a particular CF class --> (07) <soapjms:jndiConnectionFactoryName> (08) sample.jms.ConnectionFactory (09) </soapjms:jndiConnectionFactoryName> (10) <!-- Specify PERSISTENT delivery mode --> (11) <soapjms:deliveryMode>PERSISTENT</soapjms:deliveryMode> (12) </wsdl20:binding> (13) (14) <wsdl20:service name="StockQuoteService" interface="tns:StockQuoteInterface"> (15) <wsdl20:documentation>My first service</wsdl20:documentation> (16) <wsdl20:endpoint name="SOAPHTTP" binding="tns:StockQuoteSoapHTTPBinding" (17) address="http://example.com/stockquote"/> (18) <wsdl20:endpoint name="JMS" binding="tns:StockQuoteSoapJMSBinding" (19) address="jms:jndi:myQueue/stockquote"/> (20) </wsdl20:service>
Line
4
shows
the
protocol
URI
in
the
wsoap:protocol
attribute
of
the
<binding>
.
To
indicate
that
this
SOAP/JMS
binding
is
in
use,
the
wsoap:protocol
attribute
needs
to
be
set
to
the
value
http://www.w3.org/2010/soapjms/
.
Lines
7-11
show
the
use
of
WSDL
2.0
extension
elements
to
set
some
of
the
properties
of
the
connection.
In
this
case,
you
see
the
<soapjms:jndiConnectionFactoryName>
and
<soapjms:deliveryMode>
elements
defining
the
values
for
the
jndiConnectionFactoryName
and
deliveryMode
properties.
More
generally,
each
allowed
property
can
be
expressed
as
a
WSDL
2.0
extension
element,
typed
appropriately
for
that
property's
value
space.
For
example,
on
line
11
above,
<soapjms:deliveryMode>
is
of
type
xsd:string
.
This
XML
representation
then
surfaces
in
the
WSDL
2.0
Component
Model
(see
next
section)
as
an
extension
property.
Lines
18-19
are
also
additions
to
specify
the
location
at
which
this
new
implementation
exists.
Line
19
showing
the
JMS
URI
Scheme
jms:
in
the
address
attribute
of
the
<endpoint>
element.
As
with
the
WSDL
1.1
binding,
the
connection
properties
can
also
be
set
in
the
URI.
The
value
of
the
address
attribute
needs
to
be
a
URI
corresponding
to
a
JMS
Destination,
and
ought
to
be
a
"jms"
scheme
URI.
WSDL 2.0 is described abstractly in terms of a component model . Extensions such as the SOAP/JMS binding extend the predefined components with new properties and/or components.
For this specification, each property in the list jndiConnectionFactoryName , jndiInitialContextFactory , jndiURL , deliveryMode , priority , timeToLive , and replyToName adds a WSDL Component Model Property with the same name to the containing WSDL 2.0 component. For instance, if the <deliveryMode> extension element appeared underneath the <service> element in a WSDL 2.0 description, it would result in a deliveryMode property added to the Service component.
Since the same property can be specified in multiple places, we need precedence rules, and in fact they are similar to those specified in section 3.3.4 Specifying Properties In WSDL 1.1 . The most-specific setting overrides less-specific ones (URI specified in the endpoint element's address attribute, then other properties set on the endpoint, then service, then binding). For a particular interaction, the property might be found on the Endpoint component, then Service, then Binding, taking whichever value you find first.
This document is the work of the W3C SOAP-JMS Binding Working Group .
Members of the Working Group are (at the time of writing, and by alphabetical order): Adams, Phil (IBM Corporation), Golby-Kirk, Matthew (IBM Corporation), Johnson, Eric (TIBCO Software Inc.), Lafon, Yves (W3C/ERCIM), Lewis, Amelia (TIBCO Software Inc.), Mehta, Bhakti (Oracle Corporation), Phillips, Mark (IBM Corporation), Rokicki, Derek (Software AG), Sowatskey, Nathan (Cisco).
Previous members of the Working Group were: Daniels, Glen, Easton, Peter, Hapner, Mark, Le Hégaret, Philippe, Merrick, Roland, Xiao, Dongbo.
The people who have contributed to discussions on public-soap-jms@w3.org are also gratefully acknowledged.
The original contributors to the SOAP over Java™ Message Service 1.0 W3C Member Submission: Phil Adams (IBM); Glen Daniels (WSO2); Peter Easton (Progress Software); Tim Frank (Software AG); Lei Jin (BEA Systems, Inc.); Eric Johnson (TIBCO Software Inc.); Vinod Kumar (BEA Systems, Inc.); Amelia A. Lewis (TIBCO Software Inc.); David Orchard (BEA Systems, Inc.); Roland Merrick (IBM); Mark Phillips (IBM); Stephen Todd (IBM); Dongbo Xiao (BEA Systems, Inc.) and Prasad Yendluri (Software AG).
This appendix summarizes assertions made by this specification. Each assertion is assigned a unique identifier.
Id | Assertion |
---|---|
Conformance-1000 | A conforming implementation MUST work with JMS. |
Conformance-1001 | A conforming implementation MUST implement all the requirements of 2 The SOAP/JMS Underlying Protocol Binding . |
Conformance-1002 | Conforming implementations MUST implement all the requirements of the JMS URI. |
Conformance-1003 | Support for WSDL 1.1 is optional and as such an implementation MAY implement it. However, a conforming implementation of this feature MUST implement all the requirements of 3.3 WSDL 1.1 Extensions Detail . |
Protocol-2001 | Properties can be obtained from a number of sources. If a given property is specified in more than one of these, the following list specifies the precedence: the first MUST be used in preference to the second. |
Protocol-2002 | If a given property is specified more than once in the JMS URI the last instance of the property MUST be used. |
Protocol-2003 |
(lookupVariant)
MUST
be
specified
in
the
JMS
URI,
as
the
jms-variant
portion
of
the
syntax.
|
Protocol-2004 |
(destinationName)
MUST
be
specified
in
JMS
URI,
as
the
jms-dest
portion
of
the
syntax.
|
Protocol-2005 |
(deliveryMode)
if
specified
MUST
appear
in
the
JMS
message
in
the
header
named
JMSDeliveryMode
.
If
the
value
of
this
property
is
"PERSISTENT"
then
the
JMSDeliveryMode
integer
value
MUST
be
set
to
DeliveryMode.PERSISTENT
.
If
the
value
of
this
property
is
"NON_PERSISTENT"
then
the
JMSDeliveryMode
integer
value
MUST
be
set
to
DeliveryMode.NON_PERSISTENT
.
|
Protocol-2006 |
(timeToLive)
if
specified,
this
MUST
be
used
to
generate
the
value
of
the
JMS
header
JMSExpiration
.
|
Protocol-2007 |
(priority)
if
specified,
MUST
appear
in
the
JMS
message
in
the
header
named
JMSPriority
.
|
Protocol-2008 |
(replyToName)
if
specified,
this
MUST
be
used
to
derive
the
value
to
be
used
in
the
JMS
header
JMSReplyTo
.
|
Protocol-2009 |
(targetService)
if
specified
MUST
appear
in
the
JMS
message
in
the
JMS
property
named
SOAPJMS_targetService
.
Use
fault
subcode
missingTargetService
if
specified
and
SOAPJMS_targetService
does
not
appear.
|
Protocol-2010 |
(bindingVersion)
fixed
value
"1.0"
in
the
implementation,
MUST
appear
in
a
JMS
property
named
SOAPJMS_bindingVersion
.
|
Protocol-2011 | A fault MUST be generated with subcode unrecognizedBindingVersion if the value of the soapjms:bindingVersion property does not match the fixed value. |
Protocol-2012 |
(contentType)
If
the
charset
parameter
is
specified,
it
is
checked
to
ensure
that
it
matches
the
encoding
value
from
the
supplied
XML.
A
fault
MUST
be
generated
with
subcode
contentTypeMismatch
if
the
encoding
values
do
not
match.
|
Protocol-2016 |
(contentType)
The
contentType
value
MUST
appear
in
the
JMS
message
in
the
JMS
property
named
SOAPJMS_contentType
.
A
fault
MUST
be
generated
with
subcode
missingContentType
if
the
SOAPJMS_contentType
property
is
missing.
|
Protocol-2018 |
(soapAction)If
specified
MUST
appear
in
the
JMS
message
in
the
JMS
property
named
SOAPJMS_soapAction
.
Fault
subcode
missingSoapAction
MAY
be
used
if
SOAPJMS_soapAction
does
not
appear.
|
Protocol-2019 |
(soapAction)
If
using
SOAP
1.2,
and
the
contentType
property
has
an
action
parameter,
that
parameter
value
is
compared
with
the
SOAPJMS_soapAction
value.
A
fault
MUST
be
generated
with
fault
subcode
mismatchedSoapAction
if
the
SOAP
1.2
action
does
not
match
the
SOAPJMS_soapAction
value.
|
Protocol-2020 |
(isFault)
When
this
property
is
true
,
the
sending
software
MUST
set
a
boolean
JMS
Message
property
named
SOAPJMS_isFault
with
a
value
of
true
,
as
in:
Message.setBooleanProperty("SOAPJMS_isFault",
true)
.
|
Protocol-2021 | The client MUST create the requestURI by taking the supplied URI, leaving the destinationName as-is, and removing the targetService and replyToName query parameters if they are specified. The client SHOULD also remove deliveryMode, jndiConnectionFactoryName, jndiInitialContextFactory, jndiURL, jndiContextParameter, timeToLive, and priority properties. The client MAY remove other query parameters not explicitly mentioned above (for example client security related properties). |
Protocol-2022 |
(requestURI)
Appears
in
the
JMS
message
in
the
JMS
property
named
SOAPJMS_requestURI
.
A
fault
MUST
be
generated
with
fault
subcode
missingRequestURI
if
the
SOAPJMS_requestURI
property
is
missing
from
the
message.
|
Protocol-2025 |
A
fault
MUST
be
generated
with
subcode
malformedRequestURI
when
the
SOAPJMS_requestURI
violates
the
expected
syntax.
|
Protocol-2026 |
A
fault
MUST
be
generated
with
subcode
targetServiceNotAllowedInRequestURI
when
targetService
parameter
is
included
in
the
SOAPJMS_requestURI
).
|
Protocol-2027 |
The
contents
of
the
JMS
Message
body
MUST
be
the
SOAP
payload
as
a
JMS
BytesMessage
or
TextMessage
.
|
Protocol-2028 |
A
fault
MUST
be
generated
with
subcode
unsupportedJMSMessageFormat
when
the
arriving
message
format
is
not
BytesMessage
or
TextMessage
.
|
Protocol-2029 | Specifically, if the payload is formatted as a MIME multipart message, then the first byte or character encountered in the JMS Message body MUST be the start of the MIME boundary for the start of the first part — what MIME Part One [ IETF RFC 2045 ] section 2.5 calls a "Body Part". |
Protocol-2030 |
If
the
message
is
formatted
as
"
text/xml
"
or
"
application/soap+xml
",
then
the
first
byte
or
character
of
the
JMS
Message
body
MUST
be
the
start
of
a
conforming
XML
document.
|
Protocol-2032 | In the case of SOAP 1.2 a conforming SOAP-JMS Binding instance MUST support the following message exchange patterns: |
Protocol-2033 | In the case of SOAP 1.1 there is no formal specification of Message Exchange Patterns. A conforming SOAP-JMS Binding instance MUST support both the generic "request/response" and "one-way" patterns as specified in this document. |
Protocol-2036 |
The
Response
Message
MUST
be
created
using
the
same
type
as
the
corresponding
Request
Message,
i.e.
as
a
JMS
BytesMessage
or
TextMessage
.
|
Protocol-2037 |
The
message
MUST
be
sent
to
the
JMS
Destination
in
the
JMSReplyTo
header
of
the
Request
Message.
|
Protocol-2038 |
If
the
JMSCorrelationID
is
set
in
the
request
message,
then
the
JMSCorrelationID
header
field
in
the
response
message
MUST
be
set
to
the
same
value
as
the
JMSCorrelationID
header
field
in
the
request
message.
If
the
JMSCorrelationID
header
field
is
not
set
in
the
request
message,
then
the
JMSCorrelationID
header
field
in
the
response
message
MUST
be
set
to
the
value
of
the
JMSMessageID
header
in
the
request
message.
|
Protocol-2039 | (contentEncoding) If the content encoding is specified, it is checked to ensure that it matches the content encoding values supported. A fault MUST be generated with subcode contentEncodingNotSupported if the encoding values do not match. |
Protocol-2050 |
The
JMSReplyTo
header
MUST
be
assigned
a
value.
|
Protocol-2051 |
The
JMSReplyTo
header
MUST
NOT
be
assigned
a
value.
|
Protocol-2060 |
(lookupVariant)
The
jms-variant
:
jndi
MUST
be
supported.
|
Protocol-2070 |
(topicReplyToName)
if
specified
and
if
relevant,
this
MUST
be
used
to
derive
the
value
to
be
used
in
the
JMS
header
JMSReplyTo
.
|
Protocol-2071 | A fault MUST be generated with subcode unsupportedLookupVariant if the JMS URI specifies a lookupVariant that is not supported by the implementation. |
Protocol-2072 |
While
the
requesting
node
can
support
either
BytesMessage
or
TextMessage
,
the
receiving
node
MUST
support
both
BytesMessage
and
TextMessage
.
|
Protocol-2073 |
If
the
message
is
formatted
as
a
JMS
BytesMessage
,
then
the
sender
and
receiver
MUST
use
the
writeBytes()
and
readBytes()
methods,
respectively.
|
WSDLUsage-3001 | If a property is specified at multiple levels within the WSDL document, the most specific setting MUST take precedence (URI specified in the address element's location attribute first, then other properties set on the port, then service, then binding). |
WSDLUsage-3002 | The XML elements jndiConnectionFactoryName , jndiInitialContextFactory , jndiURL , deliveryMode , priority , timeToLive , and replyToName , in the soapjms namespace, MUST be supported when used in the context of the WSDL service, port, and binding elements. |
WSDLUsage-3003 |
To
indicate
that
this
SOAP/JMS
binding
is
in
use,
the
transport
attribute
MUST
be
set
to
the
value
http://www.w3.org/2010/soapjms/
.
|
WSDLUsage-3004 |
The
value
of
the
location
attribute
MUST
be
a
URI
corresponding
to
a
JMS
Destination,
and
SHOULD
be
a
"jms"
scheme
URI.
|
Date | Editor | Description |
---|---|---|
2011-11-01 | ejohnson | Updated acknowledgements. Updated disposition of comments to properly identify Andrew Kennedy as opening one issue, and to link to previous version of the dispositions. Updated entitiespr.dtd to reflect previous version, and expected publication date. Updated XML to fix problem with an invalid <ul> section in generated HTML. Regenerated HTML. |
2011-09-13 | ejohnson | More link fixes. |
2011-09-13 | ejohnson | Updated acknowledgments (official entry for TIBCO changed.) Also updated a whole bunch of links that were flagged as warnings by the link checker. |
2011-05-24 | ejohnson | Updated acknowledgments, changelog.xml, and spec. Primary aim was to update reference for "jms" URI scheme to point at RFC 6167! |
2011-01-17 | ejohnson | Applied issue 70, updated acknowledgments, and change log. |
2011-01-07 | mphillip | Applied the resolution for ISSUE-65 to complete ACTION-237 http://www.w3.org/2002/ws/soapjms/tracker/actions/237 http://www.w3.org/2002/ws/soapjms/tracker/issues/65 |
2010-12-21 | mphillip | Applied the resolution for ISSUE-69 to complete ACTION-236 http://www.w3.org/2002/ws/soapjms/tracker/actions/236 http://www.w3.org/2002/ws/soapjms/tracker/issues/69 |
2010-12-14 | mphillip | Applied the resolution for ISSUE-68 to complete ACTION-234 http://www.w3.org/2002/ws/soapjms/tracker/actions/234 http://www.w3.org/2002/ws/soapjms/tracker/issues/68 |
2010-12-14 | mphillip | Applied the resolution for ISSUE-67 to complete ACTION-230 http://www.w3.org/2002/ws/soapjms/tracker/actions/230 http://www.w3.org/2002/ws/soapjms/tracker/issues/67 |
2010-11-24 | ejohnson | Updated link to latest version of JMS URI scheme draft, also updated acknowledgments. |
2010-10-12 | mphillip | Applied the resolution for ISSUE-64 to complete ACTION-216 http://www.w3.org/2002/ws/soapjms/tracker/actions/216 http://www.w3.org/2002/ws/soapjms/tracker/issues/64 |
2010-09-15 | mphillip | Applied the resolution for ISSUE-62 and ISSUE-63 to complete ACTION-211 http://www.w3.org/2002/ws/soapjms/tracker/actions/211 http://www.w3.org/2002/ws/soapjms/tracker/issues/62 http://www.w3.org/2002/ws/soapjms/tracker/issues/63 |
2010-09-07 | mphillip | Applied the resolution for ISSUE-61 to complete ACTION-209 http://www.w3.org/2002/ws/soapjms/tracker/actions/209 http://www.w3.org/2002/ws/soapjms/tracker/issues/61 |
2010-08-30 | ejohnson | Applied resolution for http://www.w3.org/2002/ws/soapjms/tracker/issues/60 |
2010-08-30 | ejohnson | Applied resolution for http://www.w3.org/2002/ws/soapjms/tracker/issues/55 |
2010-08-30 | ejohnson | Applied resolution of http://www.w3.org/2002/ws/soapjms/tracker/issues/48 |
2010-08-27 | mphillip | Applied changes for ACTION-201 (Part2) http://www.w3.org/2002/ws/soapjms/tracker/actions/201 to resolve ISSUE-58 |
2010-08-23 | mphillip | Applied changes for ACTION-201 (Part1) http://www.w3.org/2002/ws/soapjms/tracker/actions/201 to resolve Issue-56 and ISSUE-57 |
2010-08-23 | mphillip | Applied changes for ACTION-200 http://www.w3.org/2002/ws/soapjms/tracker/actions/200 to resolve Issue-50 |
2010-08-03 | ejohnson | Applied issues 47, 49, 51, 52, 53, 54 |
2010-07-19 | ejohnson | Applied changes for issues 41-46, as per action item 194 and the recorded minutes. |
2010-07-16 | ejohnson | Applied resolution for ISSUE-40 |
2010-07-12 | ejohnson | Fixed editorial items identified in email: http://lists.w3.org/Archives/Public/public-soap-jms/2010Jul/0013.html |
2010-07-12 | ejohnson | Fixed a small typo with previous fix - three --> two. |
2010-07-09 | ejohnson | Action 183 - applied changes for ISSUE-38 |
2010-07-09 | ejohnson | Fixed publication date for URI scheme, as per action 179. |
2010-07-08 | mphillip | Applied changes for ACTION-188 http://www.w3.org/2002/ws/soapjms/tracker/actions/188 - issue 39 http://www.w3.org/2002/ws/soapjms/tracker/issues/39 |
2010-07-06 | mphillip | Applied changes for ACTION-185 http://www.w3.org/2002/ws/soapjms/tracker/actions/185 |
2010-06-28 | ejohnson | Fixed link to JMS URI scheme as per ACTION-179 |
2010-06-08 | peaston | ACTION-177 - Update the spec with the resolution to issue 34 (error subcodes in schema, SOAP 1.1 Fault structure) |
2010-05-06 | padams2 | One more update for Issue-31 |
2010-05-06 | padams2 | Apply correct updates for Issue-31 |
2010-04-27 | padams2 | Applied changes for Issue-31 |
2010-04-27 | padams2 | Applied changes for Issue-30 |
2010-04-26 | padams2 | Applied changes for Issue-32 and Issue33 |
2010-03-22 | mphillip | Changes to resolve Issue 28 (action 147) - see http://www.w3.org/2002/ws/soapjms/tracker/issues/28 |
2010-02-16 | mphillip | Changes to resolve Issue 26 (action 141) - see http://www.w3.org/2002/ws/soapjms/tracker/issues/26 |
2010-02-16 | mphillip | Changes to resolve Issue 24 (action 140) - see http://www.w3.org/2002/ws/soapjms/tracker/issues/24 |
2010-02-16 | mphillip | Changes to resolve Issue 25 (action 139) - see http://www.w3.org/2002/ws/soapjms/tracker/issues/25 |
2010-01-29 | mphillip | Changes to resolve Issue 22 (action 135) |
2010-01-29 | mphillip | Changes to resolve Issue 18 (action 125) |
2010-01-26 | mphillip | Changes to resolve Issue 17 |
2009-12-08 | padams2 | Changes for Issue-20 |
2009-12-08 | padams2 | Changes for Issue-19 |
2009-12-01 | padams2 | Changes to resolve issue-16 |
2009-12-01 | padams2 | Changes to resolve issue-15 |
2009-11-16 | mphillip | Updates to resolve Issue 4 - see action 120 http://www.w3.org/2002/ws/soapjms/tracker/actions/120 |
2009-10-21 | mphillip | Changes to resolve Issue 4 (action 101) regarding requestURI by removing assertion Protocol-2024, and rewording Protocol-2021 |
2009-10-13 | padams2 | Changes to resolve Issue-14 |
2009-10-01 | padams2 | Changes to resolve Issue-12 and Issue-13 |
2009-09-18 | padams2 | Changes to resolve Issue-9 (reworded some assertions) |
2009-08-18 | padams2 | Fixed formatting of assertion 2016 in the appendix |
2009-08-18 | padams2 | Changes to resolve Issue-10 (removed assertion 2017) |
2009-08-18 | padams2 | Changes to resolve Issue-8; regen'd testcase document |
2009-08-12 | padams2 | Follow-up changes for issues 2, 3, and 6 from 8/11 conference call |
2009-08-11 | padams2 | Changes to resolve Issue-7 (removed assertion 2041) |
2009-08-11 | padams2 | Changes to resolve Issue-6 (removed assertion 2039) |
2009-08-11 | padams2 | Changes to resolve Issue-5 (removed assertion 2035) |
2009-08-10 | padams2 | Changes to resolve ISSUE-3 (Combined assertions 2022 and 2023) |
2009-08-10 | padams2 | Changes to resolve ISSUE-2 (combined assertions 2019 and 2020) |
2009-08-10 | padams2 | Changes to resolve Issue-1 (text associated with the contentTypeMismatch fault subcode) |
2009-05-06 | rmerric | change section heading from Request-Response MEP to Request-Response Message Exchange Pattern as per derek suggestion that we be consistent with One-way Message Exchange Pattern |
2009-05-06 | rmerric | change how assertions Protocol-2035, Protocol-2039, and Protocol-2041 appear in the assertion summary. |
2009-05-05 | rmerric | Improve summary text for assertions Protocol-34 & Protocol-40 |
2009-05-05 | rmerric | remove assertion Protocol-2042 that is a duplicate of its constituent parts |
2009-04-29 | rmerric | mark usage of rfc2119 terms where required, tweak assertions so that the assertion summary is clearer. |
2009-04-28 | rmerric | expand scope of text inside assertions 1003 and 1004. |
2009-04-23 | rmerric | fix syntax error in example "Setting JMS Message Header properties" |
2009-04-16 | rmerric | ACTION-82 apply agreed changes to contentType |
2009-04-14 | padams2 | Added new fault subcode: unsupportedLookupVariant |
2009-04-14 | rmerric | editorial tweak to previous precedence change |
2009-04-08 | rmerric | clarify precedence rules for binding properties |
2009-03-25 | rmerric | change NONPERSISTENT to NON_PERSISTENT |
2009-03-23 | peaston | Clarify the wording and scope of the jndiContext Parameter property |
2009-03-19 | rmerric | tweak wording for topicReplyToName |
2009-03-19 | rmerric | add topicReplytoName definition |
2009-02-10 | padams2 | Added myself as an editor |
2009-02-10 | padams2 | Minor wording change re: use of java naming-related properties (Action-61) |
2009-01-29 | rmerric | make support for lookupVariant = jndi required. Response to Last Call comment LC03. |
2009-01-29 | rmerric | Add support for JMS 1.1 to conformance criteria. Response to Last Call comment LC02. |
2008-11-18 | rmerric | point to November draft of URI Scheme |
2008-11-12 | rmerric | add precedence question to status section. |
2008-10-29 | rmerric | add note about handling of precedence. more minor typos. |
2008-10-29 | rmerric | create named types in schema and use them in "Properties affecting binding" |
2008-10-29 | rmerric | remove references to the obsolete "context" variant +fix two minor typos |
2008-10-22 | rmerric | Remove Editor Note |
2008-10-22 | rmerric | add jndiContextParameter |
2008-10-22 | rmerric | Add XML Schema as an appendix |
2008-10-15 | rmerric | simplify conformance criteria for JMS URI support |
2008-10-15 | rmerric | clarify fault: unsupportedJMSMessageFormat |
2008-10-14 | rmerric | correct feature URIs |
2008-10-14 | rmerric | change conformance criteria |
2008-10-09 | padams2 | Modified soapjms.xml with minor edits related to TextMessage. |
2008-10-09 | rmerric | fix rfc2045 reference |
2008-10-09 | rmerric | Add support for TextMessage and considerations for use of said type. |
2008-08-18 | bmehta | Made changes to the spec to show snippets in JMS Message Header and Message properties based on code shown by Eric |
2008-07-29 | rmerric | add examples of how to set message properties |
2008-07-23 | ylafon | <p> were out of balance as a block level element was in the middle |
2008-07-23 | rmerric | Remove Java TM |
2008-07-17 | rmerric | Added a non-normative code snippet to DeliveryMode |
2008-07-14 | plehegar | Fixed language information |
2008-07-11 | rmerric | editorial nits before FPWD |
2008-06-25 | rmerric | make valid as well as well-formed! |
2008-06-25 | rmerric | MUST & MUST NOT for JMSReplyTo |
2008-06-25 | rmerric | Editorial changes identified by Eric and Peter |
2008-06-23 | rmerric | fix pointer to IETF JMS URI spec |
2008-06-22 | bmehta | Fixed some places where I missed the iri |
2008-06-22 | bmehta | Updated with changes based on discussions in meetings and Eric's feedback |
2008-06-12 | peaston | Add support for assertion markups |
2008-06-10 | rmerric | add the authors as a test |
2008-05-01 | plehegar | Using latest version for WSDL 2.0 references |
2008-05-01 | plehegar | Added support for CVS changelog |
2008-05-01 | plehegar | Moved section 2.9 into non-normative appendix. Updated the references section (now normative). Added table and example headers. Fixed/added bibref. Using SOAP 1.2 instead of SOAP 1.1 in example. Added XML Namespaces section. |
2008-04-22 | plehegar | New |