Please refer to the errata for this document, which may include normative corrections.
See also translations.
Copyright © 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 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.
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. Only editorial changes were made as a result of the 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).
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 Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to 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() ); } }
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 |