SOAP over Java Message Service 1.0

Editors' copy $Date: 2011-12-02 10:45:29 $ @@ @@@@ @@@@

This version:
soapjms.html
Latest version:
http://dev.w3.org/cvsweb/~checkout~/2008/ws/soapjms/soapjms.html?content-type=text/html; charset=utf-8
Editors:
Phil Adams, IBM
Peter Easton, Progress Software
Eric Johnson, TIBCO
Roland Merrick, IBM
Mark Phillips, IBM

Abstract

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.

Status of this Document

This document is an editors' copy that has no official standing.

Table of Contents

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

Appendices

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)


1 Introduction

1.1 Background

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.

Note that the URI specification is in a separate document.

1.3 Context

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.

1.4 Notational Conventions

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.

1.4.1 XML Namespaces

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]).

Prefixes and Namespaces used in this specification
PrefixNamespaceSpecification
soapjmshttp://www.w3.org/2010/soapjms/Defined by this specification
xsdhttp://www.w3.org/2001/XMLSchema [XML Schema Structures]
wsdl11http://schemas.xmlsoap.org/wsdl/[WSDL 1.1]
wsdl20http://www.w3.org/ns/wsdl[WSDL 2.0 Core Language]
wsoaphttp://www.w3.org/ns/wsdl/soap[WSDL 2.0 Adjuncts]
wsdl11soap11http://schemas.xmlsoap.org/wsdl/soap/[WSDL 1.1]
wsdl11soap12http://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: plh20080501
The above paragraph will need to be removed for the publication of the Recommendation.

1.6 Conformance

This specification defines two features, each of which has conformance criteria associated with it. A conforming implementation MUST work with JMS.

  1. 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.

  2. 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.

2 The SOAP/JMS Underlying Protocol Binding

This section is normative.

This section describes the required feature: soapjms:Protocol [http://www.w3.org/2010/soapjms/Protocol]

2.2 Properties Affecting Binding

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.

  1. The environment (for example local program variables, system environment variables etc).

  2. 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.

2.2.1 Connection to a destination

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.

[Definition: soapjms:lookupVariant ](xsd:string)
  • 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.]

[Definition: soapjms:destinationName ] (xsd:string)
  • 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.

[Definition: soapjms:jndiConnectionFactoryName ] (xsd:string)
  • Specifies the JNDI name of the connection factory.

  • optional in URI, optional in WSDL, optional in environment

[Definition: soapjms:jndiInitialContextFactory ] (xsd:string)
  • 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

[Definition: soapjms:jndiURL ] (xsd:anyURI)
  • 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

[Definition: soapjms:jndiContextParameter ] (soapjms:jndiContextParameterType)
  • 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

2.2.2 JMS Message Header properties

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.

[Definition: soapjms:deliveryMode] (soapjms:deliveryModeType)
  • 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.

[Definition: soapjms:timeToLive] (xsd:long)
  • 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.

[Definition: soapjms:priority] (soapjms:priorityType)
  • 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.

[Definition: soapjms:replyToName] (xsd:string)
  • 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.

[Definition: soapjms:topicReplyToName] (xsd:string)
  • 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.

2.2.3 JMS Message properties

[Definition: soapjms:targetService] (xsd:string)
  • 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. ]

[Definition: soapjms:bindingVersion] (xsd:string)
  • 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. ]

[Definition: soapjms:contentType] (xsd:string)

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.]

[Definition: soapjms:soapAction] (xsd:anyURI)
  • 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.]

[Definition: soapjms:isFault] (xsd:boolean)
  • 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.

[Definition: soapjms:requestURI] (xsd:string)
  • 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). ]

[Definition: soapjms:contentEncoding] (xsd:string)
  • 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).

2.4 The JMS Message Body

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.

2.4.1 Considerations For Using TextMessage

While the use of TextMessage might be attractive in some scenarios, there are some considerations that go along with it.

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.

2.5 Supported Message Exchange Patterns

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:

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.

