This is the second part to SOA’s, in this post we’ll have a look at Message-Oriented Middleware (MOM’s) and other various things to finish of this section.
Message-Oriented Middleware
Message-Oriented Middleware (MOM) is used as a sort of ‘plumbing’ for moving messages between services. We need a MOM in SOA because SOA is all about using messages to connect services.
Remember: The only thing that can get in and out of a Service is a message.
A MOM is middleware that is based on the concept of asynchronous communication. Examples are WebSphere MQ by IBM and MSMQ by Microsoft [1].
Asynchronous
Message-Oriented Middleware is asynchronous. What does this mean? Well, it means that if the sender sends a message, then we do not need to wait for a response from the service. Basically, a MOM does not need to wait for acknowledgements (ACKs) from the service.
Non-Blocking
MOMs are Non-Blocking, what we mean here is that it is possible for a message to be sent to a recipient who is currently, or currently not, processing messages at that time.
Point-to-Point
In Point-to-Point messaging, the sender specifies one, and only one recipient; this message is then delivered only to that recipient.
Delivery Modes
Now we have a simple definition for a point-to-point messaging system; we can state the 3 types of delivery modes that a MOM supports – each of which will be explained :)
- At Most Once
- At Least Once
- Exactly Once
At Most Once
The delivery mode known as “At Most Once” is also a ‘Best Effort’ service.
In this case, the MOM will send a message, and then forget – so Fire-and-Forget. What we mean here is that this is a message exchange pattern where a service sends a message without expecting a response.
This kind of delivery mode is only really useful in situations where it is not essential that the message gets delivered.
Because of this, the message may be lost due to network and/or service failures.
At Least Once
This time, when a message is sent, we do not forget! With this mode the recipient will eventually receive at least one copy of the message being sent.
You may have worked out, that yes, it is possible for an application to receive duplicate messages. That is why this mode is only used when a message must be received and the application receiving the message can cope with duplicates.
If the recipient does not acknowledge (send an ACK message) the receipt of the message to the sender within a certain time, then the sender will resend the message. This is continuously repeated until the sender receives that ACK message!
This mode can survive network and/or service failures, mainly because the message will consistently be resent. But also because this mode requires the sender and receiver to write to stable storage so that they can survive crashes.
This mode uses a type of Two-Phase Commit (2PC), where the receiver needs to acknowledge to the sender that it has received the message.
Exactly Once
With this mode, unlike the previous one, the recipient is guaranteed that it will eventually receive exactly one copy of the message being sent.
Application processing the message “knows” that it has never processed this message before and a duplicate will never be delivered.
In order to make this work, we need to use a variant of 2PC. This variant still requires the recipient to ACK the receipt of the message, but then requires the sender to ACK the receipt of the recipients ACK – that was like a tongue twister to type, haha!
This variant could be called Three-Phase Commit or 3PC. If i am correct, because it has been a few weeks, this variant should also have the more proper name of Handshaking in Networks.
This mode can survive network and/or service failures, mainly because the message will consistently be resent. But also because this mode requires the sender and receiver to write to stable storage so that they can survive crashes.
In Order Delivery
This is a very easy concept to grasp, and it’s name gives it all away really!
Messages are delivered to the receiving application in the same order as they were sent by the sending application, that’s it, really :D
The Need for Interoperability
This states that Services must be able to exchange messages, seeing as services do not share implementation.
Also, Services must be able to select the MOM of their choice (I laughed a little at this). However, there is one huge downside to this “free choice”. MOM’s do not interoperate, therefore, this means that every application must use the same MOM implementation to exchange messages.
Interoperate basically refers to the ability of diverse systems to work together – to work well with another system.
[...] Management Accounting ← Distributed Systems – Complete Summary Service Oriented Architecture – Part (2/2) → [...]
ReplyDelete