Local JMS implements synchronous, extremely high-performance messaging. However, many messaging applications require messaging to be asynchronous. When a sender sends a message asynchronously, the message is handed off to the JMS provider, and the sender continues on with its work. After the sender passes the message to the JMS provider, the sender does not need to be informed if or when the message has been delivered to its final recipients.

Asynchronous messaging is useful for processes that can be broken down into separate stages, where each stage might take an unknown amount of time. For example, ATG Commerce uses asynchronous messaging to process an order. Each stage in the order (calculating tax, checking inventory, sending orders to shipping houses, sending confirmation email to the user) is a single action that is activated by an incoming message from the previous stage, and ends by sending a message to the next stage in the process. When the user submits an order, a message is sent to the first stage in the process. The user is told that the ordering process has started, but does not know about the completion of the process until a later email is sent.

Another key difference between Local JMS and SQL JMS is message persistence. Local JMS stores no state, so if the system fails, all messages are lost. SQL JMS uses an SQL database for persistence of messages. This ensures that messages are not lost in the event of system failure, and enables support for persistent queues and durable subscriptions, as described in Message Persistence.

To deliver messages, SQL JMS polls the database periodically, checking the appropriate tables to see if any new messages were written. If so, those messages are delivered to the appropriate message receivers and then removed from the database. This all occurs transactionally, so if a failure occurs or the transaction rolls back, the messages are all returned to the database, again guaranteeing that messages do not get lost.

Note: In SQL JMS, the sending of a message and the receiving of a message occur in separate transactions. A sender might send a message in a transaction that later commits successfully. This does not mean that the receiver has successfully received the message. It just means that SQL JMS has successfully delivered the message to its destination. At some point in the future, receipt of the message is placed in another transaction. The message is then removed from the database when that second transaction successfully commits.

SQL JMS uses standard JDBC drivers to communicate with the database. This allows SQL JMS to operate in a distributed environment, where an Oracle ATG Web Commerce server and the database are located on different machines. SQL JMS can also run on multiple Oracle ATG Web Commerce servers at once, all utilizing the same database. This enables multiple Oracle ATG Web Commerce servers to use SQL JMS to communicate with each other. Finally, if the JDBC driver supports the XA protocol, SQL JMS also supports XA, so it can participate in transactions involving multiple resources.

By default, the connection factory for all SQL JMS topic and queue connections (including XA connections) is the Nucleus component /atg/dynamo/messaging/SqlJmsProvider. If you are using SQL JMS with Patch Bay, you can specify a different connection factory when you configure Patch Bay (though there is generally no reason to do so). If you are using SQL JMS without Patch Bay, you cannot specify a different connection factory.

From the developer’s perspective, very little changes when using SQL JMS instead of Local JMS. The message source and receiver components are still coded in essentially the same way whether they are using Local JMS or SQL JMS. The main difference is that the components are configured by pointing them at SQL JMS destinations rather than Local JMS destinations.