- messaging system = message oriented middleware (MOM)
- decouples producer (of messages) and consumer (of messages)
- they don’t need to know about each other
- loosely coupled systems, asynchronous systems
- better reliability
- JMS = Java Messaging Service
Point to point messaging system
- 1:1 system (one message has to be processed by one consumer)
- or by one of the instances of the application (if there is horizontal scaling)
- no time dependency
- consumer does not need to exist when the message is produced
- messages in server-client architecture
- input queue, output queue (error queue, when the processing of the message on the server side fails)
Error handling
- messages can take time to process
- but when it fails, the messages “stays” in the queue and needs to be processed by another consumer
- error handling using visibility timeout
- when a message is being processed by consumer 1, it is still in the queue, but not visible to other consumers
- if consumer 1 successfully processes the message, it deletes it from the queue
- if not, after the visibility timeout (cca 30 seconds), the message is again visible to other producers
- example: Amazon Simple Queue Service
- error handling using transactions
- with processing a message, a transaction is started
- if success - transaction is committed
- if fail - transaction is rollbacked and the message is “returned” to the queue
- example: JMS, Weblogic server
Publish and Subscribe system
- a 1:N relationship
- 1 message (from 1 producer) can be processed by N consumers
- there is a time dependency - a consumer must be firstly subscribed to some topic and after that, he can get messages published under that topic
- the message is deleted when all registered subscribers consume the message
- two subscribing modes:
- synchronous - blocking with timeout, asking for messages under given topicID
- asynchronous - using event listeners
- event = occurence of a message with a certain topic
- one event can trigger more actions
Store and forward
- allows sending messages between distant environments using “agents”
- when a message in one system/environment is created, it is sent to the agent and stored in it’s queue
- the agent has a remote connection with the other environment
- it tries to send the message
- if not available, the agent keeps the message in the queue and tries again after some timeout
- he has a stored backlog of messages