2.6 Request-Response Message Exchange Pattern

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.

2.6.1 Behaviour of Requesting SOAP Node

2.6.1.1 Init

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.

Init State Values
FieldValue Set by Conforming Client
JMS Message Header
JMSDeliveryModethe value of the deliveryMode property or not set if not specified
JMSExpirationcalculated from the value of the timeToLive property or not set if not specified
JMSPrioritythe value of the priority property or not set if not specified
JMSDestinationderived from the destinationName property
JMSReplyToif 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_requestURIthis is derived from the requestURI property
SOAPJMS_bindingVersionthis is copied from the bindingVersion property
SOAPJMS_soapActionthe value of the soapAction property or not set if not specified
SOAPJMS_targetServicethe value of the targetService property or not set if not specified
SOAPJMS_contentTypeinferred from the SOAP Envelope and presence of attachments
JMS Message Body
bodyA SOAP envelope is serialized according to the media type specified in the JMS Message property SOAPJMS_contentType

2.6.2 Behaviour of Responding SOAP Node

2.6.2.2 Receiving

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).

2.6.2.3 Receiving + Sending

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.

Receiving + Sending State Values
FieldValue Set by Conforming Client
JMS Message Header
JMSDeliveryModethis ought to be the same as that specified on the request
JMSExpirationthis is derived from the request. It is up to the responding node to decide whether to degrade for processing time.
JMSCorrelationIDthis is copied from the request JMSCorrelationID if it is set, or the request JMSMessageID if the request JMSCorrelationID is not set
JMSDestinationthis is copied from the JMSReplyTo property in the request
JMS Message properties
SOAPJMS_requestURIthis is copied from the requestURI property in the request message
SOAPJMS_bindingVersionthis is copied from the bindingVersion property
SOAPJMS_contentTypeinferred from the SOAP Envelope and presence of attachments
SOAPJMS_isFaultset to true if the response is a SOAP fault, otherwise it can be absent
JMS Message Body
bodyA 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.

2.7 One-way Message Exchange Pattern

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:

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.

2.7.1 Behaviour of Sending SOAP Node

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.

Sending SOAP Node Values
FieldValue Set by Conforming Client
JMS Message Header
JMSDeliveryModethe value of the deliveryMode property or not set if not specified
JMSExpirationcalculated from the value of the timeToLive property or not set if not specified
JMSPrioritythe value of the priority property or not set if not specified
JMSDestinationderived from the destinationName property
JMS Message properties
SOAPJMS_requestURIthis is derived from the requestURI property
SOAPJMS_bindingVersionthis is copied from the bindingVersion property
SOAPJMS_soapActionthe value of the soapAction property or not set if not specified
SOAPJMS_targetServicethe value of the targetService property or not set if not specified
SOAPJMS_contentTypeinferred from the SOAP Envelope and presence of attachments.
JMS Message Body
bodyA SOAP envelope is serialized according to the media type specified in the JMS Message property SOAPJMS_contentType.

2.8 Faults

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:

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:

3 WSDL Usage

3.1 Overview

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].

3.3 WSDL 1.1 Extensions Detail

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.

3.3.1 Example

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
                                   &amp;priority=8&amp;replyToName=interested&amp;userprop=mystuff"/>
42       </wsdl11:port>
43   </wsdl11:service>

The key points to notice are:

3.3.2 WSDL 1.1 Transport Identification

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/.

3.3.3 WSDL 1.1 SOAP Action

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.

3.3.4 Specifying Properties In WSDL 1.1

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.

3.3.5 Specifying Properties Via the JMS URI

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 ("&amp;" for &) when serialized into an XML attribute.

3.4 Properties

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.

A References

A.1 Normative References

