I have few basic douts.
I have developed a JMS application for P-P and the messages are geeting stored in Jboss 7.1 JMS engine. My questions are below.
1.For any JMS application do we need to have any messaging engine like IBM MQ,HornetQ,Active MQ etc
If Yes then we need to configure the MQ to atlk to Appserver Messaging engine.
3.If No, Then we need to have to create a message consumer
JMS is a specification of a messaging interface - and a state model for how messages are handled in transactions.
jms.jar contains pretty much all interfaces - no implementations. Therefore whilst you can write an application against jms.jar you can't actually run it.
You'll need to pick some type of messaging provider. That's appropriate to your requirements.
That's not a discussion for here however keep in mind that they each have possible extensions and functional behavior outside of the specification so if you want to be portable between providers pay close attention to only use specification defined functionality.
Within a JavaEE Application Server there will be a JMS implementation that provides messaging features. Therefore an app here in JBOSS will be a MOM (messaging oridentated middleware) application. If you want the message to be accessed by an application not running in a JavaEE server then that is possible with some providers. There's often a JavaEE client container. Or the messaging engine will have a JavaSE based client that can be used. (WAS thin client client for example).
Remember that with JavaEE servers you are not restricted to a the choice of messaging provider - you can use the JCA interface to directly plug in a external messagin implementation. This might present an easier route if a lot of messaging will be outside the JavaEE server.
EDIT - added JavaEE notes
Related
We are designing a solution that will consume messages from IBM MQ using JMS. The plan is to use WAS Liberty, so JMS is the technology of choice. We will create Message-Drive beans that will listen for messages in MQ queues.
We are considering both WAS Liberty and OpenLiberty as well.
The trick here is that we must implement it with fail-over, so that if one of our server fail, the other will keep consuming messages from MQ automatically. Like in a ative/passive mechanism.
I'm aware that the MQ adapter needs to be installed as it is not provided out-of-the-box.
I have the following questions:
Does WAS Liberty messaging implementation supports fail-over? Meaning that if the ative message consumer node fails, the stand-by node will automatically migrate and start consuming messages from MQ? What about OpenLiberty?
How can I configure the message system to work that way? Can you point out to the documentation?
Or is this feature only provided by WebSphere?
There is no such functionality in WebSphere Liberty or Open Liberty yet. You can create RFE here https://www.ibm.com/developerworks/rfe/?PROD_ID=544 .
There are ways to do it manually, check these links:
JMS Activation spec on Liberty: “WAS_EndpointInitialState” full profile equivalent property?
Controlling the state of endpoints at runtime
Solution that you could do:
create a script/application that will monitor your servers and call that API to enable/disable endpoint in specific server
or use Dynamic cluster/ auto scaling feature of Liberty and divide you app to two clusters - one with MDBs, one without. And then define policy that MDBs cluster has 1 instance always available. So once the server dies it is automatically restarted somewhere in the cluster
or use Kubernetes/ICP platform in the same way - so deploying 2 versions of app, and defining different replicasets parameters.
Newbee to Spring world. I have some knowledge on ActiveMQ. Recently used in one of my projects. While reading about Spring Events raised a doubt.
Spring Events: Publisher -> Listener. We do publish events and we would have created some listeners for that.
ActiveMQ: Publisher -> Listener. We do publish events and we would have created some listeners for that.
So anyone helps me to understand the use cases or difference between these two APIs.
As far as I can tell, Spring Events are an application level events mechanism, so that different parts inside our application can communicate/coordinate. The scope and functionality appear to be quite narrow and small respectively. You can publish events and deal with those events either synchronously (default behaviour) or asynchronously (using #EnableAsync and #Async). There is no broker. This functionality may be a perfect fit for your application if this is all it needs.
On the other hand, ActiveMQ is a full-featured message broker. Generally speaking, it runs as an independent server process (although it can be embedded in your application). It supports industry-standard protocols like AMQP, MQTT, & STOMP which have client implementations on numerous platforms and in various languages. For example, you could send STOMP messages via Websockets from a Javascript client and process those messages with an AMQP client written in .NET on Windows. It provides both a JMS & JNDI client implementation. It supports both publish-subscribe and point-to-point semantics. You can use it as an integration platform and scale it up to multi-node clusters with high-availability for the message data and thousands of remote clients using various protocols or you can embed it into your application and just use it for local events.
I am new to JMS.
I am little aware of RabbitMq and now trying to find the difference in rabbitMQ with JMS. How it is used and why it should be used?
Thanks in advance.
JMS is a Java API (part of JEE).
JMS Vendors use a proprietary protocol to talk to the broker; they are not wire-compatible.
You can generally talk to any JMS broker by just changing vendor-specific configuration (connection factory etc).
Vendors provide a JMS client library to talk to their brokers.
AMQP is a wire protocol, not an API.
Vendors provide a Java client API.
You can use Spring AMQP, which sits on top of RabbitMQ's amqp-client library and its API.
You can use Spring JMS, which talks to any JMS broker (including RabbitMQ with the plugin) using the JMS API.
If you need to be compatible with any JMS vendor, use spring-jms; if you only intend to use RabbitMQ, I would recommend using Spring AMQP.
Or, use Spring Integration on top of either one, and you can switch between AMQP and JMS by just changing configuration.
I'm not sure what you mean by RabbitMQ for JMS. But, i'll list out the differences below.
RabbitMQ
Works on AMQP protocol and it is not a J2EE specification
Applications written in several languages can produce and consume messages(Python, Ruby, Java, C#, Perl etc.,)
Does not work with J2EE specs, so you cannot use XA Transactions, bean pools, connection factory pools which are all provided by J2EE container by default
Community is not so mature, but, if your organization needs to communicate with a lot of different types and languages of applications you can sacrifice all the beautiful features that are provided by J2EE/JMS spec.
JMS
It is J2EE specification, any application server that provides JMS support should follow the guidelines mentioned in the spec.
Only the Java/J2EE applications can produce and consume, it can be made to work for other languages but with use of adapters
J2EE container provides XA Transaction, Bean pooling, Connection pooling etc., out of the box with little configuration at your end.
If your organization only uses Java based applications, you need not look in RabbitMQ way as you have JMS support which works well.
I am not expert in JMS and recently came across a situation in my project where they wanted to use JMS to communicate between applications. Is it possible to make use of JMS without an underlying MQ software like Websphere MQ / TIBCO EMS to communicate asynchronously. My thinking is that just like we use JDBC API to speak to a physical Database product (like Oracle/DB2 DB) underneath, we would use JMS to speak to a physical queue. But my team says just JMS and no queue. Can anyone help me understand? We use Websphere 6.0 server and use spring framework.
Thanks in advance.
You are correct: JMS is solely an interface, it contains no implementation. The comparison with JDBC is quite fitting.
When using JMS you always need a JMS provider. A provider is the JMS implementation, which interfaces a message oriented middleware.
Most application servers have built in JMS providers, so maybe your team meant using JMS without an external provider.
Is it possible to make use of JMS without an underlying MQ software like Websphere MQ / TIBCO EMS to communicate asynchronously
This makes no sense. Few points to note -
JMS is just specs. By specs you can imagine it as set of APIs/interfaces/ method signatures and governing rules.
There are various organization/companies that provide implementation of these APIs.Apache's ActiveMQ,IBM's Websphere MQ or TIBCO EMS are some of the examples.
Now when you say I want to use JMS then you need a JMS compatible server i.e server which understands the rules laid down by specs. This is generally know as MQ server and is provided by the provider.
My thinking is that just like we use JDBC API to speak to a physical Database product (like Oracle/DB2 DB) underneath, we would use JMS to speak to a physical queue. But my team says just JMS and no queue
Two things to note here. When you say you want to use databases and JDBC APIs to communicate JMS comes no where in the picture. Please understand why JMS is used. In short it is used to transfer messages between two decoupled system. What storage type JMS server uses(and if it is configurable) will depend on the provider. Generally all have DB storage type and can be configured to use your DB.
Next JMS has two types of communications - PTP(peer to peer) which uses queues and PUBSUB(publish subscribe) which uses Topics. When you say you are using JMS everything boils down to either of these two and some of it's variants.Now when you say JMS without a queue perhaps your team meant using PUBSUB. But again it is not something you decide randomly and use it in your application. This decision is takes as per what your requirement is as both of them behave differently.
First you will need queues/topics to use JMS.
Second (your team probably means not using WebSphere MQ because my team was saying the same thing)
This diagram in IBM's Red Book will fully answer your question (it is the same as WS6):
http://www.redbooks.ibm.com/redbooks/pdfs/sg247770.pdf
page 4.
Probably what you will be using is the WebSphere Default Messaging Provider.
I understand JMS spec allows me to write MDBs. Then I can deploy them on an appserver like websphere or jboss (and they have inbuilt implementation of JMS provider which is Java EE compliant). The question is when to use a full fledged product like IBM WebSphere MQ or ACtiveMQ instead of using App server's inbuilt JMS provider.
This appears to be a good reference to what you are asking, specific to IBM products but can be generalized to using an application server integrated messaging system vs a standalone messaging system - http://www.ibm.com/developerworks/websphere/library/techarticles/1109_wallis/1109_wallis.html
A built in JMS provider, such as WebSphere SI Bus, possibly others, are built for JMS messaging.
WebSphere MQ (MQSeries), ActiveMQ etc. have clients for multiple languages and are built for applications other than Application Server hosted applications to connect to it (C++, Java SE, Python, etc).
Say you want a local messaging server on the same physical server (or network?) as a non JavaEE application, you don't want to install a Java EE App Server, but want a stand alone messaging server instead (WebSphere MQ, Active MQ).
That said, ActiveMQ, for instance, is the messaging system inside Apache Geronimo. So there is overlapping here.
Then there is a whole discussion about management, clustering and security. Java EE messaging systems are pretty much optimized to follow the cluster layout of Java EE. In other deployment scenarios, the clustering might be optimal in other ways, such as cluster for different security zones. Also security models and management tools might be different in stand alone messagaing servers.