W3C

SOAP over Java Message Service 1.0

W3C Working Draft 23 July 2008

This version:
http://www.w3.org/TR/2008/WD-soapjms-20080723
Latest version:
http://www.w3.org/TR/soapjms
Editors:
Peter Easton, Progress Software
Bhakti Mehta, Sun Microsystems
Roland Merrick, IBM

Abstract

This document specifies how SOAP should bind 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.

Status of this Document

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 First Public Working Draft 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™ Message Service 1.0. A list of changes is available in E Change Log.

Please send comments about this document to public-soap-jms@w3.org mailing list (public archive).

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

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.

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.3 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.5 Supported Message Exchange Patterns
        2.5.1 Support for Topic destinations
    2.6 Request-Response MEP
        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 2.0 Extensions Overview
    3.4 WSDL 1.1 Extensions Detail
        3.4.1 Example
        3.4.2 WSDL 1.1 Transport Identification
        3.4.3 WSDL 1.1 SOAP Action
        3.4.4 Specifying Properties In WSDL 1.1
        3.4.5 Specifying Properties Via the JMS URI
    3.5 WSDL 2.0 Extensions Detail
    3.6 Properties
        3.6.1 Relationship to WSDL 2.0 Component Model
            3.6.1.1 Precedence

Appendices

A References
B SOAP/JMS Underlying Protocol Binding Examples (Non-Normative)
    B.1 SOAP Request without attachments
    B.2 SOAP Request with attachments
C Acknowledgements (Non-Normative)
D Assertion Summary (Non-Normative)
E 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. It should 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. It should 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 should 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 should 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 should bind 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.

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 may result in a error. How these subcodes should be treated is dealt with in the section "Faults".

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/2008/07/soap/bindings/JMS/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/2008/07/soap/bindings/JMS/.

It is the intent of the W3C SOAP JMS Binding Working Group that the SOAP over Java Message Service 1.0 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

A conforming implementation MUST implement the requirements as specified in 2 The SOAP/JMS Underlying Protocol Binding. To the extent required by that section, conforming implementations MUST support the [URI Scheme for JMS], specifically the syntax manipulations required therein. A conforming implementation MAY implement the requirements in 3 WSDL Usage portion of this document, and if it does so, it MUST fully support the JMS URI scheme, including its syntax, and the implications for invoking JMS related APIs.

2 The SOAP/JMS Underlying Protocol Binding

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.

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, i.e. the first will be used in preference to the second and the second will be used in preference to the third.

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

  2. WSDL elements or attributes (in addition to the endpoint URI), and;

  3. The JMS URI (which may be specified in the WSDL, programmatically, on the command line etc.);

If a given property is specified more than once on the JMS URI the last instance of the property will 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 destination, it is not possible to enumerate all the ways that connection information may 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.

[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). If the variant is "context", then the name is discovered via application context.

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

  • an optional property

  • MAY be specified in JMS URI, WSDL, or somewhere else in the environment

    Editorial note: pse20080610
    Do we want to add an assertion here and for other optional properties like: "If specified, must be used in accordance to this description."
[Definition: soapjms:jndiInitialContextFactory ] (xsd:string)
  • Specifies the fully qualified Java class name of the InitialContextFactory to use. This is mapped to the javax.naming.Context.INITIAL_CONTEXT_FACTORY property to be set in the HashMap sent to an InitialContext constructor.

  • an optional property

  • MAY be specified in JMS URI, WSDL, or somewhere else in the environment

[Definition: soapjms:jndiURL ] (xsd:anyURI)
  • Specifies the JNDI provider URL, which is mapped to the java.naming.provider.url property to be set in the HashMap sent to an InitialContextconstructor.

  • an optional property

  • MAY be specified in JMS URI, WSDL, or somewhere else in the 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] (xsd:string)
  • indicates whether the request message is persistent or not. The valid values are "PERSISTENT" and "NONPERSISTENT". 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 "NONPERSISTENT" then the JMSDeliveryMode integer value MUST be set to DeliveryMode.NONPERSISTENT.

