The Fuse ESB JMS binding component is built using the Spring 2.0 JMS framework. It allows you to create two types of endpoints:
- Consumer Endpoints
A Consumer endpoint's primary roll is to listen for messages on an external JMS destination and pass them into to the NMR for delivery to endpoints inside of the Fuse ESB container. Consumer endpoints can send responses if one is required.
- Provider Endpoints
A Provider endpoint's primary roll is to take messages from the NMR and send them to an external JMS destination.
![]() | Note |
---|---|
The JMS binding component also supports non-Spring based endpoints. However, the non-Spring based endpoints are deprecated. |
In most instances, you do not need to write any Java code to create endpoints. All of the configuration is done using Spring XML that is placed in an xbean.xml
file. There are some instances where you will need to develop your own Java classes to supplement the basic functionality provided by the binding components default implementations. These cases are discussed at the end of this guide.
The Fuse ESB JMS binding component provides a number of enterprise quality features including:
Support for JMS 1.0.2 and JMS 1.1
JMS transactions
XA transactions
Support of all MEP patterns
SOAP support
MIME support
Customizable message marshaling
A service unit that configures the JMS binding component will contain two artifacts:
xbean.xml
The
xbean.xml
file contains the XML configuration for the endpoint defined by the service unit. The contents of this file are the focus of this guide.Note The service unit can define more than one endpoint.
meta-inf/jbi.xml
The
jbi.xml
file is the JBI descriptor for the service unit. Example 1.1 shows a JBI descriptor for a JMS service unit.The elements shown in Example 1.1 do the following:
The
service
element is the root element of all service unit descriptors. The value of thebinding-component
attribute is alwaysfalse
.The
service
element contains namespace references for all of the namespaces defined in thexbean.xml
file'sbean
element.The
provides
element corresponds to a JMS provider endpoint. Theservice-name
attribute derives its value from theservice
attribute in the JMS provider's configuration.Note This attribute can also appear on a
consumes
element.The
endpoint-name
attribute derives its value from theendpoint
attribute in the JMS provider's configuration.Note This attribute can also appear on a
consumes
element.The
consumes
element corresponds to a JMS consumer endpoint. Theinterface-name
attribute derives its value from theinterfaceName
attribute in the JMS consumer's configuration.Note This attribute can also appear on a
provides
element.
The Fuse ESB Maven tooling provides two archetypes for seeding a project whose result is a service unit for the JMS binding component:
- servicemix-jms-consumer-endpoint
The servicemix-jms-consumer-endpoint archetype creates a project that results in a service unit that configures a JMS consumer endpoint.
Tip You can use the smx-arch command to in place of typing the entire Maven command.
smx-arch su jms-consumer ["-DgroupId=
my.group.id
"] ["-DartifactId=my.artifact.id
"]- servicemix-jms-provider-endpoint
The servicemix-jms-provider-endpoint archetype creates a project that results in a service unit that configures a JMS provider endpoint.
Tip You can use the smx-arch command to in place of typing the entire Maven command.
smx-arch su jms-provider ["-DgroupId=
my.group.id
"] ["-DartifactId=my.artifact.id
"]
The resulting project will contain two generated artifacts:
a
pom.xml
file containing the metadata needed to generate and package the service unita
src/main/resources/xbean.xml
file containing the configuration for the endpointImportant The endpoint configuration generated by the archetype is for the deprecated JMS endpoints. While this configuration will work, it is not recommended for new projects and is not covered in this guide.
If you want to add custom marshalers, custom destination choosers, or other custom Java code, you must add a
java
folder to the generated src
folder. You also need to modify the
generated pom.xml
file to compile the code and package it with the service unit.
To package JMS endpoints as OSGi bundles you need to make two minor changes:
include an OSGi bundle manifest in the
META-INF
folder of the bundleadd the following to your service unit's configuration file:
<bean class="org.apache.servicemix.common.osgi.EndpointExporter" />
![]() | Important |
---|---|
When you deploy JMS endpoints in an OSGi bundle, the resulting endpoints are deployed as a JBI service unit. |
For more information on using the OSGi packaging see Appendix D.
The elements used to configure JMS endpoints are defined in the
http://servicemix.apache.org/jms/1.0
namespace. You will need to add a
namespace declaration similar to the one in Example 1.2 to your
xbeans.xml
file's beans
element.
Example 1.2. Namespace Declaration for Using JMS Endpoints
<beans ...
xmlns:jms="http://servicemix.apache.org/jms/1.0"
... >
...
</beans>
In addition, you need to add the schema location to the Spring beans
element's
xsi:schemaLocation
as shown in Example 1.3.
Example 1.3. Schema Location for Using JMS Endpoints
<beans ...
xsi:schemaLocation="...
http://servicemix.apache.org/jms/1.0 http://servicemix.apache.org/jms/1.0/servicemix-jms.xsd
...">
...
</beans>