I am new to Messaging and want to know the difference between ActiveMQ, Mule, ServiceMix and Camel
Anyone knows how each of these product is different?
Thanks in advance !
EDIT: Also would like to know any good place/resource to learn these things.
ActiveMQ is a message broker which implements the JMS API and supports a number of cross language clients and network protocols. It lets you implement queues or topics and write listeners or subscribers to respond to queue events.
Mule and ServiceMix are open source ESB (enterprise service bus). An ESB has capabilities beyond JMS: queuing is key, but so are transformation, routing, logging, security, etc.
Apache Camel is an implementation of the patterns in Enterprise Integration Patterns. It can use JMS and other components to put the ideas from that book into place.
JMS is fundamental to the other technologies, like JDBC is the foundation for Hibernate, iBatis, etc.
JMS is a Java API and a specification and TCK (part of Java EE). ActiveMQ is a particular implementation of it.
Camel can use ActiveMQ (and Camel is bundled inside the ActiveMQ broker so you can easily route to and from JMS to the other components Camel supports).
Camel doesn't use Mule or ServiceMix directly; though ServiceMix uses Camel as its preferred routing engine and EIP implementation. Camel does have a ton of different components though that use various different technologies.
First let's define
JMS is a Java Messaging Service protocol specification.
ESB is Enterprise Service Bus.
JBI is Java Business Integration.
Now we can answer in details:
Apache ActiveMQ is an implementation of the above JMS (Java Messaging Service).
Apache Camel is a message routing engine implementing Enterprise Integration Patterns.
It provides a lot of predefined components.
One of its key component supports JMS (Java Messaging Service).
Apache ServiceMix is an implementation of the above ESB (Enterprise Service Bus)
compatible with the JBI (Java Business Integration) specification.
It also provides many infrastructural features not available in Camel (like services OSGI bundle support).
SM makes heavy use of Camel.
Mule is another implementation of ESB (Enterprise Service Bus), but not related to the Camel/ServiceMix family.
Apache Service Mix :: Its an ESB (Enterprise Service Bus) , a JBI Container and an Integration platform.
Apache Camel: Smart Routing and Mediation Engine which implements EIP (Enterprise Integration Patterns).
Apache ActiveMQ: Its a Message Broker that implements JMS.
Mule is a Enterprise service bus providing end to end integration solution.
ActiveMQ is message broker for queueing messages between subscriber and receiver.
ServiceMix is also a ESB i.e. Enterprise Service Bus
Camel empowers you to define routing and mediation rules in a variety of domain-specific languages.
Mule and SeriviceMix is ESB.
ActiveMQ is Messaging service.
Apache Camel is the implementation of EIP (Enterprise Integration Patterns)
ServiceMix is the product that conforms to the principles of ESB in an SOA environment.
Active MQ is as good as any other implementation of JMS API
Mule is also an ESB
Related
What is difference between Qpid Java 6.0.1 and Qpid JMS 0.9.0 and Qpid Proton?
I am new with JMS and wanted to implement simple JMS application with Apache Qpid.
Can anyone provide me links to understand it.
The three are quite different beasts.
The Qpid Java project is a Messageing Broker for AMQP that includes support for the 0.9, 0.9.1 and 0.10 AMQP draft specification along with support for the current AMQP v1.0 specification. Qpid Java does include a JMS client for the older draft specification of AMQP (0.9, 0.9.1 and 0.10.0) but it does not include an AMQP 1.0 JMS client, that is what Qpid JMS is.
The Qpid JMS project is a stand alone JMS v1.1 client library that speaks AMQP v1.0 and can be used against any AMQP 1.0 compliant broker such as Qpid Java, AcitveMQ, Qpid C++ broker etc. The Qpid JMS client is built on top of Qpid Proton.
The Qpid Proton project is an AMQP 1.0 based project that provides clients and a protocol engine for message based applications to use to communicate using AMQP. The project includes clients in a number of languages including C, C++, Python and Java to name a few. Besides the clients the project provides a core protocol engine that can be used to implement your own AMQP clients or server applications using a variety of programming languages. As mentioned above the Qpid JMS client uses the Proton protocol engine to implement its AMQP 1.0 protocol support and maps JMS behaviours on top of that protocol.
Which of these projects you use depends on what your use case is and what you are needing to implement. Each project has documentation and examples that you can review to get a better understanding of the scope of features each provides.
I need to deploy EJB3 MDB on JBOSS 5.1 and listen to the Topic deployed on IBM MQ. One way is to configure the RemoteJMSProvider inside of $JBOSS_HOME/server/default/deploy/messaging/jms-ds.xml. The second way is to use the MQ Resource adapter and deploy it in JBOSS.
What are the advantages of one approach to another? Are there any other ways?
The RemoteJMSProvider is a generic JMS JCA adapter and so can be used by lots of JMS Providers. Essentially it is a JCA wrapper around a standard MQ JMS client that then talks to the MQ QueueManager. This does mean it is not optimised for any specific JMS Provider, and is also likely to not be tested by the vendor of JMS Provider being used.
The MQ Resource Adapter is built by IBM and so will be tested and fully supported by IBM when used in a Java EE application server. It will also mean it is optimised for MQ.
I was arguing with a coworker about ESBs. I mentioned that Glassfish is an ESB as it manages database transactions, provides SOAP messages, and messaging systems through JMS. He disagreed and said that Oracle Enterprise Service Bus is an ESB whereas Glassfish isn't. I asked him what features make an ESB and he couldn't respond.
What is Glassfish lacking that prevent it from being an ESB?
Glassfish has a bunch of the components of an ESB, but what it is specifically lack in the orchestration component. The orchestration is managing the "wiring" of the various services to each other. GF has all of the capability in terms of managing the endpoints, but not the routing and transformation of messages from endpoint to endpoint.
That said, it USED to have an ESB bundled with it. It used to ship with OpenESB in GF 2.x, but that's been removed from GF 3.x.
Glassfish is an application server. You could certainly run an ESB on top of it, but there are several features missing out-of-the-box from what is typically considered an ESB. You're kind of comparing apples to oranges here -- an app-server provides the structure that supports a web application, whereas the primary goal of an ESB is to help distribute information to/from potentially several applications.
I want to subscribe to the JMS queue with no usage of EJB MDB. The reason is that I want to receive messages only when I want, but not automatically.
Is there some ways to implement it using plain Java (no Spring or smth else)?
I use WebLogic and its internal JMS provider, if it is important.
Thanks.
Yes, you should be able to connect to your JMS Queue of your Application server. JMS is a quite good standard, so after getting your Connection/Queue, the implementation is Vendor agnostic.
Here is a short overview what you have to write to create a consumer/producer with JMS: JMS Sample
This shows each step in detail with WebLogic JMS: Developing a WebLogic JMS Application
I didn't used WebLogic or it's JMS implementation, maybe you have to configure Weblogics JMS: Configuring and Managing WebLogic JMS
For a comprehensive overview of the programming capabilities of your WebLogic JMS Provider, look here: Programming WebLogic JMS
I'd like to use the Java Message Service but it says it's for the Java EE Platform. Is there a way to port it to a regular Java application (which I'm working on in Eclipse)?
JMS is part of the Java EE spec, but you can use it from any Java application. Depending on your needs, you may have to run a standalone broker, but this is just like running a regular daemon (or Windows service).
Yes, you absolutely can use JMS from a J2SE application. In fact, you can access a JMS broker from programs not written in Java at all. The ActiveMQ JMS server includes several transport connectors. The connectors allow clients to interact with ActiveMQ using different communication protocols. Most Java clients use the openwire connector. I've written a PHP client that used the STOMP protocol with great success. It consumed messages sent to a JMS Queue by a Java application running in the Tomcat Servlet Container.
This is a much more complicated question than the answer would indicate. Jms is a spec. Really just a set of interfaces. You can absolutley use those interfaces from a standalone java process. Hell you could write your own jms compliant messaging implementation. Questions you should be asking yourself is what messaging implementation will i be using and does it support jms? Even after answering that there are numerous caveats to take into account when connecting to brokers outside of a container including but not limited to transactionality, load balancing, connection pooling, and high availability. You should be very clear about what your trying to do and what messaging vendor you are working with before you can answer this completely
Many Messaging servers also provides their java api for the communication like MQ, open source Apache ActiveMQ. In that case you don't realy need to worry about JMS. You simply need to understand and use that API.