Sunday, September 09, 2012

FuseSource finally really part of Red Hat

When Red Hat announced their intention to acquire FuseSource from Progress back in June 2012, nobody knew that it would take quite so long to actually complete - but it was finally completed last Friday 7th September.

FuseSource was a great company, with great people and technology - and we achieved some tremendous growth numbers in terns of new customers and revenues, which continued right up to the close of the deal with Red Hat. I'm very proud of what we manage to achieve, but I know we've found the right home in Red Hat to continue to grow the open source projects we have worked on for the past 7 years!

Wednesday, June 27, 2012

FuseSource - we are now part of Red Hat!

Firstly, it is really fantastic that Red Hat have announced they are acquiring FuseSource!

When Progress announced they were divesting its non core products and divisions back in February, FuseSource, being an leading open source integration provider, fell into the category of not been core to the Progress 4GL product strategy. FuseSource was already an independent entity, so whilst Progress prepared to go back to the future, FuseSource was already motoring in a separate direction. 

We've been talking to Red Hat for a while, and it is very apparent that combining our technologies would enable FuseSource to deliver a complete integration solution for our customers. There are many complimentary technologies (JBoss Enterprise BRMS) but also many overlaps. However, it is our aim to produce consolidated integration solutions that will dominate the integration space. FuseSource has over 200 customers, many large enterprises that are household names. We wouldn't be joining Red Hat if we didn't feel this was going to be the very best outcome for them. Secondly its important that the whole team feel comfortable with the acquisition. Red Hat are an open source company, its in their DNA. The JBoss Enterprise Middleware Group are a highly motivated like minded team. FuseSource will be a fantastic fit. I know we will work hard to get a consolidated roadmap over the next few months - I can't wait for us to start changing the way everybody does integration, its going to be a lot of hard work and a lot fun - but our users and customers are going to be the true winners from this acquisition!

Monday, May 07, 2012

Apache ActiveMQ 5.6 is released

Apache ActiveMQ is the most widely used open source messaging solution, with many organizations  using it for the reliable integration of applications across there enterprise infrastructure.

Today, Apache ActiveMQ 5.6 has been released - its been more than a year since the last point release. This release has over 370 issues resolved, with 130 improvements including:

  • LevelDB message store. LevelDB is a fast key-value library written by google, but the message store implementation that combines LevelDB with persistent message logs can be found in fuse-extras. This message store implementation can be five times faster than the default message store implementation - KahaDB.
  • MQTT support - MQTT is an extremely light weight messaging transport designed for machine to machine devices - I described this in more detail in an earlier post.
  • Stomp 1.1 support  - which adds heartbeats, NACK frames and support for virtual hosting.  
  • Configuration checks - providing warnings about incorrectly configured brokers
  • Prevention of denial of services attacks                

Friday, April 13, 2012

What to look out for at CamelOne

The open source integration event -  CamelOne, which is being hosted by FuseSource,  is only a month away - and the agenda is coming together to provide so really interesting talks. If you haven't registered yet, there's still time - here's some reasons why you should think about attending:

Firstly, its a great opportunity to meet a lot of the developers who work on Apache Camel, ActiveMQ, ServiceMix and CXF. Most of the Apache committers from FuseSource will be in attendance, and some of them will be talking. However, most of the real talking, just like all conferences, will be the side conversations that happen in the corridors in breaks and the social events that happen after the conference days - usually in a pub somewhere.

However, there are going to be some great sessions - and I particularly like listening to the real world stories of the people who use Apache open source in production - like Christian Muller, Atos Worldline, and Christopher Hazlett from the Gilt Groupe.  There's also going to be a great session on tracking real-time weather using big data and camel by David Reiser et. al. - i've seen their demo - its awesome :).

My favorite though will probably be Felix Nikolaus Ehm, who will be talking about using ActiveMQ and  Camel to control the accelerator complex at CERN. I was lucky enough to get a tour of CERN complex a few weeks ago - its literally the coolest place in the universe.

