The consequence of not thinking about reliable communication or not implementing it in our OSB services can lead to many problems in case of error. It can lead to the loss of your messages, a destination can receive multiple messages and this means that the sending application can't trust the service bus. The application needs to monitor its own requests.

Reliable communication is all about Distributed Transactions—XA, Quality of Service (QoS), and persistence.

XA is a transaction that can be shared across multiple resources such as a JMS queue, coherence, direct binding, JCA binding, or an EJB session bean. Be aware that the HTTP transport does not support XA and can't take part in the so called global transaction. When an OSB transport or a JCA adapter starts a transaction, this transaction will be handled or controlled by the Java Transaction API (JTA) of the WebLogic server. XA will use a two-phase commit so all resources either do a commit or a rollback together.

When a destination does not take part in the global transaction, the message can be delivered more than once if there is a rollback and the OSB process is retried.

Besides XA, QoS is also important for reliable communication. With QoS. We can also control if the destination will take part in the global transaction. Choose, for example, exactly, Once for joining the global transaction or best, effort for not. Exactly, once means reliability through message assurance, as the OSB is trying to deliver the messages from inbound to outbound exactly once.

With XA and QoS, it is possible to create a loop when there is a rollback and the messages are retried infinitely. This leads to Denial of Service (DOS) on the OSB server. When the message is retried and the destination does not take part in the global transaction, then it is possible that the message is delivered to the destination more than once.

The third aspect of reliable communication is persistence. Persistence is important when the WebLogic server goes down unexpectedly. When the messages are stored in memory, they are lost in cases of a server crash or a reboot. To make persistence highly available, the storage subsystem plays an important role as well, that is, the persistent store must be configured on a shared disk.

If either the sending or the receiving application can detect failures or duplicate messages, then reliable communication might not be necessary. However, in most cases we should think about it and implement it in a good way. At least we should know what the behavior of a proxy or business service is in case of an error and test all the possible scenarios.

Off course, reliable communication also has some downsides such as the transaction overhead and the performance will be less with Exactly Once QoS.

In terms of reliable SOAP messaging, you can choose SOAP over JMS or WS-RM. With SOAP over JMS, we need to define a queue and change the endpoint. With WS-RM, we don't need to change anything and the reliable communication will be handled by the client and the service.