I'm trying to wrap my brain around JMS and have been reading up on some very helpful sources and examples. I'm now trying to see the "big picture" here and put all the theory behind JMS into a practical context where real enterprise technologies are used.
So here we have four elements: (1) JMS - a Java API for MOM, (2) ActiveMQ - one of the many JMS implementations, (3) EIP - an intriguing and mysterious beast I am only beginning to understand, and finally, (4) Apache Camel, an open source implementation of that beast.
I am trying to now relate these components together to see JMS (and, in general, enterprise-class messaging) in action.
I guess the first thing I'm looking for is a simple and concise definition for what EIPs are. They seem to be a whole set of design patterns for how MOMs should behave, but since I'm already fuzzy on the concept of messaging to begin with, this is just a fuzzier definition being added on top of an already-fuzzy understanding of some pretty hardcore concepts.
Even if I don't "get" what EIPs are, I do "get" that frameworks like Camel, Mule and ServiceMix implement them and allow server-side components ("endpoints") to message each other efficiently.
Most important to this question is my understanding of how these four components relate to one another. I think understanding this will help me connect most of the dots; well, the important ones anyway.
So in the diagram above I labeled all 6 possible relationships and refer to them below:
JMS:ActiveMQ - I understand ActiveMQ to be an implementation of JMS, much like Hibernate is an implementation of JPA. Is this correct?
ActiveMQ:Camel - Camel has the ability to push messages to any JMS implementation, such as ActiveMQ. In this case ActiveMQ is a camel endpoint. Correct?
EIP:Camel - Camel is an implementation of EIPs. Understanding what EIPs are in the first place is also important to my understanding of this entire setup.
EIP:JMS - Although there may not be a direct connection between these two, it seems as though messaging is at the core of EIP, and JMS is Java's foundation for messaging. Is this a fair assessment?
I left relations between EIP:ActiveMQ and JMS:Camel in case there are any "big concepts" that I should be aware of between these systems.
Any help in putting a simple-to-understand definition to EIP and in understanding how all these components relate to each other is greatly appreciated. Thanks in advance!
ActiveMQ is an implementation of a MOM. It provides a client-side implementation of the JMS API for use by JVM languages. JMS is just an API, but implementations are tied to whatever broker they talk to by a wire format, so you can't use the ActiveMQ JMS implementation to talk to WebsphereMQ, for example. There exist other APIs to talk to ActiveMQ from other language platforms - C/C++ via CMS, .Net via NMS. You can also talk to ActiveMQ via other "non-JMS-like" mechanisms, such as via the STOMP protocol which has client libraries in Ruby, Javascript and others.
Yes.
Yes and no. Camel uses the same "language" as EIPs, so by using Camel, you naturally pick up the EIPs. Having said that, knowing them lets you know what you are looking for in the API. I recommend Camel in Action to get a good understanding of the two, and refer to the EIP site (http://www.eaipatterns.com/) when you want to get a bit more info.
Again yes and no. There are a number of patterns implemented via messaging (JMS is only one flavour), but there are a large number of patterns that have a much broader application (e.g. Splitter, Aggregator). Have a look through the EIP site index to get a feel for this.
Camel can talk to other systems using it's JMS component, which uses any underlying messaging provider that supports that API (Websphere, Sonic, OpenMQ etc.). It can also talk over other messaging technologies, such as those that support the AMQP API.
Hope that helps.
Related
So I'm planning on writing an application that would lend itself well to a producer/consumer pattern. I was thinking of building out my own producer/consumer framework but then thought about message queues something I use extensively at work. I'm not a 100% sure that a messaging queue would be the right approach considering that the multiple modules of the application I am writing need to run on a single server as its a client/controller of sorts for that particular host.
What are the pros and cons of using messaging queues for a non-distributed application? Has anyone used it in this way before?
Thanks, let me know if you need more information.
By "message queues" do you mean an external message server? My below answer assumes that is what you were aking about. If you are just asking about the more general architectural approach of having modules communicate partially, or in full, via in-memory-messages instead of method calls--yes sometimes this can be very nice. Classes like guava's EvenBus facilitate a design like this nicely: https://code.google.com/p/guava-libraries/wiki/EventBusExplained
On the one hand I generally try to discourage people from using JMS message queues when a simple queue data structure would suffice. Sometimes I feel that JMS is an inter-process communication tool that has one-to-many (topics) and one-to-one communication channels which happen to be named queues. Yes their access pattern is similar to that of a queue, but the more important characteristic, it seems to me, is their point-to-point messaging capability. So an unfortunate name that I think sometimes causes people to use a jackhammer (JMS) when all they need is a screwdriver (java.lang.Queue).
On the other hand there are exceptions to any rule. I can't recommend, off hand, a java.lang.Queue implementation that is thread-safe and persistent during server restart (an often needed feature when people are considering JMS). I'm sure there are some. Find a few and compare them to JMS. Weigh business needs, time constraints, possible future design/requirements, etc. I have implemented one myself before and it turned out quite nice (and was faster than sending messages over the network to a remote JMS server)-- but only you can say if this is right for your situation.
I suppose you could always defer the decision by having the modules of your app communicate through a messaging-like interface of your own which uses java.lang.Queues internally for now, but JMS later if you find that you need it. Though be careful here too-- adding unnecessary abstraction early is sometimes a burden that turns out not to be worth it.
I was googling around to search for what makes them different. I have used RabbitMQ and ZeroMQ for some of my projects. Knowing that JMS still exists and people use it I begin to wonder why? What motivates the usage of JMS are there any performance, architectural, or any advantages? I have no knowledge of JMS but if what I understand is true why would somebody bound himself to a java specific technology?
JMS and AMQP aren't really comparable. JMS is an API; AMQP is a protocol. It is possible to write a JMS implementation that uses AMQP. Indeed, people have.
Moreover, it is possible to write JMS implementations that use other protocols - and of course, numerous people have.
The goal of JMS is to put a uniform API over all these different messaging protocols. This makes life easier for programmers, who can learn one API, and then have a reasonable chance of using any message queue they come across.
In addition, the existence of a standard API allows JMS to interact with other standards. For example, in ejb, there is such a thing as a message-driven bean, which is an EJB which receives messages rather than method calls, and uses the JMS API to control the process.
After reading some interesting posts here on SO, and many pages found on google, I would like to ask you for help with decision what JMS/AMQP broker to choose. We are facing simple problem in our company. We need to use reliable message-based system for communication of nodes in cluster. Since we have "our own" solution for this, it's becoming quite clutter for us as we are trying to add more and more functionality into it (plus, it's buggy :)).
I really don't want to raise another question about which broker is better/worse, I would rather like to ask you about your personal experience and observation about reliability/complexity/flexibility of JMS/AMQP brokers. (i.e. I've found some confusing information about ActiveMQ, saying it's not stable yet many people consider it to be best JMS solution out there)
Currently, our system sends approx. 100 mps, so it's not big load, yet we need to be able to scale it in the future as more and more nodes will be added into cluster. Each node should be will be sending and receiving messages. We need to find as reliable solution as possible.
Thank you for your answers.
Generally speaking the more robust brokers are commercial ones. I have used ActiveMQ in production and it had a few problems I was able to work around. It supported up to 20K messages per second. I would use it again.
I'll start with the broker I know most about.
TIBCO EMS
Pros
Very stable
Has a c#, c and java api
Good support
Mature, has lots of nice enhancements, these manifest themselves in little things such as how it distributes messages to consumers on a queue etc.
Cons
Expensive
Not much information out there on the web
My boss helped develop the AMQP spec and he rates RabbitMQ very highly. I have not used it in anger so cannot comment.
Of course the one big advantage of AMQP over a JMS broker is interoperability ie a message sent from one vendors broker can be read by any other AMQP broker implementation
We used IBM Websphere MQ for larger installtions - its commercial only - but a robust, scalable solution. For little to medium we used ActiveMQ and OpenMQ.
This is not so much a question as it is a request for an opinion on these two technologies. A little background on this: I suggested the use of JMS on an enterprise project and the client came back talking about ebXML. I can honestly say I had no idea what this was, never read about it on the wire, and never hear anyone talking about it anywhere. So as a community, what do you guys think about one over the other?
JMS
http://en.wikipedia.org/wiki/Java_Message_Service
ebXML
http://en.wikipedia.org/wiki/Ebxml
I have the privilege of having worked on both the JMS RI at Sun and the ebXML at OASIS. I agree with previous statement that it is apples and oranges comparison....
JMS is a Java API. ebXML is a set of XML specifications and protocols. This is quite different
JMS defines an API for pub/sub messaging requiring a Java Message Service. ebXML is a set of specifications that do many things ranging from technical agreements on how to interact using a common set of capabilities (ebXML CPPA), registry and repository (ebXMl RegRep, and a messaging service (ebXML Messaging). The last spec may be the one that you were comparing JMS with.
[1] has a useful comparison of JMS and ebXML Messaging....
"Although the Java Messaging Service (JMS) offers a standard programming interface to message queuing products, the message formats and wire protocols used by these products are proprietary, requiring sender and recipient to use implementations from the same vendor or to use JMS-to-JMS bridges. One promise of the ebXML Messaging Service is to provide some of the benefits of message queuing products, while offering users a choice of ebMS implementations, provided by different vendors, including open source implementations."
[1] The ebXML Messaging Service, By Pim van der Eijk, March 18, 2003
http://www.xml.com/lpt/a/1175
Seems like apples and oranges to me, but from the Wikipedia article it wasn't entirely clear what implementations had to provide.
I'd have to be convinced to not use an EE standard like JMS if it suits the messaging needs you actually have.
When designing an distributed application in Java there seem to be a few technologies that address the same kind of problem. I have briefly read about Java Remote Method Invocation and Java Message Service, but it is hard to really see the difference. Java RMI seems to be more tightly coupled than JMS because JMS uses asynchronous communication, but otherwise I don't see any big differences.
What is the difference between them?
Is one of them newer than the other one?
Which one is more common/popular in enterprises?
What advantages do they have over each other?
When is one preferred over the other?
Do they differ much in how difficult they are to implement?
I also think that Web Services and CORBA address the same problem.
You already know about method calls. What if the object that you want to invoke the method on is on a different computer? You use RMI to send the call from one computer (client) to the other (server). The client will wait (or "block") until the result comes back from the server. This is called synchronous operation.
JMS is different: it lets one computer send a message to another - like email. The first one doesn't have to wait for a response: it can keep doing whatever work it wants. There may not even be a response. The two computer systems don't necessarily work exactly in step, so this is called asynchronous.
Another way of thinking about the difference: RMI is like making a phone call, and JMS is like sending a text message.
RMI is a little older than JMS, but that's not really relevant. The two concepts are much much older than java.
There's not much difference in the complexity. I think that you should try doing a tutorial on each one. RMI and JMS
If you're starting a project from scratch, and you're not sure which one to use, then probably the synchronous/asynchronous issue is the best decision factor. If you're working on an existing system, it's probably best not to introduce too many new technologies. So if they're already using one, then I'd suggest it's probably best to stick with that one.
You cannot really compare the two, its apples and oranges.
RMI is a form of Remote Procedure Call (RPC). It is a lightweight, Java specific API that expects the caller and receiver to be available at the time of communication.
JMS is a reliable messaging API. JMS providers exist for various messaging systems. Messages can be passed even if one of the parties is not available if the provider implements that. The two I am familiar with are TIBCO and IBM MQ.
RMI doesn't deal with guaranteed delivery or asynchronous responses, JMS may, depending on the provider.
JMS allows loose coupling in the sense of availability.
"Web Services" allows loose coupling in the sense of protocol and data but doesn't specify much in the way of reliable messaging, though some implementations do include this (Windows Communication Foundation) and some don't.
EDITED: Revised per comments. When I wrote this answer in 2010 my experience was actually with only one JMS provider and I didn't actually know there was no default JMS provider.