2. Agenda
• What is JMS?
• JMS Key Elements
• JMS Messaging Domains
• JMS Message Types
• When Can You Use the JMS API?
• Overview of existing Implementations
• Demo
• Q&A
3. What is JMS?
• JMS API is a part of the Java Platform
(Enterprise Edition). JSR 914.
• A specification that describes a common way
for Java programs to create, send, receive and
read distributed enterprise messages
• loosely coupled communication
• Asynchronous messaging
• Reliable delivery
• A message is guaranteed to be delivered
once and only once.
8. When Can You Use the JMS API?
• The provider wants the components not to
depend on information about other components'
interfaces, so that components can be easily
replaced.
• The provider wants the application to run
whether or not all components are up and
running simultaneously.
• The application business model allows a
component to send information to another and to
continue to operate without receiving an
immediate response.
9. ActiveMQ
• HIGHLY configurable
• You can choose a message store
• Has lots of clustering options
• Network of brokers
• Scaling
• Transactions
• Active MQ crashes fairly frequently
• Less performant as compared to RabbitMQ
10. HornetQ
• Written in Java
• JMS and above
• Superb performance
• POJO-based design
• Solid high availability
• Flexible clustering
• Management
• Documentation & Examples
11. WebSphere MQ
• Not free!!! Money, money, money…
• Works on all common platforms
• Messages will be delivered once and once
only
• Data should never be lost
• Message is not just text, it’s something
more…
12. • No ONCE-ONLY semantics
• Multiple consumers can be configured for a
single queue
• Unordered
• Failed messages are re-tried almost
immediately
• It will use only it’s own DB
• Clustering
• Transactions
13. Apache qpid
• Transactions
• HIGHLY configurable
• Management using JMX
• Supports message Priorities
• Automatic client failover using configurable
connection properties
• Clustering
• Has bindings in many languages
14. ZeroMQ
• http://www.slideshare.net/pieterh/overview-of-zeromq
• Many kinds of connection patterns
• Multiplatform, multi-language(30+)
• Fast
• Small(20K lines of C++ code)
• Open source LGPL(large community)
• Easy to experiment and learn
• Scalable to any number of cores
Messaging technologies really focus on one way delivery. Applications send messages tosome destination. Another application can then read the message from that destination.Usually, the application that delivers the message to the destination is called a producer.The application that reads the message is called the consumer. Since producers andconsumers rely on the destination, their processes or threads are loosely coupled.Asynchronous. A JMS provider can deliver messages to a client as they arrive; a client does not have to request messages in order to receive them. Lower levels of reliability are available for applications that can afford to miss messages or to receive duplicate messages.The JMS specification describes a set of programming interfaces that support distributed, enterprise messaging. An enterprise messaging systems enables independent distributed components or applications to interact through messages. These components, whether on the same system, the same network, or loosely connected through the Internet, use messaging to pass data and coordinate their respective functions.exposing only the JMS APIs is to hide the details from the users that want a higher-level API and also to ensure portability among implementations.As long as the vendor adheres to the JMS specification, a user shouldn't have to worry too much about how the implementation is constructed. By itself, it provides no functionality: the API or interfaces are separate from the implementation This gives the benefit of describing in detail what the user view should be, while at the same time allowing vendors to implement the details however they want. JMS is not an implementation of a message-oriented middleware. security and management are not the concerns of the JMS spec
JMS provider An implementation of the JMS interface for a Message Oriented Middleware (MOM). Providers are implemented as either a Java JMS implementation or an adapter to a non-Java MOM. JMS client An application or process that produces and/or receives messages. JMS producer/publisher A JMS client that creates and sends messages. JMS consumer/subscriber A JMS client that receives messages. JMS message An object that contains the data being transferred between JMS clients. JMS queue A staging area that contains messages that have been sent and are waiting to be read. Note that, contrary to what the name queue suggests, messages don't have to be delivered in the order sent. A JMS queue only guarantees that each message is processed only once. JMS topic A distribution mechanism for publishing messages that are delivered to multiple subscribers.
A JMS Application is one or more JMS clients that exchange messages asynchronously. JMS deals with two kinds of message domains. - Point-to-Point (PTP) are built around the concept of message queues. Supports messages containing Java objects and XML pages.1 consumera sender and a receiver have no timing dependencies. the receiver can fetch the mesg whether or not it was running when client sent the msgreceiver acknowledges
Publish-Subscribe systems use a “topic” to send and receive messages. Multiple consumerspublishers and subscribers have timing dependency. a client can consume only msgs published after its subscription and must continue to be active to consume msgs( exception durable subscription)
TextMessage m=session.createTextMessage();
For example, components of an enterprise application for an automobile manufacturer can use the JMS API in situations like these. The inventory component can send a message to the factory component when the inventory level for a product goes below a certain level, so the factory can make more cars. The factory component can send a message to the parts components so that the factory can assemble the parts it needs. The parts components in turn can send messages to their own inventory and order components to update their inventories and to order new parts from suppliers. Both the factory and the parts components can send messages to the accounting component to update their budget numbers. The business can publish updated catalog items to its sales force. Manufacturing is only one example of how an enterprise can use the JMS API. Retail applications, financial services applications, health services applications, and many others can make use of messaging.
Fully supports JMS 1.1 and J2EE 1.4 with support for transient, persistent, transactional and XA messaging.You can probably do anything you want it to with it.You can choose a message store. 4 are already available.Has lots of clustering options: Shared nothing Master-Slave: ACK sent to client when master stores the messageShared Database: Acquires a lock on the DB when any instance tries to access the DBShared Filesystem: Locks a file when accessing the FS. Issues when using NFS with file-locking; or basically any network based file system since file locking is generally buggy in network file systems.Network of brokers: This is an option that allows a lot of flexibility. However, it seems to be a very problematic/buggy way of doing things since people face a lot of issues with this configuration.Scaling: A. Default transport is blocking I/O with a thread per connection. Can be changed to use nioHorizontal scaling: Though they mention this, the way to achieve this is by using a network of brokersPartitioning: We all know Mr. Partitioning, don’t we. The client decides where to route packets and hence must maintain multiple open connections to different brokers.Active MQ crashes fairly frequently, at least once per month, and is rather slowWe were able to perform some tests on Apache Active MQ today, and here are the results: Non persistent mode: 5k messages/secPersistent mode: 22 messages/sec (yes that is correct)With MySQL, I get a throughput of 8 messages/sec. What is surprising is that it is possible to achieve much better results using MySQL but ActiveMQ uses the table quite unwisely. ActiveMQ created the tables as InnoDB instead of MyISAM even though it doesn’t seem to be using any of the InnoDB features.
Written in Java - HornetQ runs on any platform with a Java 5 or later runtime.JMS and above - HornetQ supports the JMS 1.1 API and also defines its own messaging API for maximum performance and flexibility. Other protocols are planned for upcoming releases.Superb performance - HornetQ class-beating high performance journal provides persistent messaging performance at rates normally seen for non-persistent messaging. Non-persistent messaging performance rocks the boat too.POJO-based design - HornetQ has been designed using POJO and minimal third-party dependencies. You choose how you want to use HornetQ: run it stand-alone, integrate it with JBoss Application Server or another Java server/container or embed it directly inside your own product.Solid high availability. HornetQ offers server replication and automatic client failover to eliminate lost or duplicated messages in case of server failure.Flexible clustering - Create clusters of HornetQ servers that know how to load balance messages. Link geographically distributed clusters over unreliable connections to form a global network. Configure routing of messages in a highly flexible way. Adapt HornetQ to your network topology, not the other way round.Management - HornetQ provides a comprehensive management API to manage & monitor servers. It is integrated seamlessly to the servers to work in a HA environment.Documentation & Examples - All HornetQ features are documented and examples are provided. Read the documentation, run the examples and leverage HornetQ features to make your messaging code more robust and performant.
It allows independent and working in different time applications send data to each other in distributed systemMQ works on all common platforms: z/OS (mainframe), OS/400 (IBM System i or AS/400), Transaction Processing Facility, UNIX (AIX, HP-UX, Solaris), HP NonStop, OpenVMS, Linux andMicrosoft WindowsThere are two parts to message queue (hence "MQ"):Messages are collections of binary or character (for instance ASCII or EBCDIC) data that have some meaning to a participating program. As in other communications protocols, storage, routing, and delivery information is added to the message before transmission and stripped from the message prior to delivery to the receiving application.Message queues are objects that store messages in an application.A queue Manager, although not strictly required for message-oriented middleware, is a Websphere MQ prerequisite and system service that provides a logical container for the message queue and is responsible for transferring data to other queue managers via message channels.There are several advantages to this technology:Messages do not depend on pure packet-based transmissions, such as TCP/IP. This allows the sending and receiving ends to be decoupled and potentially operate asynchronously.Messages will be delivered once and once only, irrespective of errors and network problems.WebSphere MQ provides assured one-time delivery of messages across a wide variety of platforms. The product emphasizes reliability and robustness of message traffic, and ensures that a message should never be lost if MQ is appropriately configured.It needs to be remembered that a message in the context of MQ has no implication other than a gathering of data. MQ is very generalized and can be used as a robust substitute for many forms of intercommunication. For example, it can be used to implement reliable delivery of large files as a substitute for FTP.
No ONCE-ONLY semanamntics. Messages may be sent twice by RabbitMQ to the consumer(s).Multiple consumers can be configured for a single queue, and they will all get mutually exclusive messages.Unordered; not FIFO deliveryOnly closing connection NACKs a message. Removing the consumer from that channel does NOT. Hence, all queues being listened to on that channel/connetion are closed for the current consumerNO EXPONENTIAL BACKOFF for failed consumers. Failed messages are re-tried almost immediately. Hence an error in the consumer logic that crashes the consumer while consuming a particular message may potentially block the whole queue. Hence, the consumer needs to be programmed well — error free. However, apps are like; well apps… Consumer has to do rate limiting by not consuming messages too fast (if it wants to); no provision for this in RabbitMQClustering.A RabbitMQ cluster is just a set of nodes running the RabbitMQ. No master node is involved.You need to specify hostname of cluster nodes in a cluster manually on the command line or in a config file.Basic load balancing by nodes in a cluster by redirecting requests to other nodesA node can be a RAM node or a disk node. RAM nodes keep their state only in memory (with the exception of the persistent contents of durable queues which are still stored safely on disc). Disk nodes keep state in memory and on disk.Queue metadata shared across all nodes.RabbitMQ brokers tolerate the failure of individual nodes. Nodes can be started and stopped at willIt is advisable to have at least 1 disk node in a cluster of nodesYou need to specify which nodes are part of a cluster during node startup. Hence, when A is the first one to start, it will think that it is the only one in the cluster. When B is started it will be told that A is also in the cluster and when C starts, it should be told that BOTH A and B are part of the cluster. This is because if A or B go down, C still knows one of the machines in the cluster. This is only required for RAM nodes, since they don’t persist metadata on disk. So, if C is a memory node and it goes down and comes up, it will have to be manually told which nodes to query for cluster membership (since it itself doesn’t store that state locally).Replication needs to be investigated (check addtl resources) however, from initial reading, it seems queue data replication does not existFAQ: “How do you migrate an instance of RabbitMQ to another machine?”. Seems to be a very manual process.Any number of queues can be involved in a transaction
Management using JMX and an Eclipse Management Console application - http://www.lahiru.org/2008/08/what-qpid-management-console-can-do.html The management console is very feature rich.Automatic client failover using configurable connection properties - http://qpid.apache.org/cluster-design-note.htmlhttp://qpid.apache.org/starting-a-cluster.htmlhttp://qpid.apache.org/cluster-failover-modes.htmlCluster is nothing but a set of machines have all the queues replicated All queue data and metadata is replicated across all nodes that make up a cluster All clients need to know in advance which nodes make up the cluster.
WhatisØMQ?Intelligent socket library for messaging.ØMQ Benefits Start with simple/fast language(Python) Move to faster language where needed(C)Run on arbitrary platforms(Windows,Android)Scale to arbitrary sizes(2cores,16cores...)No per-core or per-seat licensingEasy to experiment and learn
Following is the performance result:RabbitMQ: it takes about 1 second to receive 10,000 messages.ZeroMQ. It takes about 15 milli seconds to receive 10,000 messages.Qpid: It takes about 4 seconds to receive 10,000 messages.
These 3 messaging technologies have different approaches on building distributed systems :RabbitMQ is one of the leading implementation of the AMQP protocol (along with Apache Qpid). Therefore, it implements a broker architecture, meaning that messages are queued on a central node before being sent to clients. This approach makes RabbitMQ very easy to use and deploy, because advanced scenarios like routing, load balancing or persistent message queuing are supported in just a few lines of code. However, it also makes it less scalable and “slower” because the central node adds latency and message envelopes are quite big.ZeroMq is a very lightweight messaging system specially designed for high throughput/low latency scenarios like the one you can find in the financial world. Zmq supports many advanced messaging scenarios but contrary to RabbitMQ, you’ll have to implement most of them yourself by combining various pieces of the framework (e.g : sockets and devices). Zmq is very flexible but you’ll have to study the 80 pages or so of the guide (which I recommend reading for anybody writing distributed system, even if you don’t use Zmq) before being able to do anything more complicated that sending messages between 2 peers.ActiveMQ is in the middle ground. Like Zmq, it can be deployed with both broker and P2P topologies. Like RabbitMQ, it’s easier to implement advanced scenarios but usually at the cost of raw performance. It’s the Swiss army knife of messaging :-).Finally, all 3 products:have client apis for the most common languages (C++, Java, .Net, Python, Php, Ruby, …)have strong documentationare actively supported