[IETF RFC 2045]
Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, N. Freed, N. Borenstein, Authors. Internet Engineering Task Force, November 1996. Available at http://www.ietf.org/rfc/rfc2045.txt.
[IETF RFC 2119]
Key words for use in RFCs to Indicate Requirement Levels, S. Bradner, Author. Internet Engineering Task Force, March 1997. Available at http://www.ietf.org/rfc/rfc2119.txt.
[IETF RFC 3986]
Uniform Resource Identifier (URI): Generic Syntax , T. Berners-Lee, R. Fielding, L. Masinter. Internet Engineering Task Force, January 2005. Available at http://www.ietf.org/rfc/rfc3986.txt.
[IETF RFC 6167]
URI Scheme for Java Message Service 1.0, M. Phillips, P. Adams, D. Rokicki, and E. Johnson, Authors. Internet Engineering Task Force, April 2011. Available at http://www.ietf.org/rfc/rfc6167.txt
[Java Message Service]
Java Message Service (JMS) 1.1, M. Hapner, et. al., Authors. Sun Microsystems, Inc., 12 April 2002. Available at http://www.oracle.com/technetwork/java/jms/index.html
[SOAP 1.1]
Simple Object Access Protocol (SOAP) 1.1, D. Box, et al, Editors. DevelopMentor, International Business Machines Corporation, Lotus Development Corporation, Microsoft, and UserLand Software, 8 May 2000. This version of the SOAP 1.1 specification is http://www.w3.org/TR/2000/NOTE-SOAP-20000508/. The latest version of the SOAP 1.1 specification is available at http://www.w3.org/TR/soap/.
[SOAP 1.1 Binding for MTOM 1.0]
SOAP 1.1 Binding for MTOM 1.0, Dimitar Angelov, et. al., Authors. International Business Machines Corporation, Microsoft Corporation, Inc., Oracle Corp. and SAP AG, 5 April 2006. This version of the SOAP 1.1 Binding for MTOM 1.0 specification is http://www.w3.org/Submission/2006/SUBM-soap11mtom10-20060405/. The latest version of the SOAP 1.1 Binding for MTOM 1.0 specification is available at http://www.w3.org/Submission/soap11mtom10/.
[SOAP 1.2 Messaging Framework]
SOAP Version 1.2 Part 1: Messaging Framework, M. Gudgin, M. Hadley, N. Mendelsohn, J-J. Moreau, H. Frystyk Nielsen, Editors. World Wide Web Consortium, 24 June 2003, revised 27 April 2007. This version of the SOAP Version 1.2 Part 1: Messaging Framework Recommendation is http://www.w3.org/TR/2007/REC-soap12-part1-20070427/. The latest version of SOAP Version 1.2 Part 1: Messaging Framework is available at http://www.w3.org/TR/soap12-part1/.
[SOAP 1.2 Part 2: Adjuncts]
SOAP Version 1.2 Part 2: Adjuncts (Second Edition), M. Gudgin, et al., Editors. World Wide Web Consortium, 24 June 2006, revised 27 April 2007. This version of the "SOAP Version 1.2 Part 2: Adjuncts (Second Edition)" Recommendation is http://www.w3.org/TR/2007/REC-soap12-part2-20070427/. The latest version of "SOAP Version 1.2 Part 2: Adjuncts" is available at http://www.w3.org/TR/soap12-part2/.
[SOAP 1.2 Part 3: One-Way MEP]
SOAP 1.2 Part 3: One-Way MEP, David Orchard, Author. World Wide Web Consortium, 2 July 2007. This version of the SOAP 1.2 Part 3: One-Way MEP is http://www.w3.org/TR/2007/NOTE-soap12-part3-20070702/. The latest version of the SOAP 1.2 Part 3: One-Way MEP is available at http://www.w3.org/TR/soap12-part3/.
[SOAP Messages with Attachments]
SOAP Messages with Attachments, John Barton, Satish Thatte, and Henrik Frystyk Nielsen, Authors. Hewlett Packard Labs, Microsoft Corporation, 11 December 2000. This version of the SOAP Messages with Attachments specification is http://www.w3.org/TR/2000/NOTE-SOAP-attachments-20001211. The latest version is available at http://www.w3.org/TR/SOAP-attachments.
[SOAP MTOM]
SOAP Message Transmission Optimization Mechanism, N. Mendelsohn, M. Nottingham, and H. Ruellan, Editors. World Wide Web Consortium, W3C Recommendation, 25 January 2005. This version of SOAP Message Transmission Optimization Mechanism is http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/. The latest version of the "SOAP Message Transmission Optimization Mechanism" document is available from http://www.w3.org/TR/soap12-mtom/.
[WSDL 1.1]
Web Services Description Language (WSDL) 1.1, E. Christensen, et al, Authors. Ariba, International Business Machines Corporation, and Microsoft, 15 March 2001. This version is available at http://www.w3.org/TR/2001/NOTE-wsdl-20010315. The latest version is available at http://www.w3.org/TR/wsdl.
[WSDL 1.1 for SOAP 1.2]
WSDL 1.1 Binding Extension for SOAP 1.2, D. Angelov, et al, Authors. International Business Machines Corporation, Microsoft Corporation, Inc., Oracle Corp. and SAP AG, 5 April 2006. This version is available at http://www.w3.org/Submission/2006/SUBM-wsdl11soap12-20060405/. The latest version is available at http://www.w3.org/Submission/wsdl11soap12/.
[XML 1.0]
Extensible Markup Language (XML) 1.0 (Fourth Edition), T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, and François Yergeau, Editors. World Wide Web Consortium, 10 February 1998, revised 16 August 2006. This version of the XML 1.0 Recommendation is http://www.w3.org/TR/2006/REC-xml-20060816/. The latest version of XML 1.0 is available at http://www.w3.org/TR/REC-xml.
[XML Namespaces]
Namespaces in XML 1.0, T. Bray, D. Hollander, A. Layman, and R. Tobin, Editors. World Wide Web Consortium, 14 January 1999, revised 16 August 2006. This version of the Namespaces in XML Recommendation is http://www.w3.org/TR/2006/REC-xml-names-20060816/. The latest version of Namespaces in XML is available at http://www.w3.org/TR/REC-xml-names.
[XML Schema Datatypes]
XML Schema Part 2: Datatypes Second Edition, P. Byron and A. Malhotra, Editors. World Wide Web Consortium, 2 May 2001, revised 28 October 2004. This version of the XML Schema Part 2 Recommendation is http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/. The latest version of XML Schema Part 2 is available at http://www.w3.org/TR/xmlschema-2.
[XML Schema Structures]
XML Schema Part 1: Structures Second Edition, H. Thompson, D. Beech, M. Maloney, and N. Mendelsohn, Editors. World Wide Web Consortium, 2 May 2001, revised 28 October 2004. This version of the XML Schema Part 1 Recommendation is http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/. The latest version of XML Schema Part 1 is available at http://www.w3.org/TR/xmlschema-1.
[IANA HTTP PARAMS]
Hypertext Transfer Protocol (HTTP) Parameters, Internet Assigned Names And Numbers (IANA), Sept. 2, 2009, Available at http://www.iana.org/assignments/http-parameters/http-parameters.xml.

