JMS

JMS or Java Message Service API is MOM (Message Oriented Middleware) middleware oriented on Java messages, which sends messages between two or more clients. It is implementation, which has the task to solve problem between producer and consumer. MOM products ensure integration among applications. They allow the business components to function together and to be able to create comprehensive, flexible and reliable system. They are completely different components but thanks to the mediator, they can communicate together with the help of messages.

JMS is one of the possible solutions of this problematic, because it provides complete API for developers and allows them to write programs in Java, which can create, receive, send and read messages, which the apps send among each other. Interface file together with associated logic defines, how client accesses the MOM resources.

The JMS goal is providing the maximal amounts of concepts and interface in form that minimalizes the number of concepts, which the programmer needs to know, so he could work with the messages and MOM. Programmer doesn’t have to deal with the technical background of the message circle, with the usage of JMS.

Types of systems

In MOM area are used two different models, i. e. point-to-point or also peer-to-peer and publish-subscribe. Both models differ as in the number of message providers and subscribers as in which way the subscribers pick up their messages and which way then are the messages published.

Point-to-point model

Messages are routed to the individual subscribers, who have queues for incoming messages. These types of sending messages is built on the message, senders and recipients’ queues. Each message is addressed to specific queue and subscriber extracts messages from queue, which is intended for gathering their messages.

Many senders can send messages to queues and each of the messages is guaranteed to be delivered and processed by the recipient. Queues withhold all messages, which are send to them, if they are not processed or until the message expires. If there is not registered any message subscriber, queues keep them, until subscriber signs up.

Publish-and-subscribe model

Publish and subscribe model supports the message publication on the concrete “topic”. Subscribers register their interest in getting messages, which are published on the given topic. To this model, publishers nor subscriber know about the other. System could be compared to the anonymous board with messages.

Message can be received by zero or more recipients. There is a dependency about timing among publishers and subscribers. Publishers must create a topic, to which the subscribers can sign up. The subscriber must constantly stay active to receive the messages, if the subscription is not set to be durable. In that case, as soon as the subscriber connects again, there occurs the redistribution of messages, which were published, whilst the subscriber wasn’t connected.

Advantages of using JMS

• Asynchronous communication. Messages are placed in queues, which allows high efficiency and high deliverability. JMS can also send thousands of messages within seconds to different subscribers with the help of threads and processes.
• Support. JMS specification can be easily implemented on most message servers.
• Reliability. Once are the messages sent, they are reliably delivered to subscribers without data loss.
• Compatibility. If two apps use different types of messages, they can still easily communicate with the help of JMS.
• Load balancing.

Disadvantages of using JMS

• Complexity. It is a new layer with new set of servers. It comes with problems with monitoring, security and other aspects.
• Differences in implementation. Different suppliers don’t always interpret standards the same and because of that, there are differences in implementation.
• Controls. With adding new layer is needed to also add asynchronous data distribution. There is a need of more controls and load balancing.