I understand Java JMS API provides the support for producing and consuming messages asynchronously.
For example, I will implement JMS producer using java and send messages to the JBOSS Message(Destination).
let say the external application say .net applicationin the distributed environment want to consume the messages by connecting to the JBOSS Message(Destination)
Is that possible?
There are several JMS message types:
BytesMessage: can be read by anybody
TextMessage: ditto
StreamMessage: can be read by anybody who can read network-ordered primitive types
ObjectMessage: these are serialized objects and can only be read by Java
MapMessage: these are essentially maps; ditto
JMS itself isn't a message broker, just an API to an existing broker.
If your Java code and the non-Java code can agree on a byte- or text-based message format, you can interchange message between them.
JMS only defines the API an application can use to send and receive messages. It doesn't define a wire format. So it depends on the messaging system you use. JBoss uses HornetQ (since JBoss 6, IIRC), and HornetQ supports other wire formats, namely STOMP and AMQP. It also allows to use REST to send and receive messages.
But, as it is so often the case with interoperability, you'll have to limit yourself for this to actually work. You can't exchange all message bodies (as EJP has elucidated) and probably not all message headers and properties.
Reading a book about it at the moment.
You will need a JMS server that can be accessed through .Net services (either directly or because your JMS can be configured to send the messages to a .Net MOM *).
In any case, it would not be part of JMS but a capability of a particular product. JMS was developed with the intention of being "generic enough" to work in this scenario, but it is up to the specific server implementation (and configuration) to support it (or not).
MOM: Message Oriented Middleware
on a technical level any message over a protocol can be read regardless of message since its all converted to 0's and 1's at some point. However, because JMS are java interfaces you technically wont be using JMS even if you read the messages that way - JMS is the java way to read those messages by using java JMS interfaces and classes that extend those interfaces
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'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.
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?
I want to know what is the JMS protocol? is it text base protocol like http or a binary?
What is the hierarchy of these kind of protocols? ( RMI > JMS or ... )
I will thank you if you introduce me good reference for learning these protocols hierarchies.
RGDS
JMS is an api specification, it doesn't define anything about the underlying protocol.
I would imagine that most JMS server implementations use a binary protocol, EMS which is the one I have had most experience with most certainly does.
Best place to start is the docs at here
AMQP is a messaging standard which does however define the on the wire protocol, and it is binary.
JMS is not a protocol. It is a specification. Many MOM vendors implement this specification and provide API for messaging. JMS implementations are vendor specific. So first understand JMS specs and then select your JMS provider.
The JMS message can be a BytesMessage, than the body of the JMS message is binary data.
Also the JMS message can be a TextMessage, than the body of the JMS message is string data.
JMS is completely dependent on the JMS Provider implementation.
You have to first familiarize yourself with the abstract specification, than seek documentation depending on the JMS Vendor impl you're going to use. Most vendors follow the specification, but also extend it. I would say ActiveMQ and HornetQ are the most popular free license message brokers. Here's a starting tutorial on JMS, but if you have already chosen a specific vendor, it's best to follow their starting docs.
Its either - in fact JMS has two specific message types to cover those cases.
Id start with wiki - http://en.wikipedia.org/wiki/Java_Message_Service
And then take a look at http://docs.oracle.com/javaee/1.3/jms/tutorial/
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.