[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 is used to generate the value of the JMS header JMSExpiration.

[Definition: soapjms:priority] (xsd:int)
  • 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 should 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 "context", then the name is discovered via application context.

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

  • if specified, this is 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

  • if specified MUST appear in the JMS message in the JMS property named SOAPJMS_targetService.

[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: Fault subcode unrecognizedBindingVersion if the value of this 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 may be present; if the value of the property is multipart/related, a type parameter may be present.

  • if the charset parameter is specified it is checked to ensure that it matches the encoding value from the supplied XML. If there is a mismatch then a fault is generated. [Definition: Use fault subcode contentTypeMismatch in the event that the values do not match.]

  • if no charset parameter is supplied the charset MUST be inferred using the rules defined in appendix F, Autodetection of Character Encodings , [XML 1.0].

  • the type parameter MUST reflect the value specified in the Content-type part header for the first part (the SOAP body, so text/xml or application/xop+xml).

  • MUST appear in the JMS message in the JMS property named SOAPJMS_contentType. [Definition: Use fault subcode missingContentType if the SOAPJMS_contentType property is missing.]

[Definition: soapjms:soapAction] (xsd:anyURI)
  • as with SOAP/HTTP

  • optional in WSDL, optional in environment

  • if specified MUST appear in the JMS message in the JMS property named SOAPJMS_soapAction.

  • if using SOAP 1.2, and the contentType property has an action parameter, that parameter value MUST match this SOAPJMS_soapAction value. [Definition: Use fault subcode mismatchedSoapAction if the SOAP 1.2 action does not match.]

[Definition: soapjms:isFault] (xsd:boolean)
  • This property indicates whether a SOAP/JMS message is a fault. For senders, this property should be set to true when responding with a SOAP fault. When this property is true, the sending software should include a JMS property named SOAPJMS_isFault with a value of 1.

  • For receivers, this property is derived from the JMS property named SOAPJMS_isFault — if present and containing a value of 1, the value of soapjms:isFault is true. If omitted, or present with a value of 0, the value of soapjms:isFault is false.

Editorial note: pse20080612
Stronger statement needed ?
[Definition: soapjms:requestURI] (xsd:string)
  • Specifies the JMS URI of the service. The client MUST create this property which is derived from the supplied URI. The client MUST remove the targetService query parameter if specified; SHOULD remove JMS Message Header properties; and MAY remove other query parameters (for example client security related properties).

  • a required property

  • MUST appear in the JMS message in the JMS property named SOAPJMS_requestURI. [Definition: Use fault subcode missingRequestURI if the SOAPJMS_requestURI is missing from the message.]

2.2.4 Binding of Properties to URI

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. To conform to the latest enhancements to support internationalization, this specification references the [URI Scheme for JMS]. In particular, this section describes how the properties above are used in the URI [IETF RFC 3987]. 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. The "Client treatment" column describes how the property should be treated in the process of forming the soapjms:requestURI property. There are three options for this column:

  • As-is — the client SHOULD leave the information in the URI as is.

  • Should exclude — the client SHOULD exclude the information from the generated requestURI .

  • Must exclude — the client MUST not include the information in the generated requestURI.

Binding of Properties to URI
Specification PropertyURI RepresentationClient Treatment
deliveryMode as deliveryMode query parameterShould exclude
destinationNameas jms-dest portion of URI syntax As-is
jndiConnectionFactoryName as jndiConnectionFactoryName query parameterShould exclude
jndiInitialContextFactory as jndiInitialContextFactory query parameterShould exclude
jndiURL as jndiURL query parameterShould exclude
replyToName as replyToName query parameterMust exclude
priority as priority query parameterShould exclude
targetService as targetService query parameterMust exclude
timeToLive as timeToLive query parameterShould exclude

[Definition: Use fault subcode malformedRequestURI when the URI violates the expected syntax. ]. [Definition: Use fault subcode targetServiceNotAllowedInRequestURI when targetService parameter is included in the requestURI).]

2.4 The JMS Message Body

The contents of the JMS Message body MUST be the SOAP payload as a JMS BytesMessage. [Definition: Use fault subcode unsupportedJMSMessageFormat when the arriving message format is not supported by the application.]. The encoding will depend on whether the payload is simply a SOAP Envelope or whether there are any attachments, and the JMS "contentType" property 2.2.3 JMS Message properties will reflect this appropriately.

In the case of a message without any attachments, the JMS Message Body will contain the properly encoded bytes of the XML SOAP message, and nothing else. In this case the Content-type will be "text/xml" (for SOAP 1.1) or "application/soap+xml" (for SOAP 1.2).

In the case that there are attachments, the JMS Message Body will contain a multipart MIME message. The first thing encountered in byte stream MUST be the MIME boundary for the start of the first part — what MIME Part One [IETF RFC 2045] section 2.5 calls a "Body Part". The message will be encoded using SOAP Messages with Attachments [SOAP Messages with Attachments] or XOP [SOAP 1.1 Binding for MTOM 1.0] [SOAP MTOM], in either case with a Content-type of "multipart/related".

2.5 Supported Message Exchange Patterns

An instance of a binding to JMS conforming to this binding specification MUST support the following message exchange patterns:

  • Request-Response

  • One-way

In the case of SOAP 1.2 a conforming SOAP-JMS Binding instance MUST support the following 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 and in the case of SOAP 1.1 are specified in this document.

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 MEP

The http://www.w3.org/2003/05/soap/mep/request-response/ message pattern is described in section 6.2, Request-Response Message Exchange Pattern, [SOAP 1.2 Part 2: Adjuncts].

For binding instances conforming to this specification:

  • A SOAP Node instantiated at the JMS interface may 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 may 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

The overall flow of the behaviour of a Requesting SOAP Node follows the outline state machine description contained in section 6.2, Request-Response Message Exchange Pattern, [SOAP 1.2 Part 2: Adjuncts]. The following subsections describe each state in more detail and apply to both SOAP 1.1 and SOAP 1.2 unless stated otherwise.

2.6.1.1 Init

In the "Init" state, a JMS request is formulated and transmission of the request is initiated. The message MUST be created as a JMS BytesMessage 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 specifies how the 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 must determine the reply queue, and use the JMS Destination object which represents that queue; the queue may 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.1.2 Requesting

In the "Requesting" state, sending of the request continues while waiting for the start of the correlated response message. A correlated response message is one where the value of the JMSCorrelationID header field is the same as the value of the JMSMessageID 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 should be listening.

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.

2.6.2 Behaviour of Responding SOAP Node

The overall flow of the behaviour of a Responding SOAP Node follows the outline state machine description contained in section 6.2, Request-Response Message Exchange Pattern, [SOAP 1.2 Part 2: Adjuncts]. The following subsections describe each state in more detail and apply to both SOAP 1.1 and SOAP 1.2.

2.6.2.3 Receiving + Sending

Completing Request Message reception and Response Message transmission. (Response Message sent on exit from Receiving State).

The JMS request is formulated and transmission of the response is initiated. The message MUST be created as a JMS BytesMessage. A number of the message header properties are implicitly created by the use of the JMS API, the following table specifies how the properties described earlier explicitly affect the message constructed. The message MUST be sent to the JMS Destination in the JMSReplyTo header of the Request Message. The value of the JMSCorrelationID header field MUST be set to the same as the value of the JMSMessageID of the request message.

Receiving + Sending State Values
FieldValue Set by Conforming Client
JMS Message Header
JMSDeliveryModethis SHOULD 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.
JMSPrioritythis is copied from the request
JMSCorrelationIDthis is copied from the request JMSMessageID
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.
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 [SOAP 1.2 Part 3: 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 may be received by zero or one receiver. For JMS messages sent to a Topic destination this MEP results in SOAP message(s) which may 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 may take 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 an 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 sending node MUST formulate a JMS request, make it available in the http://www.w3.org/2003/05/soap/mep/OutboundMessage property, and send it to the destination identified by http://www.w3.org/2003/05/soap/mep/ImmediateDestination.

The message MUST be created as a JMS BytesMessage 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 specifies how the properties described earlier explicitly affect the message constructed.

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.

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 detail element should have a single child element with the namespace and local name of that matches the subcode for SOAP 1.2. The same error as above, shown in SOAP 1.1:

An implementation MAY choose to put a textual description as the contents of the element within the detail section. A portion of the above example with this change follows:

3 WSDL Usage

3.4 WSDL 1.1 Extensions Detail

3.4.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/2008/07/soap/bindings/JMS/">
15       <wsdl11soap11:binding style="document" 
              transport="http://www.w3.org/2008/07/soap/bindings/JMS/"/>
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"/>
42       </wsdl11:port>
43   </wsdl11:service>

The key points to notice are:

3.4.2 WSDL 1.1 Transport Identification

The wsdl11soap11:binding element has a transport attribute. The developer indicates the use of the SOAP/JMS binding by putting http://www.w3.org/2008/07/soap/bindings/JMS/ as the value of the transport.

3.4.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.4.5 Specifying Properties Via the JMS URI

Some of the above information can be put in the URI [URI Scheme for JMS]. 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, in turn, is represented as the location attribute on the <wsdl11soap11:address> element. Note that with SOAP 1.2, the same pattern applies, although the "soap" prefix corresponds to the SOAP 1.2 binding namespace http://schemas.xmlsoap.org/wsdl/soap12/ as established by [WSDL 1.1 for SOAP 1.2].

Properties expressed in the URI [IETF RFC 3987] override any values set in the markup as described above.

3.5 WSDL 2.0 Extensions Detail

Section 3.4 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/2008/07/soap/bindings/JMS/"
   xmlns:soapjms="http://www.w3.org/2008/07/soap/bindings/JMS/">
(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>, which indicates that this SOAP over JMS binding is in use.

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 may 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, you may also set connection properties in the URI.

3.6 Properties

Table SOAP/JMS properties which are declarable in WSDL 1.1 and WSDL 2.0 documents lists the SOAP/JMS properties which are declarable in WSDL documents.

SOAP/JMS properties which are declarable in WSDL 1.1 and WSDL 2.0 documents
Property localNameValid WSDL Locations
jndiConnectionFactoryNameservice, port/endpoint, binding
jndiInitialContextFactoryservice, port/endpoint, binding
jndiURLservice, port/endpoint, binding
deliveryModeservice, port/endpoint, binding
priorityservice, port/endpoint, binding
timeToLiveservice, port/endpoint, binding
replyToNameservice, port/endpoint, binding
soapActionbinding operation

3.6.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 table above 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.

3.6.1.1 Precedence

Since the same property can be specified in multiple places, we need precedence rules, and in fact they are exactly as specified in section 3.4.4 Specifying Properties In WSDL 1.1. The most-specific setting overrides less-specific ones, so endpoint wins over service, which wins over binding. For a particular interaction, you may search for a given property on the Endpoint component, then Service, then Binding, taking whichever value you find first.

A 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 3987]
Internationalized Resource Identifiers (IRIs) , M. Duerst and M. Suignard, Authors. Internet Engineering Task Force, January 2005. Available at http://www.ietf.org/rfc/rfc3987.txt.
[Java Message Service]
Java Message Service (JMS) 1.1, M. Hapner, et. al., Authors. Sun Microsystems, Inc., 12 April 2002. Available at http://java.sun.com/products/jms/docs.html
[URI Scheme for JMS]
URI Scheme for Java Message Service 1.0, D. Xiao, R. Merrick, P. Easton, and D. Rokicki, Authors. Internet Engineering Task Force, 22 April 2008. Available at http://www.ietf.org/internet-drafts/draft-merrick-jms-uri-03.txt
[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. Available at http://www.w3.org/TR/SOAP-attachments
[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. Available at http://www.w3.org/Submission/soap11mtom10/
[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/.
[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. Available at http://www.w3.org/TR/2002/NOTE-soap12-email-20020703
[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. Available at http://www.w3.org/TR/2000/NOTE-SOAP-20000508/.
[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. Available at http://www.w3.org/TR/2007/NOTE-soap12-part3-20070702/
[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. Available at http://www.w3.org/TR/2001/NOTE-wsdl-20010315.
[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.  Available at http://www.w3.org/Submission/2006/SUBM-wsdl11soap12-20060405/.
[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/.
[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.
[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 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.
[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.

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

The JMS message consists of three parts, the first of these 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 the last part is the Message Body.

B.2 SOAP Request with attachments

The URI in Example JMS URI will become:

JMS Message Header Values
Fieldvaluecomments
JMSMessage classjms_bytesa fixed value
JMSTypenull
JMSDeliveryMode2
JMSExpiration0
JMSPriority8
JMSMessageIDID:d438e0000001
JMSTimestamp1092110476167
JMSCorrelationIDnull
JMSDestinationA Destination object resolved by JNDI from the destination name news
JMSReplyToA Destination object resolved by JNDI from the destination name interested
JMSRedeliveredfalse
JMS Message Properties Values
Fieldvaluecomments
SOAPJMS_bindingVersion1.0
SOAPJMS_targetServicecurrent-affairsderived from the targetService property
SOAPJMS_requestURIjms:jndi:news?userprop=mystuffderived from the requestURI property
SOAPJMS_contentTypemultipart/related type="application/xop+xml"; boundary="--MIME_boundary"inferred from the SOAP Envelope and presence attachments. In this case it is SOAP 1.2

The following represents a human readable version of the JMS message body:

C 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): Phil Adams (IBM Corporation), Glen Daniels (WSO2), Peter Easton (Progress Software), Mark Hapner (Sun Microsystems, Inc.), Eric Johnson (TIBCO Software, Inc.), Yves Lafon (W3C/ERCIM), Amelia Lewis (TIBCO Software, Inc.), Bhakti Mehta (Sun Microsystems, Inc.), Roland Merrick (IBM Corporation), Mark Phillips (IBM Corporation), Derek Rokicki (Software AG).

Previous members of the Working Group were: Philippe Le Hégaret, Dongbo Xiao.

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

D Assertion Summary (Non-Normative)

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

Summary of Assertions
IdAssertion
Introduction-1001 A conforming implementation MUST implement the requirements as specified in 2 The SOAP/JMS Underlying Protocol Binding.
Introduction-1002 To the extent required by that section, conforming implementations MUST support the [URI Scheme for JMS], specifically the syntax manipulations required therein.
Introduction-1003 A conforming implementation MAY implement the requirements in 3 WSDL Usage portion of this document, and if it does so, it MUST fully support the JMS URI scheme, including its syntax, and the implications for invoking JMS related APIs.
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, i.e. the first will be used in preference to the second and the second will be used in preference to the third.
Protocol-2002 If a given property is specified more than once on the JMS URI the last instance of the property will 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 "NONPERSISTENT" then the JMSDeliveryMode integer value MUST be set to DeliveryMode.NONPERSISTENT.
Protocol-2006 (timeToLive)if specified, this is 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 is 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.
Protocol-2010 (bindingVersion)fixed value "1.0" in the implementation, MUST appear in a JMS property named SOAPJMS_bindingVersion.
Protocol-2011 Fault subcode unrecognizedBindingVersion if the value of this 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. If there is a mismatch then a fault is generated.
Protocol-2013 Use fault subcode contentTypeMismatch in the event that the values do not match.
Protocol-2014 if no charset parameter is supplied the charset MUST be inferred using the rules defined in appendix F, Autodetection of Character Encodings , [XML 1.0].
Protocol-2015 the type parameter MUST reflect the value specified in the Content-type part header for the first part (the SOAP body, so text/xml or application/xop+xml).
Protocol-2016 (contentType)MUST appear in the JMS message in the JMS property named SOAPJMS_contentType.
Protocol-2017 Use fault 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.
Protocol-2019 if using SOAP 1.2, and the contentType property has an action parameter, that parameter value MUST match this SOAPJMS_soapAction value.
Protocol-2020 (soapAction)Use fault subcode mismatchedSoapAction if the SOAP 1.2 action does not match.
Protocol-2021 Specifies the JMS URI of the service. The client MUST create this property which is derived from the supplied URI. The client MUST remove the targetService query parameter if specified; SHOULD remove JMS Message Header properties; and MAY remove other query parameters (for example client security related properties).
Protocol-2022 (requestURI)MUST appear in the JMS message in the JMS property named SOAPJMS_requestURI.
Protocol-2023 Use fault subcode missingRequestURI if the SOAPJMS_requestURI is missing from the message.
Protocol-2024 Binding of Properties to URI
Protocol-2025 Use fault subcode malformedRequestURI when the URI violates the expected syntax.
Protocol-2026 Use fault subcode targetServiceNotAllowedInRequestURI when targetService parameter is included in the requestURI).
Protocol-2027 The contents of the JMS Message body MUST be the SOAP payload as a JMS BytesMessage.
Protocol-2028 Use fault subcode unsupportedJMSMessageFormat when the arriving message format is not supported by the application.
Protocol-2029 In the case of a message without any attachments, the JMS Message Body will contain the properly encoded bytes of the XML SOAP message, and nothing else. In this case the Content-type will be "text/xml" (for SOAP 1.1) or "application/soap+xml" (for SOAP 1.2).
Protocol-2030 In the case that there are attachments, the JMS Message Body will contain a multipart MIME message. The first thing encountered in byte stream MUST be the MIME boundary for the start of the first part — what MIME Part One [IETF RFC 2045] section 2.5 calls a "Body Part". The message will be encoded using SOAP Messages with Attachments [SOAP Messages with Attachments] or XOP [SOAP 1.1 Binding for MTOM 1.0] [SOAP MTOM], in either case with a Content-type of "multipart/related".
Protocol-2031 An instance of a binding to JMS conforming to this binding specification MUST support the following message exchange patterns:
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 and in the case of SOAP 1.1 are specified in this document.
Protocol-2034 The message MUST be created as a JMS BytesMessage as defined in 2.4 The JMS Message Body.
Protocol-2035 Init State Values
Protocol-2036 The message MUST be created as a JMS BytesMessage.
Protocol-2037 The message MUST be sent to the JMS Destination in the JMSReplyTo header of the Request Message.
Protocol-2038 The value of the JMSCorrelationID header field MUST be set to the same as the value of the JMSMessageID of the request message.
Protocol-2039 Receiving + Sending State Values
Protocol-2040 The message MUST be created as a JMS BytesMessage as defined in 2.4 The JMS Message Body.
Protocol-2041 Sending SOAP Node Values
Protocol-2042 The SOAP fault subcodes listed throughout this document, and consolidated here, include:
Protocol-2050 The JMSReplyTo header MUST be assigned a value.
Protocol-2051 The JMSReplyTo header MUST NOT be assigned a value.
WSDLUsage-3001 Various JMS properties described in the SOAP/JMS binding specification may be set in three places in the WSDL — the binding, the service, and the port. Values specified at the service will propagate to all ports/endpoints. Values specified at the binding will propagate to all ports/endpoints using that binding.
WSDLUsage-3002 If a property is specified at multiple levels, the most specific setting will take precedence (port first, then service, then binding).
WSDLUsage-3003 Properties expressed in the URI [IETF RFC 3987] override any values set in the markup as described above.
WSDLUsage-3004 SOAP/JMS properties which are declarable in WSDL 1.1 and WSDL 2.0 documents

E Change Log (Non-Normative)

DateEditorDescription
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