The ActiveMQ project has been around since 2005 – and has been a top level project at the Apache Software Foundation for a good part of that. The aims of the ActiveMQ project has been to provide a world class enterprise messaging solution, with brokers being able to provide connectivity from smart, IP enabled devices all the way through to high availability at the enterprise back end. ActiveMQ provides cross language clients – including
Java/C/C++/C#/Perl/PHP/Python etc – for a full list see here. Open connectivity has always been a goal, which why as well as OpenWire and STOMP, ActiveMQ will be supporting AMQP 1.0 when its finalised.
FuseSource ships is own distributions of Apache ActiveMQ (called FuseMQ), Camel, ServiceMix (FuseESB) and CXF. The code base is exactly the same as Apache, however we need to be able to ship mission critical fixes and enhancements within hours for production systems. We also ensure that these distinct projects work well together on different platforms, and put the releases through more extensive system tests. I mention this because some of the case studies that I’ll refer to mention FuseMQ – which is is the same code as ActiveMQ – and can be used as a drop-in replacement – its just better tested.
The Java/C++/C# clients support seamless failover if connectivity is lost to a broker – and brokers can be configured in highly available clusters. In addition, ActiveMQ supports connectivity between brokers over wide-area networks, using store and forward network topologies. This means that ActiveMQ is not only used to provide connectivity between remote data centres, but is also being used to provide connectivity between unreliable communications (dial-up, satellites). This is particularly important for large retailers, to provide real time reliable connectivity for order placement, stick tracking and monitoring. There’s a case study on SpecSaver’s here – but I know some of the largest retailers in the US (as they are FuseSource customers) are also heavily using ActiveMQ for very similar deployments.
Enterprise Messaging has traditionally been used to enable large transactional systems for enterprise deployment. Can ActiveMQ do that ? Yes it can – FuseMQ is deployed as part of FuseESB – see this NY Times article. Messaging is also used for high volume real time updates – can ActiveMQ do that – yep (CERN, RiotGames or JPL). If you want an example of really mission critical deployment of ActiveMQ – look at the FAA case study on how its been utilised in the Next Generation Transport System.
In order for ActiveMQ to be utilised in so many varied deployments, it has to be very flexible, so that it can configured to run in the best way possible for a particular deployment. This asset can also be ActiveMQ’s achilles heel. As a developer, I often expect things to just work, and figure out afterwards why they don’t, however ActiveMQ is one of those highly configurable tools that does require some upfront knowledge, or background reading (or at least reading the F.A.Q) before you can get the best out of it.
As FuseSource CTO, I see ActiveMQ being a unique foundation stone to the thousands of successful enterprise integration projects we support our many hundreds of enterprise customers on. ActiveMQ is not only ready for prime time, but with the innovation, flexibility and world beating performance being developed in ActiveMQ Apollo, it will continue to dominate the enterprise messaging space for many years to come.
Reference: ActiveMQ IS Ready For Prime Time from our JCG partner Rob Davies at the Rob Davies on Open Source Integration blog.
