I’m happy to announce that Red Hat Fuse 7.0 is now officially available!  This is major new release which focused on expanding support for distributed hybrid integration deployments.  Fuse now comes in 3 distributions:

• Fuse Standalone.  Run integrations in your choice of JVM platform: OSGi, JEE, or Spring Boot.  This is an evolution of what was provided in Fuse 6.3.  In addition to the new Spring Boot support, major Fuse building blocks like Apache Camel, Apache CXF, Undertow, etc. received big version bumps and version alignment across all the support JVM platforms.  You also now get feature parity in terms of Camel component support across those platforms.
• Fuse on OpenShift.  Builds on the foundations of Fuse Standalone, but gives you the tooling and base images to run your integrations in cloud native way on OpenShift.  OpenShift gives you the foundation you need to run robust scale out clusters of integration services and automate it all using CI/CD.  Since OpenShift runs in your datacenter or in any cloud datacenter, it’s the easy way to build the abstraction need to do hybrid cloud deployments.
• Fuse Online. Building on the foundations of Fuse on OpenShift, Fuse Online provides a new web based UI allows a for a no-code/low-code way to develop integrations.  Business users can now self-serve to implement simple integrations without needing to wait for developers to implement their use cases. Yet, it allows developers to plug in and expand the functionality available to those business users.  This allows business managers and analysts to collaborate more effectively with their development teams.

This new Fuse allows you have even more agile integration development. Fuse installations can span online, on-premise, or container based environments without reducing functionality. This allows an integration platform that crosses environments, and be as lightweight and decentralized as an individual development team or an enterprise-wide platform. You can more importantly run your integrations where it makes most business sense and controlled by different groups yet managed and operated in a common way.

Additionally, Fuse 7 contains these new features:

• 50 new application connectors (with a total of over 200 included connectors)
• A new monitoring subsystem
• A new name (Red Hat Fuse, rather than Red Hat JBoss Fuse)

Want to learn more? Why don’t you try out Fuse Online, the easiest way to get started with Fuse.  Or read more about Fuse 7.

I’m happy to announce that JBoss Fuse Integration Service 2.0 has been released. The Fuse team has been hard at work bringing Camel 2.18, Spring Boot, to the OpenShift platform. This is the best platform to develop and operate integrations in a micro microservice architecture.  It lets you create tailored containerized integration applications that package only the middleware services that you need and no more.

What is Fuse Integration Services?

Fuse Integration Services (FIS) is a distribution of JBoss Fuse that provides tooling and runtime support for creating containerized integration services on OpenShift, including

• Docker-formatted container images for a Fuse runtime
• Tooling to create, develop and build containerized Fuse applications
• Self-service deployment templates for common integration scenarios
• Native integration with OpenShift for service discovery, clustering,and configuration management
• All based on the core technologies (Camel, CXF, Karaf) available in JBoss Fuse

What’s New?

• Support for Fuse on Spring Boot along with the latest version of Camel (2.18).
• Completely overhauled templates and getting started experience for OpenShift.
• FIS-specific tooling added to Fuse Tooling suite for Developer Studio.
• A brand new Getting Started guide
• Alignment with Fuse 6.3 for Karaf images to ease transition for existing Fuse customers using Karaf/Blueprint-based apps.
• Uniform alignment with OpenShift source-to-image for both source and binary builds.
• Improved quality and bug fixes across the board.

Ready to get started?

Check out the official docs

I’m pleased to announce the availability of Apache Apollo 1.0.  Apollo is a faster, more reliable, easier to maintain messaging broker built from the foundations of the Apache ActiveMQ project but with a radically different threading architecture which lets it scale to large number of concurrent connections and destinations while using a constant number of threads.

Apollo features:

• Stomp 1.0 Protocol Support
• Stomp 1.1 Protocol Support
• Topics and Queues
• Queue Browsers
• Durable Subscriptions on Topics
• Persistent/Reliable Messaging
• Message Expiration
• Message Swapping
• Message Selectors
• JAAS Authentication
• ACL based Authorization
• SSL/TLS Support and Certificate based Authentication
• REST Management API

Yes, it supports JMS!  Just download Apollo, start it up using the getting started guide and then check out the distribution’s examples directory.  Oh yeah, Apollo has great documentation!

I’ve re-run the STOMP benchmarks I covered in a previous post against the 1.0 release.  The benchmark uses the STOMP protocol to build an apples to apples performance comparison between all the major STOMP servers.  I’ve also built a new JMS benchmark which uses the JMS API build the same kind of performance comparisons.  Both benchmarks are open source and available to be tried out on your choice of hardware.  Or better yet, follow the simple instructions found in each project’s readme to run the benchmarks on EC2:

• https://github.com/chirino/stomp-benchmark
• https://github.com/chirino/jms-benchmark

For those of you wondering why the ActiveMQ project create new message broker as a subproject, it’s because we wanted to address the shift in the processor market to multi core for the next major release.  ActiveMQ currently employs complex thread locking which starts to become bottleneck as you increase the core count and you don’t end up fully exploiting the potential on large core count machines.  By developing the solution as a subproject, it’s easier to explore the best options without impacting current main line development of ActiveMQ 5.x.

Now that the Apollo sub project has proven itself, I think it’s time to start integrating it into ActiveMQ.  Ideally, ActiveMQ 6 switches Apollo’s messaging engine and adds/ports all the existing features we’ve come to expect out of ActiveMQ like networks of brokers and priority queues.  But we should really be talking about this on the Apache mailing lists.. join me there!

ActiveMQ Apollo is a new generation of messaging broker built from the foundations of the ActiveMQ messaging broker, but using a radically different threading and message dispatching architecture.  In it’s current incarnation, Apollo only supports the STOMP protocol but just like the original ActiveMQ, it’s been designed to be a multi protocol broker and in future iterations it should get OpenWire support so it can be compatible with ActiveMQ 5.x JMS clients.

The BIGGEST change in the broker architecture was a switch to a non-blocking threading model for message processing using the HawtDispatch library.  This meant changing many of the APIs to using a continuation passing style so that caller never blocks on a request.  The upside of the new architecture is that the most complex and brittle areas of multi-threaded code in ActiveMQ 5.x  have now been tremendously simplified.  Those areas are using actor style coarse grained synchronization thanks to HawtDispatch.

It is impressive how well Apollo performs. Using a little benchmarking tool, I compared the performance of Apollo and three other STOMP server implementations.  The benchmark tests different combinations of consumers, destinations, producers, persistence options, message sizes for a total of 74 common usage scenarios.  I ran the benchmarks on two different boxes.  If you want to peek at the complete benchmark reports, see Ubuntu 4 Core report and OS X 8 Core report.

Apollo ends up doing really well in comparison to other servers in most cases but in some cases it’s just mind blowing.  For example:

The  scenario above is the case where you have 10 producer and 10 consumers on a single topic moving non persistent STOMP messages with a 20 byte payload.   The graph shows that Apollo can easily sustain a total consumer processing rate of 1.2 Million messages per second while the closest contender could only reach about 105,000 thousand messages per second.

I’m very excited to announce that Mop 1.0 M1 has been released. Mop is one of those tools that you wish you have had years ago. Most of you probably have not heard of mop yet. Mop is:

… a small utility for executing Java programs which are stored as artifacts like jars or bundles in a Maven repository. MOP automatically deals with the following for you transitive dependencies downloading artifacts from remote repositories and caching them locally setting up your class path

It’s a wonderfully small download that weighs in at only 3.2 megs.  Why don’t you try it out today?