A.2 Informative References

[JAX-WS]
The Java API for XML Web Services, Jitendra Kotamraju, Specification Lead, Java Community Process, Oracle Corp. 10 Dec, 2009. Available at http://jcp.org/aboutJava/communityprocess/mrel/jsr224/index3.html.
[SOAP 1.2 Email Binding]
SOAP Version 1.2 Email Binding, Highland Mary Mountain, Jacek Kopecky, Stuart Williams, Glen Daniels, and Noah Mendelsohn, Authors. World Wide Web Consortium, 3 July 2002. This version of the SOAP Version 1.2 Email Binding is available at http://www.w3.org/TR/2002/NOTE-soap12-email-20020703. The latest version of the SOAP Version 1.2 Email Binding is available at http://www.w3.org/TR/soap12-email.
[WSDL 2.0 Adjuncts]
Web Services Description Language (WSDL) Version 2.0 Part 2: Adjuncts, R. Chinnici, H. Haas, A. Lewis, J-J. Moreau, D. Orchard, S. Weerawarana, Editors. World Wide Web Consortium, 26 June 2007. This version of the "Web Services Description Language (WSDL) Version 2.0 Part 2: Adjuncts" Recommendation is available at http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626/. The latest version of "Web Services Description Language (WSDL) Version 2.0 Part 2: Adjuncts" is available at http://www.w3.org/TR/wsdl20-adjuncts/ .
[WSDL 2.0 Core Language]
Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language, R. Chinnici, J. J. Moreau, A. Ryman, S. Weerawarana, Editors. World Wide Web Consortium, 26 June 2007. This version of the WSDL 2.0 specification is http://www.w3.org/TR/2007/REC-wsdl20-20070626/. The latest version of WSDL 2.0 is available at http://www.w3.org/TR/wsdl20/.

