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.
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.
Hi I have designed a desktop application in Java SE with netbeans and Mysql.I do not have any server coding for now since all my operations were of pull type. I need a push notification functionality. Previously I had a button that refreshed the notification but now I want the notifications to be updated automatically.
What would be best way to add this functionality without changing much of my present code.
Any help appreciated.
Thanks a lot
You really will have to change a lot about your architecture to have your application go the other direction. However, I think the best approach is to use a light weight JMS provider. That way your client can code to the JMS API which is really pretty straight forward, and your server can use JMS and its really pretty easy. It's not nearly as much effort as plumbing other options in.
The harder part is setting up the container in your application. It's not tremendously hard, but JMS has lots of options for configuration. Figuring out the point to point vs topic, durable vs non-durable and what's right for your application is a lot of research you have to do if you haven't done JMS before.
But, what this affords you is a very expressive control over messaging in your application. You can under the covers without modifying your code swap between polling or direct connections, message 1:1 or 1:many. If you need to send a message to one client vs. sending a message to all clients. You can segment messages between clients and create groups. Your messages can be durable or non-durable (survive client shutdown or server shutdown). The possibilities are endless, but you have to make a lot of architectural decisions. You also don't have to handle network topology and connectivity issues as much than if you used UDP multicast or TCP connections in reverse.
ActiveMQ and RabbitMQ can be easily embedded within a server using spring in a matter of 20 minutes. They also provide hooks for other platforms. It might sound overkill, but I've tried to do without JMS in the past when I should've used it and regretted not using it.
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.
I'd like to throw together a small game and put it online. It would be multiplayer (ideally it would be MMO, but it's a side project, so I'll settle for MO hehe), the content is rather unimportant. I'm planning on writing the game (server and client) in Java.
I'm considering options I have for getting information around reliably. Will JMS be sufficient for this? Will I need more (if so, what)? Are there better alternatives?
I've made a few games in the past, but nothing multiplayer. I work with an app that uses JMS, and there's plenty of tutorials, so that's why I figured it would work... but I'm really open to anything.
Thanks!
Edit: It appears I have a lot to learn about JMS. Perhaps my question should be rephrased to be: "What implementation of JMS will best serve my purposes for an MMO?"
Criteria thus far:
Free
Low overhead
Easy to configure
JMS would assume that your players are all on the same local network. I don't think it would work as well if your game is played over the Internet.
Don't forget that JMS is an API and doesn't specify an implementation. I suspect that for a game you're going to require prompt delivery, and choosing an implementation may depend on attributes including this.
You may want to check out JGroups. As well as implementing JMS, it is enormously configurable and can be used to implement many different messaging patterns. You can choose to enforce reliability, ordering etc. and tune for different applications / clients etc.
JMS is good if you need guaranteed transacted message delivery. Typically those kinds of constraints aren't there in a game (though it depends on the kind of game). If you want low latency communication, JMS is probably not the solution. Beyond that, without providing more information about the requirements of the game, its really impossible to say if JMS would be good for you or not.
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.