I've learned a respectable amount about networking protocols in Grad School and in professional experience and sent HTTP requests programmatically using AJAX and such.
The project on which I work professionally uses JMS to communicate and I'm curious about how it works.
When using REST (for instance) one makes an HTTP request with parameters in either the URI or the message header in order to invoke a service and further describe its needs.
A mentor of mine at work and I were discussing how JMS works and I'm struggling to understand at an application level how messages are actually sent. As far as I understand JMS in general (I realize there are many implementations of JMS) it is a specification for how to format data being sent.
Is the message itself still sent via HTTP(S)? Could it be SMTP?
Without going excruciatingly deep I would like to understand how one would, at a code level, send a JMS message from one service to another?
Am I even thinking about this correctly?
Can it be done any number of different ways?
Is there a convention that's used in the industry?
If someone could shed some light on JMS for me I would appreciate it.
Thanks!
JMS is not a protocol, it's an API specification. It's not something like TCP or HTTP protocol. Simply put the JMS specification defines signature of messaging APIs. How the APIs are internally implemented and what protocols they use to communicate with the messaging provider is vendor specific.
The vendor specific JMS implementations know how to communicate with their own messaging provider, but not with any other vendors messaging providers. For example IBM's MQ JMS implementation uses it's own protocol to communicate with IBM MQ Queue Manager, similarly Oracle JMS, Active MQ implementations with their own messaging provider.
Hope this helped.
Related
I want to subscribe to a Java Messaging Service (JMS) publish-subscribe service using Apache Qpid. However rather than using Java, I want to use C++. My customer told me this was possible (and even said trivial). Are they correct? Can anyone point me to an example? Everywhere I've looked says that to use JMS I have to use Java. The point here is that the service is a third party service (so I can't change it to use AMQP or any other protocol other than JMS).
This depends quite a bit on what JMS Broker you are using. If the broker supports the AMQP 1.0 protocol as well as whatever native protocol it implements for its JMS client then you might be in luck.
The main thing you need besides support for AMQP 1.0 then is good cross protocol communication support such that a message send from the JMS client can get turned into something meaningful for the subscribed AMQP client or the other way round the broker needs to map incoming AMQP messages into meaningful JMS representations so that the two interoperate successfully.
A Broker like ActiveMQ does support this sort of thing along with support for other protocols as well. You need to have the AMQP support turned on in the broker and then you can use the C++ client from the Qpid project to send messages and receive messages with relative ease.
I'm trying to implement bi-directional communication between java-based client and server and the main protocol is JMS. But due to administrative intranet restrictions where client reside it is not possible to have inbound connection. The main idea is to wrap JMS in something HTTP-like. I chose Websockets. The only solution I found is OpenMQ. It supports this. Are there any better solution?
Thanks.
JMS is a way different way of communication compared to websockets. Briefly :
Websockets are an implementation of sockets for the Web. A socket is a connection that is made between 2 peers. The connection is on hold, while the peers exchange messages. The connection is maintained during the whole communication and it is closed after the communication has ended.
JMS is a Java standard/API for sending messages between 2 or more clients. However, it is differently structured. In JMS, there is an entity called message broker, where messages are sent, stored and then retrieved by the clients. So, this approach can be a distributed environment.
So, JMS is a different approach to Websockets, since JMS is "stateless" and optionally asynchronous, while websockets are stateful and synchronous.
Thus, I think you should not make a choice between those 2, considering only the firewall limitation, but you should be more focused on the context of the 2 approaches, deciding which one is more suitable for your case.
If you believe that JMS is a better solution, then you should alter the firewall rules, so that the port used for JMS (by default 1099) is allowed with specific security limitations.
Otherwise, you can use websockets, accepting the performance limitation of synchronous communication.
There is also the approach of integrating websockets with JMS, that is captured by openMQ and other frameworks. However, I do not know what the implications in performance will be compared to simple JMS, and I think that this solution should be chosen, only if we talk about a web application.
Additional Comment
There is also the capability of using HTTP tuneling over JMS. Thus, you will not have to use websockets. You will still use JMS, but there will be a servlet that will be receiving HTTP requests and redirecting them to the JMS service. This has also been implemented in openMQ, as you can see in the tutorial. In this way, you ovveride the firewall restriction, without adding the complexity of websockets.
I am trying to understand the basics of Message Queues. I see that there are many implementations available as libraries for MQs (ActiveMQ, RabbitMQ, ZeroMQ etc). Also J2EE enabled servers provide such support I think.
What I fail to understand about the topic, is how are these kind of constructs used by real software. I mean what kind of messages are usually being exchanged? Strings? Binary data?
If I understand correctly one can configure the transport protocol, but what is usually the application data format?
Is it a new way of communication, like e.g. SOAP WS or REST WS or RPC etc where each has a different application msg format?
Message queues usually using for application integration. In enterprise it is usually used to implement ESB, but nowadays there are smaller application systems that utilize similar patterns.
Concerning data being transmitted - usually it is XML messages, but actually depends on applications and MQ software - some of them are able to handle binary messages, some are not.
For example imagine you have two applications which require data interchange. If you integrate them using some kind of messaging software such as ActiveMQ, for example, then it will give you some benefits like routing, fault-tolerance, balancing, etc, out-of-the-box.
You may integrate your applications using MQ directly, but ESBs usually
give you ability to use web services: app just calls ws of ESB and knows nothing about underlying architecture.
Also MQs and ESBs gives you a level of abstraction: you may switch your apps in a system absolutely transparent, as long as data exchange interface is preserved.
MQs are mainly used for interprocess communication, or for inter-thread communication within the same process. They provide an asynchronous communications protocol, meaning that the sender and receiver of the message do not need to interact with the message queue at the same time. Messages placed onto the queue are stored until the recipient retrieves them.
wikipedia can be good intro to topic. http://en.wikipedia.org/wiki/Message_queue#Standards_and_protocols
Also, to understand diff between webservice and mq, read this thread: Message Queue vs. Web Services?
Basically I need a bidirectional client-server communication (Java) where the client calls methods on the server, but also needs to get "callbacks" if certain events in the server occur.
The methods theirselves have quite complex input and output parameters and lateron it would be nice to include authentication to the system.
Which approach would fit my requirements?
I already build a prototype with RMI, but I read that there exists a number of problems especially for "callbacks" when the c/s are in different networks.
Additionally I would like to avoid JAX related technology, becuase of my complex data structures in the parameters.
Have you thought about using JMS. Within this architecture, server and client will register to a queue or topic and are able to send messages to each other. This enables sych and async application behaviour.
Please have a deeper look into JMS here:
http://java.sun.com/developer/technicalArticles/Ecommerce/jms/index.html
And a really nice implementation is ActiveMQ:
http://activemq.apache.org/
I've had lots of luck with using CometD for callbacks for webapps.
I will like to know:
I have a scenario. If a user adds a product to the system (I'm developing), there's a listener that sends a notification to the user's client base notifying of a new product added by the user.
I've read this thread and (seeing I've never used JMS nor ThreadPool before) I was wondering whether I should use JMS or ThreadPooling.
I am using Tomcat 5.5 and higher and JBoss 5 and higher (depending on company last resort) to deploy my web application.
If I use JMS, do I use Apache ActiveMQ or JBoss Messaging? Are they both compatible to run on both platforms (Tomcat and JBoss)?
Thanks in advance.
For communicating between applications, JMS is a very good solution, especially for events and notifications. JMS allows for such notifications to be sent and received using what is known as asynchronous messaging whereby the sender and receiver have no knowledge of one another and no requirement to be available at the same time.
ActiveMQ is a very widely used message broker that provides client APIs for Java, C/C++, C#, Perl, PHP, Python, Ruby and more. This allows the use of JMS with applications written in Java and other languages.
I have implemented JMS messaging many, many times for a large variety of business situations to handle events and notifications. The vast majority of these times, I have recommended and/or used Spring JMS no matter what message broker is being used. Spring JMS is incredibly easy to use, extremely robust and highly scalable. Spring JMS removes the complexity of creating your own message producers and message consumers, which can save you a tremendous amount of time.
To see how easy it is to send messages using Spring JMS, check out a blog post I wrote recently titled Using the Spring JmsTemplate to Send JMS Messages. I'm also working on a blog post about receiving messages using Spring JMS.
If you have any further questions, let me know.
Bruce
I had a similar requirement once, and we used JMS. Then main problem was how to deal with errors because SMTP is indeed not transactional:
is it ok if some email are lost?
is it ok if some email are sent twice?
We decided it was better to send the message twice, and here is more or less the design we had:
We relied on container managed transaction and if for some reason the email can not be sent, we decided to rollback the JMS transaction; the message would be redelivered later by JMS and an new attempt to send the message was done.
If the JMS message delivery transaction failed after the email was sent (e.g. because of a problem with JMS), the transaction would be rolled back automatically and the message was redelivered later. In this case, the email was sent twice because STMP is not transactional.
Even if the email can be sent (from point of view of code), the SMTP server can still have problem later. In this case, the JMS have been delivered and consumed, so we had no way to know which email had been processed and how to re-send them manually.
But we were already using JMS. I would not introduce JMS just for that given that the main argument is that JMS is transactional, but SMTP isn't anyway.
I would go for something lighter -- possibly with a ThreadPool -- and store the state in a database to know which email need to be sent or has been sent. If there are some problem, you can look at the database and take the ad-hoc decisions.
I know that this reply is very late to this dicsussion, but I hope it will still be valuable for folks seeking info on integrating ActiveMQ and Tomcat.
I've had many people ask me for help with issues they have had integrating ActiveMQ and Tomcat so I decided to write some articles about it. Not only is this topic covered in ActiveMQ in Action (see chapter 8), but I also published a series of articles on it titled ActiveMQ and Tomcat: Perfect Partners. Hopefully people will find this helpful.
I would go for a persistent JMS (I have used only WLS JMS and Websphere MQ so can't compare AQ vs JBoss, whichever offers a better guarantee for delivery). Also, I would seriously consider making the email engine a completely separate application, depending on how much you expect the traffic to grow.