B Schema


<?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>

C Complete WSDL 1.1 Example (Non-Normative)


<?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
                                 &amp;priority=8&amp;replyToName=interested&amp;userprop=mystuff"/>
       </wsdl11:port>
   </wsdl11:service>

</wsdl11:definitions>

D SOAP/JMS Underlying Protocol Binding Examples (Non-Normative)

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:

The URI is augmented by the following SOAP/JMS properties from the StockQuoteSoapJMSBinding in the WSDL:

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.

D.2 SOAP Request with attachments

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:

JMS Message Header Values
Fieldvaluecomments
JMSMessage classjms_bytesa fixed value
JMSTypenull
JMSDeliveryMode2
JMSExpiration0
JMSPriority8
JMSMessageIDID:d438e0000001
JMSTimestamp1092110476167
JMSCorrelationIDnull
JMSDestinationA Destination objectresolved by JNDI from the destination name myQueue
JMSReplyToA Destination object resolved by JNDI from the destination name interested
JMSRedeliveredfalse
JMS Message Properties Values
Fieldvaluecomments
SOAPJMS_bindingVersion1.0
SOAPJMS_targetServicestockquotethis is derived from the targetService property
SOAPJMS_requestURIjms:jndi:myQueue?userprop=mystuffthis is derived from the requestURI property
SOAPJMS_contentTypemultipart/related type="application/xop+xml"; boundary="MIME_boundary"; charset=utf-8inferred 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:

E JAX-WS @BindingType annotation values (Non-Normative)

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:

In addition to the @BindingType annotation, the JAX-WS specification also defines the specific values to be used with the annotation:

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:

F WSDL 2.0 (Non-Normative)

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].

F.2 WSDL 2.0 Extensions Detail

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.

F.2.1 Relationship to WSDL 2.0 Component Model

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.

F.2.1.1 Precedence

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.

G Acknowledgements (Non-Normative)

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).

H Assertion Summary (Non-Normative)

This appendix summarizes assertions made by this specification. Each assertion is assigned a unique identifier.

Summary of Assertions
IdAssertion
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.

I Change Log (Non-Normative)

