JMS Binding Component Scenarios

The following scenarios show how the JMS Binding Component can consume messages and provide messages.

• Outbound Scenario

• Inbound Scenario

• XA Scenario

• Outbound InOut Exchange Scenario

• Inbound InOut Exchange Scenario

• On Demand Receive Scenario

Outbound Scenario

The following diagram illustrates an outbound scenario.

The HTTP Binding Component consumes an external web service client message. The HTTP Binding Component sends an InOnly message exchange to the BPEL Service Engine. The BPEL Service Engine performs a simple translation of the input message to an output message. The BPEL Service Engine sends the message exchange to the JMS Binding Component.

The JMS Binding Component converts the normalized message in the InOnly message exchange to a JMS text message. The JMS Binding Component sends the text message to a configured JMS topic.

In this scenario, the BPEL Service Engine cannot automatically correlate the incoming and outgoing messages for the business process because the message does not acquire a message ID until the JMS Binding Component sends the message. If correlation is needed in order to support request reply processing, manually correlate the Message ID of the message the JMS Binding Component sends to the Correlation ID of the reply request.

Inbound Scenario

The following diagram illustrates an outbound scenario.

The JMS Binding Component receives a JMS message from a JMS topic. The JMS Binding Component normalizes the JMS message to an InOnly message exchange. The JMS Binding Component sends the message exchange to the BPEL Service Engine.

The BPEL Service Engine invokes the HTTP Binding Component to send a message to a web service.

XA Scenario

The following diagram illustrates an XA scenario.

The inbound JMS Binding Component receives a text message from JMS queue 1. The JMS Binding Component starts an XA transaction and enlists its XAResource. The JMS Binding Component normalizes the JMS message and sends the message as a transacted InOnly message exchange. The message exchange contains the transactional context as a property keyed by MessageExchange.JTA_TRANSACTION_PROPERTY_NAME.

The XSLT Service Engine propagates the transaction in the InOnly message exchange that it creates and sends it to the outbound JMS Binding Component. The outbound JMS Binding Component denormalizes the message exchange to a JMS message and sends the JMS message to JMS queue 2, as part of the XA transaction created by the inbound JMS Binding Component.

Upon completion of both InOnly message exchanges, the inbound JMS Binding Component commits the XA transaction (thereby committing both the JMS receive and the JMS send).

The JMS Client Trigger and JMS Client Verifier are external JMS clients used to initiate the message exchanges and to verify the result. Once the transaction is committed, the JMS Client Verifier receives the expected JMS message sent by the outbound JMS Binding Component.

Outbound InOut Exchange Scenario

In this use case, the JMS Binding Component receives an InOut exchange from its consuming partner (for example, the BPEL Service Engine).

It denormalizes the message found in the "In" portion of the InOut message exchange to a JMS message. It then creates a temporary queue or topic, "Q-temp", and sets the JMS message property, called JMSReplyTo, with this temporary queue or topic. It sends the JMS message to the request queue "Q-in". It waits to receive the reply (a JMS message) from the temporary queue or topic.

When it receives the reply message from the temporary queue or topic, it normalizes the JMS message and sets it as the message in the "Out" portion of the InOut message exchange.

It then sends the InOut message exchange to the consuming partner. Finally, it waits for the message exchange status from the consuming partner to complete the InOut message exchange.

Inbound InOut Exchange Scenario

In this use case, the JMS Binding Component is an external proxy consumer for an external service consumer.

It receives a JMS message from input queue "Q-in". It creates an InOut message exchange. It normalizes the JMS message and sets it as the message in the "In" portion of the InOut message exchange. It then sends the InOut exchange to its providing partner (for example, the BPEL Service Engine). It then waits for the reply from its providing partner for the InOut exchange via the NMR.

Upon receiving the reply, it denormalizes the message found in the "Out" portion of the InOut exchange to a JMS message.

It then extracts the topic or queue, "Q-temp", found in the JMS request message's JMSReplyTo property and sends the JMS reply message to this reply queue or topic.

Finally, upon successfully sending the JMS reply message to the JMSReplyTo queue or topic, it sends back a DONE response on the InOut message exchange to the providing partner.

On Demand Receive Scenario

The HTTP Binding Component consumes a request message from an external web service client. The HTTP Binding Component sends an InOnly message exchange to the BPEL Service Engine. The BPEL Service Engine performs a simple translation of the input message to an output message. The BPEL Service Engine sends the message exchange to the JMS Binding Component.

The JMS Binding Component converts the normalized message in the InOnly message exchange to a JMS text message. The JMS Binding Component sends the text message to a configured JMS topic or queue.

The JMS Binding Component receives a JMS reply message from the JMS topic or queue. The JMS Binding Component normalizes the JMS message to an InOnly message exchange. The JMS Binding Component sends the message exchange to the BPEL Service Engine.

The BPEL Service Engine invokes the HTTP Binding Component to send a message to the external web service client.