Reliability

When implementing Soap2Jms a special attention has been placed to reliability (the ability of the system to deliver messages over the time) and resilience to temporary network failures. JMS has built-in error recovery features, implementing the same feature using SOAP over HTTP requires extra coding effort.

Sending messages to a queue

A good reading on message sending can be found in the ActiveMQ guide . Below an extract of the most important part:

When sending messages from a client to a server, if the target server or connection fails sometime after sending the message, but before the sender receives a response that the send (or commit) was processed successfully then the sender cannot know for sure if the message was sent successfully to the address.

If the target server or connection failed after the send was received and processed but before the response was sent back then the message will have been sent to the address successfully, but if the target server or connection failed before the send was received and finished processing then it will not have been sent to the address successfully. From the senders point of view it's not possible to distinguish these two cases.

When the server recovers this leaves the client in a difficult situation. It knows the target server failed, but it does not know if the last message reached its destination ok. If it decides to resend the last message, then that could result in a duplicate message being sent to the address.

What has been implemented in Soap2Jms is an Enterprise Pattern called Idempotent Receiver . The client can resend the message and only one copy will be placed in the destination queue.

Duplicate message detection

What we try to acheive is that each message is put exaclty once in the destination queue.

TODO: client generated id. Automatic generated id.

References

  • Brewer's theorem: https://en.wikipedia.org/wiki/CAP_theorem