Message brokering markets were once dominated by heavy weights and required huge investments by enterprises for implementing such solutions. Vendors made huge bucks out of it by selling such solutions and support. Is this still considered a niche market? I personally don’t think so. I am definitely not against vendors offering such solutions, but the point I am making here is whether this market still deserves huge investments when mature open source alternatives are available.
You possibly have two options. Buy an OTS solution and forget about maintenance nightmare, typically argued by the so called “Enterprise Architects” because they assume it’s a safe bet. Such decisions make your enterprise tightly coupled with these kinds of solutions. You may never know sometimes you end up paying huge bucks for feature requests and lobbying for license costs and finally stuck with the custom solution for years. This choice comes at a huge price, but at some convenience as one need not blame you for lack of a feature or offering a buggy solution. Does this convenience worth anymore?
Historically, enterprises chose such solutions mainly because of the support and maintenance that comes bundled with the solution and they always awarded such contracts to market leaders. Finally, when the vendor decides to release newer versions of the product, customers had to upgrade and sometimes forcefully migrated to a newer version, just because earlier version does not scale or does not support a feature or possibly discontinued.
On the contrary, some enterprises (mostly small to mid-size) consider the option of implementing such messaging solution using open source alternatives and people who make this choice need to be really smart because of the liability that comes with their decision. In most situations, such decisions are made by experts who are aware of the complexity involved in such undertaking. For most part it will be straightforward to adopt such a solution and sometimes it could be painful when there is lack of technical expertise within the enterprise. But, it will definitely be a rewarding experience when working with smart people in such integrations. The open source community offers their best support in resolving any issues. This option will surely benefit enterprises in terms of licensing and support costs. But, the key assumption here is that you bet on your expertise on such engagements.
Open source solutions are increasingly becoming a compelling choice for enterprises because of their mature feature set and wide adoption backed by strong user community. ActiveMQ is one such project in ASF where you see tons of features available to its users. I had experience working on similar commercial products, but ActiveMQ is absolutely mind blowing. Simplicity wins the heart of enterprise developers. Some commercial offerings take days to install and configure which requires special hardware (high-end servers) and sometimes on-site training from vendor. With projects like ActiveMQ, it is becoming more and more productive for teams to develop, test and roll out integration solutions in a shorter period of time. It just takes minutes to install and configure ActiveMQ in your desktop.
I recently downloaded ActiveMQ and played around with it. Let us analyze their startup messages and dissect some of them and see what they offer. This is just a tip of an iceberg.
<code> (1) D:\\apache-activemq-5.1.0\\bin>activemq.bat (2) ACTIVEMQ_HOME: D:\\apache-activemq-5.1.0\\bin\\.. (3) ACTIVEMQ_BASE: D:\\apache-activemq-5.1.0\\bin\\.. (4) Loading message broker from: xbean:activemq.xml (5) INFO BrokerService - Using Persistence Adapter: AMQPersistenceAdapter(D:\\apache-activemq-5.1.0\\bin\\..\\data) (6) INFO BrokerService - ActiveMQ 5.1.0 JMS Message Broker (localhost) is starting (7) INFO BrokerService - For help or more information please see:http://activemq.apache.org/ <u> (8) INFO AMQPersistenceAdapter - AMQStore starting using directory: D:\\apache-activemq-5.1.0\\bin\\..\\data</u> (9) INFO KahaStore - Kaha Store using data directory D:\\apache-activemq-5.1.0\\bin\\..\\data\\kr-store\\state (10) INFO AMQPersistenceAdapter - Active data files:  <u>(11) INFO KahaStore - Kaha Store using data directory D:\\apache-activemq-5.1.0\\bin\\..\\data\\kr-store\\data</u> <u>(12) INFO TransportServerThreadSupport - Listening for connections at: tcp://nandi:61616</u> (13) INFO TransportConnector - Connector openwire Started <u>(14) INFO TransportServerThreadSupport - Listening for connections at: ssl://nandi:61617</u> (15) INFO TransportConnector - Connector ssl Started <u>(16) INFO TransportServerThreadSupport - Listening for connections at: stomp://nandi:61613</u> (17) INFO TransportConnector - Connector stomp Started <u>(18) INFO TransportServerThreadSupport - Listening for connections at: xmpp://nandi:61222</u> (19) INFO TransportConnector - Connector xmpp Started (20) INFO NetworkConnector - Network Connector default-nc Started (21) INFO BrokerService - ActiveMQ JMS Message Broker (localhost, ID:nandi-64041-1211065443740-0:0) started (22) INFO log - Logging to org.slf4j.impl.JCLLoggerAdapter(org.mortbay.log) via org.mortbay.log.Slf4jLog (23) INFO log - jetty-6.1.9 (24) INFO WebConsoleStarter - ActiveMQ WebConsole initialized. (25) INFO /admin - Initializing Spring FrameworkServlet 'dispatcher' <u>(26) INFO log - ActiveMQ Console at http://0.0.0.0:8161/admin</u> (27) INFO log - ActiveMQ Web Demos at http://0.0.0.0:8161/demo <u>(28) INFO log - RESTful file access application at http://0.0.0.0:8161/fileserver</u> (29) INFO log - Started SelectChannelConnector@0.0.0.0:8161 <u>(30) INFO FailoverTransport - Successfully connected to tcp://localhost:61616</u> </code>
The following features are enabled by default when an ActiveMQ broker is started.
Line 8 – AMQStore is the default storage for AcitveMQ 5 and above.
Line 11 – KahaStore is an optimal performance storage solution used for message persistance.
Line 12 – OpenWire is a cross language Wire Protocol which allows native access to ActiveMQ from a number of different languages and platforms.
Line 14 – SSL transport allows clients to connect to a remote ActiveMQ broker using SSL over a TCP socket.
Line 16 – Stomp is used by non-Java clients talk to ActiveMQ server and other message brokers.
Line 18 – XMPP is used to connect to the broker & send and receive messages (Jabber).
Line 26 – ActiveMQ Web Console for managing the broker services such as queues, topics and subscriptions.
Line 28 – REST-ful API to messaging (JMS). Browsing of queues implemented using pluggable views such as ATOM and RSS feeds.
Line 30 – Failover transport used for reconnection.
There are tons of other features which is beyond the scope of this discussion. Some of the notable features include embedded message broker which comes handy in unit testing. You can refer to its complete feature set here. There are sub-projects within ActiveMQ such as NMS (for .NET) and CMS (for C++) which provides unified access to ActiveMQ from other programming language environments. Camel is another sub-project which implements enterprise integration patterns. Its a topic of interest for another blog entry.
This is more than compelling to adopt this solution. Enterprises sometimes face real complexity in terms of cost of ownership issues when trying to adopt such open source solutions. But, this could be overcome by choosing support offerings from companies like IONA, Covalent (now part of SpringSource) and OpenLogic. This may still work out to be cost effective when compared to OTS solutions. The market should favor such healthy adoption.
Possibly Related Posts:
- Local Variable Type Inference in Java 10
- Must have Time and Size Log4J appender for your application
- Private interface methods in Java 9
- Java 8 gearing up for release, why Java 8 will be a top contender for Java.next languages in 2014?
- Configuring chunk size in Apache HttpClient 4.3.x