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.