There's also going to be some great subject matter talks and discussions - the full agenda, as it stands is here.

Wednesday, April 11, 2012

MQTT support added to upcoming Apache ActiveMQ 5.6 release

The MQTT protocol is an extremely light weight publish/subscribe messaging transport - targeted at  machine to machine (mobile, industrial control, asset tracking etc) devices that came out of IBM in 1999. Its incorporated into Websphere MQ via the WebSphere MQ Telemetry product.

A key driver for MQTT is the explosion in connected devices -  its predicted to be in the range of 50 billion by the year 2020. ActiveMQ already provides connectivity for asset tracking, smart devices and vehicle tracking via its ability to be deployed as a small footprint broker and utilizing store and forward for connectivity across unreliable networks. But it makes sense to extend the protocols ActiveMQ already supports (like OpenWire and STOMP) to support MQTT too (ActiveMQ Apollo already supports MQTT - and its the release where AMQP is being developed).

There's also an excellent open source broker called Mosquitto, that implements MQTT, but ActiveMQ gives you the advantage of interoperability with JMS,STOMP or C/C++/ clients over open-wire. In addition to providing enterprise features (clustering, networks, etc) - and of course - enables integration with Apache Camel (either embedded inside ActiveMQ or via the ActiveMQ Component).

Tuesday, April 10, 2012

Beta release of FuseSource Enterprise Products

FuseSource has launched the Beta program for two new Enterprise products its launching today.
These products, Fuse ESB Enterprise and Fuse MQ Enterprise,  provide the capabilities to make integration and messaging even easier to deploy and manage.

Central to the new functionality the Enterprise products  provide are Apache licensed open source projects that that FuseSource has been working on outside of the Apache Software Foundation, called Fuse Fabric and FAB (Fuse application bundles), which have been designed to work seamlessly with Apache Camel, ActiveMQ, Karaf, CXF and ServiceMix.

The Enterprise products are about providing stable, production ready integration platforms for large scale deployments. As well as the additional system and platform testing that goes beyond what we do at the Apache Software Foundation, we also run the products through independent security and license validation, and provide platform installers. For developers, we provide Fuse IDE - Eclipse based tooling for deploying and managing running integration routes based on Enterprise Integration Patterns from Apache Camel. For FuseSource subscribers, we will also be providing incremental patching, and configuration and deployment tooling for the remote management of enterprise deployments (Fuse Management Console) and FuseHQ for operational monitoring.

Fuse Fabric

The main project providing the deployment and configuration required for enterprise deployments is Fuse Fabric, which provides a centrally managed distributed configuration, provisioning and runtime registry for services deployed on-premise, in the cloud or both. The main driver for Fabric is that deployments of more than one Apache ServiceMix or ActiveMQ instance can get complex pretty quickly, and FuseSource has customers who deploy with thousands of instances of these projects. So an Enterprise deployment requires a lot of upfront knowledge, and its easy to get wrong. They also require location transparency and the ability to support the failover of endpoints. Fuse Fabric has been developed to solve these problems, and to make the creating interconnected services, clusters and networks of brokers simple. Ioannis Canellos has a nice video demonstration of Fuse Fabric and Camel  here.

The Fuse Enterprise products utilize the power provided by Fuse Fabric, and key to that is the Fuse Management Console and the new functionality built in to Fuse IDE.

A central part of the Fabric is the deployment container, which can manage and control child containers, and is based on Apache Karaf, which is a small OSGi based runtime and a project which we developed out of Apache ServiceMix.  OSGi is great technology for providing modularity and services for Java applications, but it can be difficult to migrate existing applications or create new ones to use OSGi - which is why FuseSource has created Fuse Application Bundles.

Fuse Application Bundles

OSGi is an ideal micro container for the JVM, its small and modular, simple yet powerful. OSGi supports hot (re) deployment of services at runtime and has framework support from blueprint or Spring-dm.

