SOAP over Java Message Service 1.0 RC1

Informal Note October 2006

This version:
http://www.example.org/webservices/soapjms.html
Editors:
Glen Daniels, Sonic Software <gdaniels@sonicsoftware.com>
Eric Johnson, TIBCO Software Inc. <eric@tibco.com>
Vinod Kumar, BEA Systems <vkumar@bea.com>
Amelia A. Lewis, TIBCO Software Inc. <alewis@tibco.com>
Roland Merrick, International Business Machines Corporation <roland_merrick@uk.ibm.com.>
Mark Phillips, International Business Machines Corporation <m8philli@uk.ibm.com>
Stephen Todd, International Business Machines Corporation <stephen_todd@uk.ibm.com.>
Dongbo Xiao, BEA Systems <xiaod@bea.com>
  1. A link or URL to the SOAP-JMS Binding Specification at one of the Authors’ websites

  2. The copyright notice as shown in the SOAP-JMS Binding Specification.


Abstract

Status of this Document

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

This specification may change before final release and you are cautioned against relying on the content of this specification. The authors are currently soliciting your contributions and suggestions. Licenses are available for the purposes of feedback and (optionally) for implementation.

Table of Contents

1 Introduction
    1.1 Background
    1.2 Out of Scope
    1.3 Context
    1.4 Notational Conventions
    1.5 Conformance
2 The SOAP/JMS Underlying Protocol Binding
    2.1 Introduction
    2.2 Binding Name
    2.3 Properties Affecting Binding
        2.3.1 Connection to a destination
        2.3.2 JMS Message Header properties
        2.3.3 JMS Message properties
        2.3.4 Binding of Properties to IRI
        2.3.5 Other Properties
    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.1.1 Init
            2.7.1.2 Sending
            2.7.1.3 Success and Fail
        2.7.2 Behaviour of Receiving SOAP Node
            2.7.2.1 Init
            2.7.2.2 Receiving
            2.7.2.3 Success and Fail
    2.8 Faults
    2.9 Examples
        2.9.1 SOAP Request without attachments
        2.9.2 SOAP Request with attachments
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 Transport Identification
        3.4.3 SOAP Action
        3.4.4 Specifying Properties In WSDL
        3.4.5 Specifying Properties Via the JMS URI
    3.5 WSDL 2.0 Extensions Detail
    3.6 Properties

Appendices

