Meet Fabric8: An Open-Source Integration Platform Based on Camel and ActiveMQ
Meet Fabric8: An Open-Source Integration Platform Based on Camel and ActiveMQ
Join the DZone community and get the full member experience.Join For Free
It provides automated configuration and deployment management to help make deployments easy, reproducible, and less human-error prone.
Fabric8 unifies and packages those open-source projects to help you build integrations between systems and also tackle non-functional requirements like managing your deployments, service discovery, failover, load balancing, centralized configuration, automation, and more! It also gives a clear path to cloud deployments, such as on PaaS The best part is it’s familiar to people who already use Camel or ActiveMQ which are the most popular open-source integration libraries and messaging platforms respectively.
Awesome, so what does Fabric8 give me?
Fabric8 provides a LOT of functionality … but a couple of key pieces of functionality that I’d like to mention in this blog post, pieces that you’d otherwise have to build out yourself if you use the constituent projects directly, are:
* Automated deployment and provisioning * Polycontainer support * Centralized management * Service discovery * Load balancing * High availability * Master/slave failover coordination
With Fabric8, you build your integration pieces, deploy them and manage them (together this creates a “fabric”) where nodes represent containers with provisioned pieces of your software (deployments) and the endpoints (HTTP, MQ, SOAP/REST) are registered in a repository for dynamic lookup.
A DevOpsy story
Think for a moment about what your current build and release process looks like…
For Java shops you probably have Maven to build your source code, subversion or git to provide version control and change management around your source code, and maybe Jenkins for managing your builds, right? And that’s a very powerful set of tools for Java developers.
But a build and release process is more than using a few tools regardless of how powerful they are.
Getting your code to production involves a lot more on the operations side that developers either don’t get or are oblivious to. What containers does your code run in? What operating systems? What supporting software needs to be around? Are these environments carefully crafted and manually configured with behemoth containers that are brittle to change, are different depending on which environment they run in (DEV/QA/UAT/PROD, etc), ??
Successful IT shops embrace the DevOps movement and its principles of communication and automation to create an environment that is easily scripted/automated, reproducible, and removes as much human and manual configuration as possible.
A dev person thinks in terms of code and app servers.
An ops person might be thinking in terms of managing VMs, servers, OSs, network, etc.
But therein lies a gap. What tools do developers have to automate deploying containers, provisioning their applications, configure those apps, and visualize/manage this from a central location?
Ops folks are familiar with Puppet/Chef/Ansible/MCollective/capistrano… and using these tools in concert with Fabric8 will give you a very deep and powerful stack for automation and configuration management to help you achieve consistent and reproducible deployments to production to implement a continuous delivery model.
So what’s the value that Fabric8 adds?
Consistency across containers
A consistent way of configuring your deployments with Profiles that works across java containers (Karaf, Tomcat, Wildfly, TomEE), micro-service frameworks (Dropwizard, Spring Boot, Vert.x), and plain-jain Java Main (PJJM, TM ) based apps.
A unified web console based on HawtIO to manage your profiles, deployments, brokers, services, etc. There are even rich visualizations for your Camel routes and debugging and tracing when there are problems.
For all the deployments within a Fabric, Fabric8 can not only manage them but also register them into a run-time registry that clients can use to automatically find the set of HTTP endpoints (SOAP/REST, etc) they need, or MQ services (brokers, master/slave pairs, network of brokers, etc). Additionally, external clients can also use the registry to discover services.
Deep understanding about your running services
While the familiar Ops tools like those mentioned above are great at getting software onto disk for sets of machines they cannot give a rich understanding about the services running. For example, with the Camel plugin for Fabric8, you can track #s of exchanges completed, those failed, amount of time an endpoint is taking to complete exchanges, etc. With the ActiveMQ plugin you can visualize your queues/producers/consumers, send messages to queues, move messages from DLQ, etc. Additionally, there are plugins for ElasticSearch/Kibana for even deeper understanding of business/integration processed implemented by your code/Camel routes.
Fabric8 uses tools that are already familiar to Java developers writing distributed integration services or applications. For example, all of the configurations (Profiles) are stored in git. The provisioning mechanisms use Maven. The coordination services use [Apache Zookeeper][zk], etc.
Manage deployments in the cloud or across hybrid clouds
Fabric8 has built in support for deploying and provisioning to IaaS or PaaS out of the box. There’s even support for Docker based containers which you can then ship and use in any environment.
What about ServiceMix?
ServiceMix is also an open-source ESB based on Apache Camel and ActiveMQ. So how does this relate to Fabric8?
ServiceMix is the genesis of the current JBoss Fuse/Fabric8. It started off 9 or so years ago as an implementation of an EnterpriseServiceBus (ESB) based on the Java Business Integration spec. It’s goal was to provide a pluggable component architecture with a normalized messaging backbone that would adhere to standard interfaces and canonical XML data formats. ServiceMix gained a lot of popularity, despite JBI being a overly ceremonious spec (lots and lots of XML descriptors, packaging demands, etc). But, despite most products/projects offering integration services as a large, complex container, the need for routing, transformation, integrating with external systems, etc. shows up outside of that complex “ESB” environment as well.
Around the SMX 3.x and 4.x timeframe, the project underwent some major refactoring. The JBI implementation was ripped out and simplified with routing/mediation DSL that would later become Apache Camel. This way the “heart” of the “ESB” could be used in other projects (ActiveMQ, stand alone, etc). Additionally, the core container also moved away from JBI and toward OSGi. Still later, the actual OSGi container was refactored out into its own project, now known as Karaf. So ServiceMix became less its own project and really a packaging of other projects like ActiveMQ, Karaf (which used to be core SMX) and Camel (which used to be core SMX). The older versions of JBoss Fuse (Fuse ESB/Fuse Enterprise) where basically a hardening of SMX which was already a repackaging of some Apache projects. Additionally a lot of the core developers working on SMX also moved toward contributing to the constituent pieces and not necessarily the core SMX.
Fabric8 takes the “ESB” or “integration” spirit of ServiceMix and adds a nice management UI (HawtIO), and all of the DevOpsy stuff I mentioned above, and paints a clear path toward large-scale deployments and even moving to cloud/hybrid cloud architectures.
If you develop systems/enterprise integrations with Camel, CXF, or ActiveMQ and deploy into OSGi (karaf), Servlet (Tomcat), Java EE (Wilffly) or stand alone (Vert.x, Spring Boot, DropWizard), then you should definitely take a look at Fabric8.
In subsequent posts, I’ll continue to dive into the functionality of Fabric8 and how you can use it to build robust, scalable integrations AND have a consistent and reproducible environment for deploying your integrations.
Published at DZone with permission of Christian Posta , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.