However, OSGi bundles ate very fine grained and use package level metadata. To control bundle dependencies requires defining version ranges for every bundle, and typically an application will consist of 10s or even 100s of bundles - thats a lot of packaging and metadata, which often leads to mistakes - and it can be very time consuming to get right. Developers just want to get their applications deployed and working quickly - hence Fuse Application Bundles (FAB).

The goal of FAB is to provide a simple way of managing dependencies and class loaders so developers can concentrate on developing value to the business, and avoid learning new ways of dealing with dependencies just for OSGi. FAB enables developers to use a common model of class loaders across build tools, IDE and the OSGi container - how often does code work in the IDE, only to fail when its deployed to an OSGi container? 

FAB works by using the transitive dependencies all ready defined in an application jar which has been built by maven or sbt. It also enables you to define what to dependencies you wish to share, or you expect to be provided. There's some great examples of using FAB provided with Fuse ESB Enterprise.

Friday, February 03, 2012

Apache ActiveMQ Apollo 1.0 is released!

Apache ActiveMQ Apollo 1.0 has gone GA. Hiram Chirino does a great summary of features and functionality on his blog.

About 2 years ago, FuseSource started to think about the requirements of enterprise messaging systems for the next 10-15 years. There has been an exponential growth in the amount of data used by organisations over the past 25 years, and that trend is set to continue for the next 25. Once applications held megabytes of data, now they can hold petabytes (10^15). Within 5 years that will be zetabytes (10^21).  Speed of accessing that data is increasing, especially with the use of BigData (Apache Hadoop, Cassandra, MongoDB etc) - and so is the requirement for filling data stores with the vast volumes of data required.
Message-oriented middleware is all about transferring data reliably and as quickly as possible from one application to another. So it made sense for us to look at the requirements of the next generation of ActiveMQ with that in mind. We realised we would need to provide the following:

  • Extreme throughput
  • Scale to millions of dynamic destinations  for both point-2-point (Queues) and publish/subscribe (Topics).
  • Scale to 100,000 connections or more
  • Extensive protocol support (STOMP/OpenWire/MQTT/AMQP).

Apache ActiveMQ is performant, and provides extensive capabilities - but in its current architecture, its not going to meet the performance and scaling we required. ActiveMQ 5 is really stable - after being deployed in real world production environments, its become very battle hardened,  its not something we radically want to change. However, if you examine some of the internals of the current broker, you realise that there are too many points of synchronisation for ActiveMQ to scale up for the next generation of messaging problems that we will start to encounter in just a few years time.

It was decided early on that to help with scaling and concurrency, we should use a functional language -  which would help reduce side effects (and hence the need for synchronisation), and enable Apollo to maximise the utilisation of multi-core architectures. Currently, the Apollo broker is written in the Scala programming language. At the core of Apollo is the Grand Central Dispatch (GCD) technology  to help optimise support for multi-core.

The implementation of GCD, has been implemented by Hiram - and is called HawtDispatch.  ActiveMQ Apollo currently supports the STOMP protocol, but it does support JMS - using JMS over STOMP - there are performance comparisons here, which demonstrates Apollo's performance, even using a text based protocol its considerably faster than ActiveMQ 5 - which uses efficient data encoding based on OpenWire.

Right now ActiveMQ Apollo is a very performant message broker, that you should use if raw  performance is the overriding criteria of your architecture.  Later releases will be adding support for more protocols (MQTT, OpenWire, AMQP) and the enterprise features that will bring it in line with ActiveMQ 5. When this work is complete FuseSource will also provide a hardened supported version of ActiveMQ Apollo.

Thursday, January 26, 2012

CamelOne is back!

FuseSource is hosting the CamelOne event this year in Boston, MA,  May 15-18th 2012. Its the best conference to go to to hear about Apache Camel, ActiveMQ, ServiceMix, Karaf and CXF.
Its going to be awesome!

Its also going to be a great opportunity for us to talk about all the really cool, secret technology we've been developing at FuseSource for the past year too :)

To get a flavour of technical content at this event - you can view last year's sessions ...