A JMS provider can be used as the transport for one-way and request-response operations. A minimal one-way configuration is shown below:
| Code Block | ||||
|---|---|---|---|---|
| ||||
<component name="OneWayClient">
<implementation.java class="..."/>
<reference name="service">
<binding.jms>
<destination namejndiName="serviceQueue"/>
</binding.jms>
</reference>
</component>
<component name="OneWayService">
<implementation.java class="..."/>
<service>
<binding.jms>
<destination namejndiName="serviceQueue"/>
</binding.jms>
</service>
</component>
|
The above configuration uses the "serviceQueue" queue to propagate messages. Depending on the JMS provider, it may also be necessary to specify a connection factory name (see below).
| Info | ||
|---|---|---|
| ||
When writing asynchronous Java components, it is important to remember the @OneWay annotation. If a method is not marked with @OneWay, it will be taken as a request-response operation even if the return value is void. This means the operation will block until a response message is received. |
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
<component name="RequestResponseClient">
<implementation.java class="..."/>
<reference name="service">
<binding.jms>
<destination name="serviceQueue"/>
<response>
<destination namejndiName="responseQueue"/>
</response>
</binding.jms>
</reference>
</component>
<component name="RequestResponseService">
<implementation.java class="..."/>
<service>
<binding.jms>
<destination name="serviceQueue"/>
<response>
<destination namejndiName="responseQueue"/>
</response>
</binding.jms>
</service>
</component>
|
...
When the CallbackClient invokes the CallbackService, the call will return immediately. At some later point in time, a reponse will be delivered asynchronously using the "callbackQueue" queue.In the previous examples, queues where assumed to be externally configured using Fabric3 server settings or the JMS provider.
Specifying Connection Factories
The previous examples assumed the JMS provider did not require the connection factory to be specified for simplicity. However, most JMS providers will require the connection factory to be specified using the conectionFactory element:
| Code Block | ||||
|---|---|---|---|---|
| ||||
<component name="CallbackClient">
<implementation.java class="..."/>
<reference name="service">
<binding.jms>
<connectionFactory jndiName="TheConnectionFactory"/>
<destination name="serviceQueue"/>
</binding.jms>
</reference>
</component>
|
Dynamically Creating Queues
The JMS binding can also be configured to create queues dynamically by using the @create create attribute on the destination element and setting it to "ifnotexist" or "always". Similarly.
| Info | ||
|---|---|---|
| ||
By default, the JMS |
...
binding uses Queues to reference and service bindings. While it is possible to specify a Topic using the type="topic" attribute on the destination element, this should be avoided as doing so may have unintended effects. Specifically, if a service is clustered and bound to a topic, all service replicas in the zone will receive copies of an invocation message. With Queues, only one clustered service replica will receive a copy, which is in most cases the correct behavior for service interactions. |
Wire Formats
The JMS binding supports multiple wire formats including object serialization, JMS message types, and JAXB serialization. If a parameter type is annotated with the JAXB @XmlRootElement annotation, parameters will be sent as XML using a JMS text message. Otherwise, the JMS binding will introspect the parameter types and select the most appropriate message type (e.g. object, bytes, etc).