DateEditorDescription
2011-11-01ejohnson 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-13ejohnson More link fixes.
2011-09-13ejohnson 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-24ejohnson Updated acknowledgments, changelog.xml, and spec. Primary aim was to update reference for "jms" URI scheme to point at RFC 6167!
2011-01-17ejohnson Applied issue 70, updated acknowledgments, and change log.
2011-01-07mphillip 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-21mphillip 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-14mphillip 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-14mphillip 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-24ejohnson Updated link to latest version of JMS URI scheme draft, also updated acknowledgments.
2010-10-12mphillip 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-15mphillip 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-07mphillip 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-30ejohnson Applied resolution for http://www.w3.org/2002/ws/soapjms/tracker/issues/60
2010-08-30ejohnson Applied resolution for http://www.w3.org/2002/ws/soapjms/tracker/issues/55
2010-08-30ejohnson Applied resolution of http://www.w3.org/2002/ws/soapjms/tracker/issues/48
2010-08-27mphillip Applied changes for ACTION-201 (Part2) http://www.w3.org/2002/ws/soapjms/tracker/actions/201 to resolve ISSUE-58
2010-08-23mphillip 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-23mphillip Applied changes for ACTION-200 http://www.w3.org/2002/ws/soapjms/tracker/actions/200 to resolve Issue-50
2010-08-03ejohnson Applied issues 47, 49, 51, 52, 53, 54
2010-07-19ejohnson Applied changes for issues 41-46, as per action item 194 and the recorded minutes.
2010-07-16ejohnson Applied resolution for ISSUE-40
2010-07-12ejohnson Fixed editorial items identified in email: http://lists.w3.org/Archives/Public/public-soap-jms/2010Jul/0013.html
2010-07-12ejohnson Fixed a small typo with previous fix - three --> two.
2010-07-09ejohnson Action 183 - applied changes for ISSUE-38
2010-07-09ejohnson Fixed publication date for URI scheme, as per action 179.
2010-07-08mphillip 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-06mphillip Applied changes for ACTION-185 http://www.w3.org/2002/ws/soapjms/tracker/actions/185
2010-06-28ejohnson Fixed link to JMS URI scheme as per ACTION-179
2010-06-08peaston ACTION-177 - Update the spec with the resolution to issue 34 (error subcodes in schema, SOAP 1.1 Fault structure)
2010-05-06padams2 One more update for Issue-31
2010-05-06padams2 Apply correct updates for Issue-31
2010-04-27padams2 Applied changes for Issue-31
2010-04-27padams2 Applied changes for Issue-30
2010-04-26padams2 Applied changes for Issue-32 and Issue33
2010-03-22mphillip Changes to resolve Issue 28 (action 147) - see http://www.w3.org/2002/ws/soapjms/tracker/issues/28
2010-02-16mphillip Changes to resolve Issue 26 (action 141) - see http://www.w3.org/2002/ws/soapjms/tracker/issues/26
2010-02-16mphillip Changes to resolve Issue 24 (action 140) - see http://www.w3.org/2002/ws/soapjms/tracker/issues/24
2010-02-16mphillip Changes to resolve Issue 25 (action 139) - see http://www.w3.org/2002/ws/soapjms/tracker/issues/25
2010-01-29mphillip Changes to resolve Issue 22 (action 135)
2010-01-29mphillip Changes to resolve Issue 18 (action 125)
2010-01-26mphillip Changes to resolve Issue 17
2009-12-08padams2 Changes for Issue-20
2009-12-08padams2 Changes for Issue-19
2009-12-01padams2 Changes to resolve issue-16
2009-12-01padams2 Changes to resolve issue-15
2009-11-16mphillip Updates to resolve Issue 4 - see action 120 http://www.w3.org/2002/ws/soapjms/tracker/actions/120
2009-10-21mphillip Changes to resolve Issue 4 (action 101) regarding requestURI by removing assertion Protocol-2024, and rewording Protocol-2021
2009-10-13padams2 Changes to resolve Issue-14
2009-10-01padams2 Changes to resolve Issue-12 and Issue-13
2009-09-18padams2 Changes to resolve Issue-9 (reworded some assertions)
2009-08-18padams2 Fixed formatting of assertion 2016 in the appendix
2009-08-18padams2 Changes to resolve Issue-10 (removed assertion 2017)
2009-08-18padams2 Changes to resolve Issue-8; regen'd testcase document
2009-08-12padams2 Follow-up changes for issues 2, 3, and 6 from 8/11 conference call
2009-08-11padams2 Changes to resolve Issue-7 (removed assertion 2041)
2009-08-11padams2 Changes to resolve Issue-6 (removed assertion 2039)
2009-08-11padams2 Changes to resolve Issue-5 (removed assertion 2035)
2009-08-10padams2 Changes to resolve ISSUE-3 (Combined assertions 2022 and 2023)
2009-08-10padams2 Changes to resolve ISSUE-2 (combined assertions 2019 and 2020)
2009-08-10padams2 Changes to resolve Issue-1 (text associated with the contentTypeMismatch fault subcode)
2009-05-06rmerric 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-06rmerric change how assertions Protocol-2035, Protocol-2039, and Protocol-2041 appear in the assertion summary.
2009-05-05rmerric Improve summary text for assertions Protocol-34 & Protocol-40
2009-05-05rmerric remove assertion Protocol-2042 that is a duplicate of its constituent parts
2009-04-29rmerric mark usage of rfc2119 terms where required, tweak assertions so that the assertion summary is clearer.
2009-04-28rmerric expand scope of text inside assertions 1003 and 1004.
2009-04-23rmerric fix syntax error in example "Setting JMS Message Header properties"
2009-04-16rmerric ACTION-82 apply agreed changes to contentType
2009-04-14padams2 Added new fault subcode: unsupportedLookupVariant
2009-04-14rmerric editorial tweak to previous precedence change
2009-04-08rmerric clarify precedence rules for binding properties
2009-03-25rmerric change NONPERSISTENT to NON_PERSISTENT
2009-03-23peaston Clarify the wording and scope of the jndiContext Parameter property
2009-03-19rmerric tweak wording for topicReplyToName
2009-03-19rmerric add topicReplytoName definition
2009-02-10padams2 Added myself as an editor
2009-02-10padams2 Minor wording change re: use of java naming-related properties (Action-61)
2009-01-29rmerric make support for lookupVariant = jndi required. Response to Last Call comment LC03.
2009-01-29rmerric Add support for JMS 1.1 to conformance criteria. Response to Last Call comment LC02.
2008-11-18rmerric point to November draft of URI Scheme
2008-11-12rmerric add precedence question to status section.
2008-10-29rmerric add note about handling of precedence. more minor typos.
2008-10-29rmerric create named types in schema and use them in "Properties affecting binding"
2008-10-29rmerric remove references to the obsolete "context" variant +fix two minor typos
2008-10-22rmerric Remove Editor Note
2008-10-22rmerric add jndiContextParameter
2008-10-22rmerric Add XML Schema as an appendix
2008-10-15rmerric simplify conformance criteria for JMS URI support
2008-10-15rmerric clarify fault: unsupportedJMSMessageFormat
2008-10-14rmerric correct feature URIs
2008-10-14rmerric change conformance criteria
2008-10-09padams2 Modified soapjms.xml with minor edits related to TextMessage.
2008-10-09rmerric fix rfc2045 reference
2008-10-09rmerric Add support for TextMessage and considerations for use of said type.
2008-08-18bmehta Made changes to the spec to show snippets in JMS Message Header and Message properties based on code shown by Eric
2008-07-29rmerric add examples of how to set message properties
2008-07-23ylafon <p> were out of balance as a block level element was in the middle
2008-07-23rmerric Remove Java TM
2008-07-17rmerric Added a non-normative code snippet to DeliveryMode
2008-07-14plehegar Fixed language information
2008-07-11rmerric editorial nits before FPWD
2008-06-25rmerric make valid as well as well-formed!
2008-06-25rmerric MUST & MUST NOT for JMSReplyTo
2008-06-25rmerric Editorial changes identified by Eric and Peter
2008-06-23rmerric fix pointer to IETF JMS URI spec
2008-06-22bmehta Fixed some places where I missed the iri
2008-06-22bmehta Updated with changes based on discussions in meetings and Eric's feedback
2008-06-12peaston Add support for assertion markups
2008-06-10rmerric add the authors as a test
2008-05-01plehegar Using latest version for WSDL 2.0 references
2008-05-01plehegar Added support for CVS changelog
2008-05-01plehegar 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-22plehegar New