A References (Non-Normative)
B Acknowledgments (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. The main purpose is to ensure interoperability between the implementations of different WebServices vendors. It should also enable customers to implement their own WebServices for part of their infrastructure, and to have this interoperate with vendor provided WebServices. The main audience will be implementors of WebServices stacks; in particular people who wish to extend a WebServices 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 WebServices 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 WebServices 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.

  • The JMS calls that must be made to construct and interpret SOAP/JMS messages.

  • The WSDL binding that may be used to describe SOAP/JMS services

  • The IRI specification for JMS endpoints to be used by SOAP/JMS implementations (and potentially in other areas where a JMS IRI is required)

Note that the IRI specification is in a separate document.

1.2 Out of Scope

It is important to stress what this standard does NOT provide.

  • It does NOT provide any mechanism for interoperation between two different JMS providers. In the example above, VendorA and VendorB are different providers of a WebServices infrastructure, but the customer must still use a single implemenation of JMS at both client and service side.

  • It does NOT define any (wire) format for SOAP/JMS messages.

  • It does NOT define how the WebServices themselves will be presented to the application programmer. For example, it does not describe how the programmer will characterise a one-way message.

1.3 Context

This document specifies how SOAP should bind to a messaging system that supports the Java Message Service (JMS) [JMS]. Binding is specified for both SOAP 1.1 and SOAP 1.2 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 an HTTP binding and is described in [SOAP 1.2 Part 2]. A second binding for Email was also created by some members of the XML Protocol WG and published as a W3C Note -- SOAP Version 1.2 Email Binding [SOAP-EMAIL].

Properties are named with XML qualified names (QNames). Property values are determined by the Schema type of the property, as defined in the specification which introduces the property. The following tables lists the standard prefix mappings which we assume to hold throughout this specification:

Standard Prefix Mappings
PrefixNamespace
soapjmshttp://www.example.org/2006/06/soap/bindings/JMS/
xsdhttp://www.w3.org/2001/XMLSchema
wsdlhttp://schemas.xmlsoap.org/wsdl/
wsoaphttp://www.w3.org/2006/01/wsdl/soap
wsdl11soap11http://schemas.xmlsoap.org/wsdl/soap/
wsdl11soap12http://schemas.xmlsoap.org/wsdl/soap12/

1.4 Notational Conventions

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [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.5 Conformance

A conforming implementation MUST implement the requirements as specified in 2 The SOAP/JMS Underlying Protocol Binding. To extent required by that section, conforming implementations MUST support the [JMS IRI Scheme], 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 IRI scheme, including its syntax, and the implications for invoking JMS related APIs.

2 The SOAP/JMS Underlying Protocol Binding

2.1 Introduction

This section covers the SOAP/JMS binding, and implicitly the JMS calls that must be made. Many people may think of the JMS calls as the SOAP/JMS message format. This is almost correct, but not completely. JMS is strictly an API and does not define a message format. Also, this document covers how the SOAP/JMS implementation connects to the JMS service and selects the appropriate destination.

This part covers details such as how JMS connections and destinations should be handled. It also covers the message content, including how properties and headers such as priority, soapAction and targetService should be handled within the SOAP/JMS implementation.

2.2 Binding Name

The binding described here is identified with the IRI:

http://www.example.org/2006/06/soap/bindings/JMS/

This binding is provided as an example binding when using a transport that is exposed using the Java Message Service (JMS) [JMS] "api".

2.3 Properties Affecting Binding

There are a number of properties that affect how the binding behaves. The following properties are grouped into related sets. A conforming implementation must support all these properties.

Properties can be obtained from a number of sources, the JMS IRI, WSDL and the environment. If a property is specified in more than one of these places then a property in the environment will be used in preference to one specified in WSDL that will itself be used in preference to the JMS IRI. If the property is specified more than once on the JMS IRI the last instance of the property will be used.

2.3.1 Connection to a destination

This set of properties provide the information necessary to resolve the address of the target service and establish a connection.

[Definition: soapjms:destinationName ] (xsd:string)
  • Specifies the Java Naming and Directory Interface (JNDI) name of the destination (queue or topic).

  • MUST be specified in JMS IRI

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

  • an optional property

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

[Definition: soapjms:initialContextFactory ] (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 IRI, 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 IRI, WSDL, or somewhere else in the environment

2.3.2 JMS Message Header properties

This set of properties provide information that will set the values of corresponding JMS Header fields.

[Definition: soapjms:deliveryMode] (xsd:int)
  • indicates whether the request message is persistent or not. The valid values are 1 for nonpersistent and 2 for persistent. The default value is 2 (defaulted by JMS)

  • optional in IRI, optional in WSDL, optional in environment

  • if specified MUST appear in the the JMS message in the header named JMSDeliveryMode.

[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 IRI, 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 IRI, 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 Java Naming and Directory Interface (JNDI) name of the destination to which a response message should be sent. If the replyToName property has a value it is used to retrieve a JMS Destination object which will be found in JNDI under the specified name.

  • optional in IRI, optional in WSDL, optional in environment

  • if specified, this is used to derive the value to be used in the JMS header JMSReplyTo

2.3.3 JMS Message properties

[Definition: soapjms:targetService] (xsd:string)
  • Used by the service implementation to dispatch the service request.

  • optional in IRI

  • 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 [SwA] or MTOM [SOAP11-MTOM] [SOAP12-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 [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 the charset MUST be inferred using the rules defined at Autodetection of Character Encodings from [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, optionally specified in SOAP call

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

[Definition: soapjms:requestIRI] (xsd:string)
  • Specifies the JMS IRI of the service. The client MUST create this property which is derived from the supplied IRI. 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_requestIRI. [Definition: Use fault subcode missingRequestIRI if the SOAPJMS_requestIRI is missing from the message.]

[Definition: soapjms:destinationType] (xsd:string)
  • The destination can have a value of either queue or topic which specifies whether the destination is a queue or a topic

  • optional in IRI, optional in WSDL, optional in environment

  • SHOULD NOT appear in the JMS message

  • MAY be used to cast result from looking up destination in JNDI, or to use old style JMS explicit QueueConnectionFactory, TopicConnectionFactory, etc etc. This in not technically necessary, as SOAPJMS may be implemented with generic JMS code that does not need to be aware of the queue/topic distinction. However, it has value for documentation (someone reading the WSDL can better see the intent and possible usage), and for error checking (where the JMS infrastructure deployment does not match the intended application usage).

[Definition: soapjms:soapMEP] (xsd:string)
  • indicates the SOAP Message Exchange Pattern that this message is part of.

  • inferred by the requesting SOAP node if not explicitly specified. If the replyToName property is found then the "request-response" MEP should be used. If there is no replyToName property then the "one-way" MEP should be used.

  • MUST appear in the JMS message in the JMS property named SOAPJMS_soapMEP. [Definition: Use fault subcode missingSoapMEP if the property does appear in the message.]

  • [Definition: Inconsistency between the value of this property and the JMS ReplyTo header, or any other message header or property of the message, will result in a fault subcode of inconsistentMEP ]

2.3.4 Binding of Properties to IRI

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 "JMS IRI scheme." In particular, this section describes how the properties above are used in the IRI. Note that the IRI 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 "IRI representation" column describes how the property is carried in the IRI. The "Client treatment" column describes how the property should be treated in the process of forming the soapjms:requestIRI property. There are three options for this column:

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

  • Should exclude - the client SHOULD exclude the information from the generated requestIRI .

  • Must exclude - the client MUST not include the information in the generated requestIRI.

Specification PropertyIRI RepresentationClient Treatment
destinationNameas jms-destcode portion of IRI syntax As-is
connectionFactoryName as connectionFactoryName query parameterShould exclude
initialContextFactory as initialContextFactory query parameterShould exclude
jndiURL as jndiURL query parameterShould exclude
deliveryMode as deliveryMode query parameterShould exclude
timeToLive as timeToLive query parameterShould exclude
priority as priority query parameterShould exclude
targetService as targetService query parameterMust exclude
destinationType as destinationType query parameterShould exclude

[Definition: Use fault subcode malformedRequestIRI when the IRI violates the expected syntax.]. [Definition: Use fault subcode targetServiceNotAllowedInRequestIRI when targetService parameter is included in the requestIRI).]

2.3.5 Other Properties

It is possible to specify other properties on the IRI but they do not affect processing. Any such properties will be included in the JMS Message property requestIRI unless explicitly removed by the client. The specification of userid and/or password related properties in the IRI is not recommended.

Note:

A userid and password may be available from the environment and used for accessing the directory.

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 "Content-type" header (sec 3.3) 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 [RFC 2045] section 2.5 calls a "Body Part". The message will be encoded using SOAP Messages with Attachments [SwA] or XOP [SOAP11-MTOM] [SOAP12-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. Relevant information on how SOAP 1.1 should bind to HTTP is specified in that specification [SOAP 1.1].

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.5.1 Support for Topic destinations

Topics may be used as destinations for SOAP messages over JMS. However, due to the potential complexities around how topics might interact with message-exchange patterns, this specification provides no guidelines as to how that message exchange might work. In particular, the "request-response" exchange clearly means something different when an unknown number of responses might be received. Even the "one-way" exchange over a JMS topic differs in subtle ways from the same exchange over HTTP, including the fundamental question of whether the message is received at all, by any listeners.

For these reasons, implementers and clients of this specification are advised to use caution when dealing with JMS topics. We strongly encourage implementers to carefully document their choices around the use and support of topic destinations.

2.6 Request-Response MEP

The http://www.w3.org/2002/06/soap/mep/request-response/ message pattern is described in 6.2 Request-Response Message Exchange Pattern from [SOAP 1.2 Part 2].

For binding instances conforming to this specification:

  • A SOAP Node instantiated at the JMS interface (sending and receiving) 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 (sending and receiving) may take on the role (ie. 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 QNames. 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 6.2 Request-Response Message Exchange Pattern. The following subsections describe each state in more detail and apply to both SOAP 1.1 and SOAP 1.2 until 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 per section 4 above. 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.

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_requestIRIthis is derived from the requestIRI 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
SOAPJMS_soapMEPhttp://www.w3.org/2003/05/soap/mep/request-response/ -- determined by requesting SOAP node
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 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.1.3 Sending + Receiving

Receive a correlated message body that is assumed to contain a SOAP envelope serialised according to the rules for carrying a SOAP message in the media type specified in the JMS Message property SOAPJMS_contentType.

If a well formed response message is received a transition to "Success" is made.

2.6.1.4 Success and Fail

"Success" and "Fail" are the terminal states of the Request-Response MEP. Control over the message exchange context returns to the local SOAP node.

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 6.2 Request-Response Message Exchange Pattern. The following subsections describe each state in more detail and apply to both SOAP 1.1 and SOAP 1.2 until stated otherwise.

2.6.2.1 Init

Receive and validate the inbound request message.

If a well formed request message is received a transition to the local SOAP node is made followed by a transition to the "Receiving" state.

If a malformed request message is received a transition to "Fail" is made.

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

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 reponding 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_requestIRIthis is copied from the requestIRI property in the request message
SOAPJMS_bindingVersionthis is copied from the bindingVersion property
SOAPJMS_contentTypeinferred from the SOAP Envelope and presence of attachments.
SOAPJMS_soapMEPhttp://www.w3.org/2003/05/soap/mep/request-response/ -- determined by requesting SOAP node.
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.6.2.4 Success and Fail

"Success" and "Fail" are the terminal states for the Request-Response MEP. From the point-of-view of the local node this message exchange has completed.

2.7 One-way Message Exchange Pattern

Note:

The XMLP workgroup are creating a Part 3 REC track specification for SOAP 1.2 that explicitly specifies a one-way MEP. A number of proposals have been made in the xml-dist-app list (for example, David Hull comments on three in this message.).

Pending agreement on the recommended SOAP one-way MEP, this section is based on [SOAP One-way MEP] from David Orchard

This message exchange pattern is identified by the URI http://www.w3.org/2006/03/soap/mep/one-way/ from [SOAP One-way MEP].

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 from the table of properties describing MEPs) of SendingSOAPNode.

  • A SOAP Node instantiated at the receiving JMS interface takes on the role (ie. 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 state machine. In the state tables below, 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 QNames. 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.7.1 Behaviour of Sending SOAP Node

This section documents the states through which a Sending SOAP Node can transition during the lifetime of the message exchange. The subsections describe each state in more detail and apply to SOAP 1.2 only.

2.7.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 per section 4 above. 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.

State transitions unconditionally to "Sending" on completion of "Init".

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_requestIRIthis is derived from the requestIRI 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.
SOAPJMS_soapMEPhttp://www.w3.org/2006/03/soap/mep/one-way/ -- determined by requesting SOAP node.
JMS Message Body
bodyA SOAP envelope is serialized according to the media type specified in the JMS Message property SOAPJMS_contentType.
2.7.1.2 Sending

In the "Sending" state, the Sending SOAP Node transmits the message.

If the message is sent without error, then the message is made available in the http://www.w3.org/2003/05/soap/mep/OutboundMessage property, and a transition to "Success" is made.

If the Sender receives a message transmission failure, then a failure reason transmissionFailure is set and a transition to "Fail" is made.

2.7.1.3 Success and Fail

"Success" and "Fail" are the terminal states of the One-Way MEP. Control over the message exchange context returns to the local SOAP node.

2.7.2 Behaviour of Receiving SOAP Node

This section documents the states through which a Receiving SOAP Node can transition during the lifetime of the message exchange. The subsections describe each state in more detail and apply to SOAP 1.2 only.

2.7.2.1 Init

In the "Init" state, the Receiving SOAP Node receives the inbound message.

If the message is received without error, a transition to "Receiving" is made.

If the Receiving SOAP Node receives a message receipt failure, then a failure reason receptionFailure is set and a transition to "Fail" is made.

2.7.2.2 Receiving

In the "Init" state, the Receiving SOAP Node validates the inbound message.

If a well formed message is received, the message is made available in the http://www.w3.org/2003/05/soap/mep/InboundMessage property and a transition to "Success" is made.

If a malformed request message is received a transition to "Fail" is made.

2.7.2.3 Success and Fail

"Success" and "Fail" are the terminal states for the One-Way MEP. Control over the message exchange context returns to the local SOAP node.

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:malformedRequestIRI.

In SOAP 1.2, the subcodes above are used as-is in the env:Value element of the env:Subcode for a SOAP Fault. The following shows an example of a SOAP 1.2 Fault payload with the contentTypeMismatch subcode:

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"
              xmlns:soapjms="http://www.example.org/2006/06/soap/bindings/JMS/"
              xmlns:xml="http://www.w3.org/XML/1998/namespace">
 <env:Body>
  <env:Fault>
   <env:Code>
     <env:Value>env:Sender</env:Value>
     <env:Subcode>
      <env:Value>soapjms:contentTypeMismatch</env:Value>
     </env:Subcode>
   </env:Code>
   <env:Reason>
     <env:Text xml:lang="en">The content type of the JMS payload does 
                             not match the XML.</env:Text>
   </env:Reason>
   <env:Detail>
     <m:MaxTime>P5M</m:MaxTime>
   </env:Detail>    
  </env:Fault>
 </env:Body>
</env:Envelope>

This specification does not mandate any particular text for the env:Text child element of the env:Reason element.

The SOAP 1.1 specification does not support subcodes directly. In that scenario, the 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:

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
   <env:Body>
       <env:Fault>
           <faultcode>SOAP-ENV:Client</faultcode>
           <faultstring>Client Error</faultstring>
           <detail>
               <soapjms:contentTypeMismatch 
                  xmlns:soapjms="http://www.example.org/2006/06/soap/bindings/JMS/" />
           </detail>
       </env:Fault>
   </env:Body>
</env:Envelope>

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:

   <detail>
      <soapjms:contentTypeMismatch 
           xmlns:soapjms="http://www.example.org/2006/06/soap/bindings/JMS/">
        The content type of the JMS payload does not match the XML.
      </soapjms:contentTypeMismatch>
   </detail>

2.9 Examples

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.

2.9.1 SOAP Request without attachments

The IRI:

    jms:news?targetService=current-affairs
        &connectionFactory=SOAPJMSFactory
        &deliveryMode=2
        &priority=8
        &replyToName=interested
        &userprop=mystuff

will become:

The JMS Message header:

Fieldvaluecomments
JMSMessage classjms_bytesa fixed value
JMSTypenull
JMSDeliveryMode2
JMSExpiration0
JMSPriority8
JMSMessageIDID:d438e0000001
JMSTimestamp1092110476167
JMSCorrelationIDnull
JMSDestinationA Destination objectresolved by JNDI from the destination name news
JMSReplyToA Destination objectresolved by JNDI from the destination name interested
JMSRedeliveredfalse

The JMS Message properties:

Fieldvaluecomments
SOAPJMS_bindingVersion1.0
SOAPJMS_targetServicecurrent-affairsthis is derived from the targetService property
SOAPJMS_requestIRIjms:news?userprop=mystuffthis is derived from the requestIRI property
SOAPJMS_contentTypetext/xml; charset=utf-8inferred from the SOAP Envelope and absence of attachments. In this case it is SOAP 1.1
SOAPJMS_soapMEPhttp://www.w3.org/2002/06/soap/mep/request-response/determined by requesting SOAP node.

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

1    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
2       xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" 
3       xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
4       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
5      <soapenv:Body soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
6        <postMessage><ngName xsi:type="xsd:string">news.current.events</ngName>
7          <msg xsi:type="xsd:string">This is a sample news item.</msg>
8        </postMessage>
9      </soapenv:Body>
10   </soapenv:Envelope>

2.9.2 SOAP Request with attachments

The JMS Message header:

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

The JMS Message properties:

Fieldvaluecomments
SOAPJMS_bindingVersion1.0
SOAPJMS_targetServicecurrent-affairsderived from the targetService property
SOAPJMS_requestIRIjms:news?userprop=mystuffderived from the requestIRI property
SOAPJMS_contentTypemultipart/related type="text/xml"; boundary="--Part_1092086011970"inferred from the SOAP Envelope and presence attachments. In this case it is SOAP 1.1
SOAPJMS_soapMEPhttp://www.w3.org/2002/06/soap/mep/request-response/determined by requesting SOAP node.

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

0
1    ----Part_1092086011970
2    Content-Type: text/xml; charset=UTF-8
3    Content-Transfer-Encoding: binary
4    Content-Id: <945414389.1092086011970>
5
6    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
7       xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" 
8       xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
9       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
10      <soapenv:Body soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
11       <postMessage><ngName xsi:type="xsd:string">news.current.events</ngName>
12         <msg xsi:type="xsd:string">This is a sample news item.</msg>
13       </postMessage>
14     </soapenv:Body>
15   </soapenv:Envelope>
16   ----Part_1092086011970
17   Content-Type: image/jpeg
18   Content-Transfer-Encoding: binary
19   Content-Id: <jpegImageRequest=81380956150.1092086011880>
20
21   [n lines omitted]
21+n ----Part_1092086011970--
22+n

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 associated SOAP Underlying Transport Binding above contains the actual rules by which SOAP messages are sent and received using the Java Message Service. 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 the SOAP Binding from [WSDL 1.1]. For information about accepted SOAP 1.2 bindings, see [WSDL 1.1 Extension for SOAP 1.2]. For information about SOAP bindings in WSDL 2.0 see [WSDL 2.0].

3.2 WSDL 1.1 Extensions Overview

  • The transport attribute of the wsdl11soap11:binding or wsdl11soap12:binding element gets a new URL reflecting a JMS transport.

  • Allows use of SOAPAction header, even though it is explicitly disallowed by WSDL specification.

  • Defines how to set various properties to control the behavior (connection parameters, runtime setting) of the binding.

  • Locates the service using a JMS IRI.

3.3 WSDL 2.0 Extensions Overview

  • The wsoap:protocol attribute of the binding element gets a new URL reflecting a JMS transport.

  • Defines how to set various properties to control the behavior (connection parameters, runtime setting) of the binding.

  • Locates the service using a JMS IRI.

3.4 WSDL 1.1 Extensions Detail

3.4.1 Example

The [WSDL 1.1] Specification includes 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 <soap:binding>, and lines 17-22 show the extension properties in the <soap:binding>.

Lines 40-42 are also additions to specify the location at which this new implementation exists. Line 41 shows the jms: IRI in the <soap:address>.

1     <binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
2        <wsdl11soap11:binding style="document" 
                transport="http://schemas.xmlsoap.org/soap/http"/>
3         <operation name="GetLastTradePrice">
4            <wsdl11soap11:operation soapAction="http://example.com/GetLastTradePrice"/>
5           <input>
6               <wsdl11soap11:body use="literal"/>
7            </input>
8           <output>
9               <wsdl11soap11:body use="literal"/>
10          </output>
11        </operation>
12    </binding>
13
14   <binding name="StockQuoteSoapJMSBinding" type="tns:StockQuotePortType" 
              xmlns:soapjms="*placeholder*">
15       <wsdl11soap11:binding style="document" 
              transport="http://www.example.org/2006/06/soap/bindings/JMS/"/>
16
17       <!-- We want this binding to use a particular CF class -->
18       <soapjms:connectionFactoryName>
19         sample.jms.ConnectionFactory
20       </soapjms:connectionFactoryName>
21       <!-- Specify PERSISTENT delivery mode -->
22       <soapjms:deliveryMode>2</soapjms:deliveryMode>
23
24       <operation name="GetLastTradePrice">
25         <wsdl11soap11:operation soapAction="http://example.com/GetLastTradePrice"/>
26         <input>
27             <wsdl11soap11:body use="literal"/>
28         </input>
29         <output>
30             <wsdl11soap11:body use="literal"/>
31          </output>
32       </operation>
33   </binding>
34
35   <service name="StockQuoteService">
36       <documentation>My first service</documentation>
37       <port name="StockQuotePort" binding="tns:StockQuoteSoapBinding">
38           <wsdl11soap11:address location="http://example.com/stockquote"/>
39       </port>
40       <port name="StockQuotePort_jms" binding="tns:StockQuoteSoapJMSBinding">
41           <wsdl11soap11:address location="jms:myQueue?targetService=stockquote"/>
42       </port>
43   </service>

The key points to notice are:

  • The transport URI in <wsdl11soap11:binding> (line 15)

  • The jms: IRI in the <wsdl11soap11:address> (line 41)

  • The extension properties in the <wsdl11soap11:binding> (lines 17-22)

3.4.2 Transport Identification

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

Example:


<wsdl11soap11:binding style="document" 
                 transport="http://www.example.org/2006/06/soap/bindings/JMS/"/>

Issue (message-format):

For discussion: Do we need to specify the message format, and do we put it in the URI?

Resolution:

None recorded.

3.4.3 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.4 Specifying Properties In WSDL

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. For example, the "InitialContextFactory" may be indicated for a wsdl:service, and it is then implied for all of the contained wsdl:port elements.

If a property is specified at multiple levels, the most specific setting will take precedence (port first, 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.


<wsdl:binding name="exampleBinding">
  ...
  <soapjms:timeToLive>200</soapjms:timeToLive>
</wsdl:binding>

<wsdl:service name="exampleService">
  <soapjms:contextFactoryName>
    com.example.jndi.InitialContextFactory
  </soapjms:contextFactoryName>
  <soapjms:timeTolive>100</soapjms:timeToLive>
  ...
  <wsdl:port name="quickPort" binding="tns:exampleBinding">
    ...
    <soapjms:timeToLive>10</soapjms:timeToLive>
  </wsdl:port>
  <wsdl:port name="slowPort" binding="tns:exampleBinding">
    ...
  </wsdl:port>
</wsdl:service>

3.4.5 Specifying Properties Via the JMS URI

Some of the above information can be put in the IRI. (See [JMS IRI Scheme]) When expressing properties from the SOAP/JMS binding in the IRI, you do not need the namespace prefix - just use the property name, such as "priority".

This IRI, 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 Extension for SOAP 1.2]

Properties expressed in the IRI override any values set in the markup as described above.

Example:


<definitions .... >
    <port .... >
       <wsdl11soap11:address location="jms:destinationName?targetService=service1"/> 
    </port>
</definitions>

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


1     <binding name="StockQuoteSoapJMSBinding" interface="tns:StockQuoteInterface" 
2          type="http://www.w3.org/2006/01/wsdl/soap"
3          wsoap:protocol="http://www.example.org/2006/06/soap/bindings/JMS/"
4          xmlns:soapjms="http://www.example.org/2006/06/soap/bindings/JMS/">
5
6       <!-- We want this binding to use a particular CF class -->
7       <soapjms:connectionFactoryName>
8         sample.jms.ConnectionFactory
9       </soapjms:connectionFactoryName>
10      <!-- Specify PERSISTENT delivery mode -->
11       <soapjms:deliveryMode>2</soapjms:deliveryMode>
12    </binding>
13
14    <service name="StockQuoteService" interface="tns:StockQuoteInterface">
15       <documentation>My first service</documentation>
16       <endpoint name="SOAPHTTP" binding="tns:StockQuoteSoapHTTPBinding"
17                 address="http://example.com/stockquote"/>
18       <endpoint name="JMS" binding="tns:StockQuoteSoapJMSBinding"
19             address="jms:myQueue/stockquote"/>
20   </service>

Line 3 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:connectionFactoryName> and <soapjms:deliveryMode> elements defining the values for the connectionFactoryName and deliveryMode properties. More generally, each property becomes 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:int.

Lines 18-19 are also additions to specify the location at which this new implementation exists. Line 19 showing the jms: IRI in the address attribute of the <endpoint> element. As with the WSDL 1.1 binding, you may also set connection properties in the IRI.

3.6 Properties

Property localNameValid WSDL Locations
connectionFactoryNameservice, port/endpoint, binding
contextFactoryNameservice, port/endpoint, binding
jndiURLservice, port/endpoint, binding
deliveryModeservice, port/endpoint, binding
priorityservice, port/endpoint, binding
destinationTypeservice, port/endpoint, binding
timeToLiveservice, port/endpoint, binding
soapActionbinding operation

A References (Non-Normative)

JMS
Sun Microsystems, Java Message Service (JMS) 1.1, April 2002. (See http://java.sun.com/products/jms/docs.html.)
RFC 2045
IETF RFC 2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, N. Freed, Innosoft, N. Borenstein, 1996. (See http://www.ietf.org/rfc/rfc2045.txt.)
SwA
W3C Note SOAP Messages with Attachments, John Barton, Satish Thatte, Henrik Frystyk Nielsen, December, 2000 (See http://www.w3.org/TR/SOAP-attachments.)
SOAP11-MTOM
W3C Member Submission, SOAP 1.1 Binding for MTOM 1.0, Christopher Ferris, Jonathan Marsh, et. al., 05 April 2006. (See http://www.w3.org/Submission/2006/SUBM-soap11mtom10-20060405/.)
SOAP12-MTOM
W3C Recommentation, SOAP Message Transmission Optimization, Martin Gudgin, Noah Mendelsohn, Mark Nottingham, Hervé Ruellan, 25 January 2005. (See http://www.w3.org/TR/2005/REC-soap12-mtom-20050125/.)
XML 1.0
W3C Recommendation, Extensible Markup Language (XML) 1.0 (Fourth Edition) (See http://www.w3.org/TR/2006/REC-xml-20060816/.)
SOAP-EMAIL
W3C Note, SOAP Version 1.2 Email Binding, Highland Mary Mountain, Jacek Kopecky, Stuart Williams, Glen Daniels, Noah Mendelsohn, 3 July 2002. (See http://www.w3.org/TR/soap12-email.)
IETF RFC 2119
IETF (Internet Engineering Task Force). RFC 2119: Key words for use in RFCs to Indicate Requirement Levels. Scott Bradner, 1997. (See http://www.ietf.org/rfc/rfc2119.txt.)
SOAP 1.1
W3C Note, Simple Object Access Protocol (SOAP) 1.1, Don Box, David Ehnebuske, Gopal Kakivaya, Andrew Layman, Noah Mendelsohn, Henrik Frystyk Nielsen, Satish Thatte, Dave Winer, 8 May 2000 (See http://www.w3.org/TR/2000/NOTE-SOAP-20000508/.)
SOAP 1.2 Part 2
W3C Recommendation, SOAP Version 1.2 Part 2: Adjuncts, Martin Gudgin, Marc Hadley, Noah Mendelsohn, Jean-Jacques Moreau, Henrik Frystyk Nielsen, 24 June 2003. (See http://www.w3.org/TR/soap12-part2/.)
SOAP One-way MEP
W3C mailing list, SOAP One-way MEP, David Orchard, 30 March 2006. (See http://lists.w3.org/Archives/Public/xml-dist-app/2006Mar/att-0045/one-way-mep-simple.html.)
WSDL 1.1
W3C Note, Web Services Description Language (WSDL) 1.1, Erik Christensen, Francisco Curbera, Greg Meredith, Sanjiva Weerawarana, 15 March 2001. (See http://www.w3.org/TR/wsdl.)
WSDL 1.1 Extension for SOAP 1.2
WSDL 1.1 Binding Extension for SOAP 1.2, Christopher Ferris, Jonathan Marsh, et. al., 2 March 2006. (See http://schemas.xmlsoap.org/wsdl/soap12/WSDL11SOAP12.pdf.)
WSDL 2.0
Web Services Description Language (WSDL) Version 2.0 Part 2: Adjuncts, Roberto Chinnici, Hugo Haas, Amelia A. Lewis, et. al., 27 March 2006. (See http://www.w3.org/TR/2006/CR-wsdl20-adjuncts-20060327.)
JMS IRI Scheme
IRI Scheme for Java Message Service 1.0, D. Xiao, R.A. Merrick, G. Daniels, E.Johnson, September 2006.

B Acknowledgments (Non-Normative)

The authors gratefully acknowledge the contributions of: Phil Adams (IBM); Glen Daniels (Sonic Software); Lei Jin (BEA Systems, Inc.); Eric Johnson (TIBCO Software Inc.); Vinod Kumar (BEA Systems, Inc.); Amelia A. Lewis (TIBCO Software Inc.); Roland Merrick (IBM); Mark Phillips (IBM); Stephen Todd (IBM); and Dongbo Xiao (BEA Systems, Inc.).