1 Introduction

This document defines the concept and behavior of a messaging binding, and a concrete Java Message Service [JMS] based binding that provides that behavior. The binding specified in this document applies to an SCA composite’s services and references. The binding is especially well suited for use by services and references of composites that are directly deployed, as opposed to composites that are used as implementations of higher-level components. Services and references of deployed composites become system-level services and references, which are intended to be used by non-SCA clients.

The messaging binding describes a common pattern of behavior that may be followed by messaging-related bindings, including the JMS binding. In particular it describes the manner in which operations are selected based on message content, and the manner in which messages are mapped into the runtime representation. These are specified in a language-neutral manner.

The JMS binding provides JMS-specific details of the connection to the required JMS resources. It supports the use of Queue and Topic type destinations.

1.1 Terminology

The key words “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 Keywords [RFC2119].

This specification uses predefined namespace prefixes throughout; they are given in the following list. Note that the choice of any namespace prefix is arbitrary and not semantically significant.

Table 1-1 Prefixes and Namespaces used in this specification

*Prefix*	*Namespace*	*Notes*
xs	"http://www.w3.org/2001/XMLSchema"	Defined by XML Schema 1.0 specification
sca	"http://docs.oasis-open.org/ns/opencsa/sca/200903"	Defined by the SCA specifications

1.2 Normative References

[RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.

[JMS] Java™ Message Service Specification v1.1 http://java.sun.com/products/jms/

[WSDL] E. Christensen et al, Web Service Description Language (WSDL) 1.1, http://www.w3.org/TR/2001/NOTE-wsdl-20010315, W3C Note, March 15 2001.

R. Chinnici et al, Web Service Description Language (WSDL) Version 2.0 Part 1: Core Language, http://www.w3.org/TR/2007/REC-wsdl20-20070626/, W3C Recommendation, June 26 2007.

[JCA15] J2EE Connector Architecture Specification Version 1.5
http://java.sun.com/j2ee/connector/

[IETFJMS] M. Phillips, P. Easton, D. Rokicki, E. Johnson, URI Scheme for Java™ Message Service 1.0 http://www.ietf.org/id/draft-merrick-jms-uri-06.txt, IETF Internet-Draft June 2009[1]

[SCA-Assembly] OASIS Committee Draft 03, “Service Component Architecture Assembly Model Specification Version 1.1”, March 2009
http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-1.1-spec-cd03.pdf

[SCA-Policy] OASIS Committee Draft 02, “SCA Policy Framework Specification Version 1.1”, February 2009
http://docs.oasis-open.org/opencsa/sca-policy/sca-policy-1.1-spec-cd02.pdf

1.3 Non-Normative References

TBD TBD

1.4 Naming Conventions

This specification follows some naming conventions for artifacts defined by the specification. In addition to the conventions defined by section 1.3 of the SCA Assembly Specification [SCA-Assembly], this specification adds three additional conventions:

· Where the names of elements and attributes consist partially or wholly of acronyms, the letters of the acronyms use the same case. When the acronym appears at the start of the name of an element or an attribute, or after a period, it is in lower case. If it appears elsewhere in the name of an element or an attribute, it is in upper case. For example, an attribute might be named "uri" or "jndiURL".

· Where the names of types consist partially or wholly of acronyms, the letters of the acronyms are in all upper case. For example, an XML Schema type might be named "JCABinding" or "MessageID".

· Values, including local parts of QName values, follow the rules for names of elements and attributes as stated above, with the exception that the letters of acronyms are in all upper case. For example, a value might be "JMSDefault" or "namespaceURI".

2 Messaging Bindings

Messaging bindings form a category of SCA bindings that represent the interaction of SCA composites with messaging providers. It is felt that documenting, and following this pattern is beneficial for implementers of messaging bindings, although it is not strictly necessary.

This pattern is embodied in the JMS binding, described later.

Messaging bindings utilize operation selector and wire format elements to provide the mapping from the native messaging format to an invocation on the target component. A default operation selection and data binding behavior is identified, along with any associated properties.

In addition, each operation may have specific properties defined, that may influence the way native messages are processed depending on the operation being invoked.

3 JMS Binding Schema

The JMS binding element is defined by the following schema.

<binding.jms correlationScheme=”QName”?

initialContextFactory=”xs:anyURI”?

jndiURL=”xs:anyURI”?

requestConnection=”QName”?

responseConnection=”QName”?

operationProperties=”QName”?

name=”NCName”?

requires=”list of QName”?

policySets=”list of QName”?

uri=”xs:anyURI”? >

<destination jndiName=”xs:anyURI” type=”queue or topic”?

create=”always or never or ifNotExist”?>