JBoss Enterprise Forum, and the red hat goody
A summary of this month’s JBoss Forum on Integration consisting of:
- a description of the venue, speakers, and audience;
- short summaries on what each speaker spoke about.
This short overview I have taken from my notes supported by my memory. I’ve verified the information that’s open to the public. Yet, inaccuracies and errors, if any, are my own.
At the entrance to the Stationer’s Hall
Yes, I couldn’t resist Red Hat’s red hat. I received one at the JBoss Enterprise Forum where Integration was the focus. This was on Thursday, 7th February 2013 at the Stationer’s Hall; a hall, well preserved from the 14th Century, and rich in history.
Though the hall’s history was a conversation starter, Integration was the theme. Red Hat had chosen its speakers well – addressing both the business and technical aspects of Red Hat and Integration. These were:
- Werner Knoblich, VP and General Manager of Red Hat EMEA;
- James Strachan, Senior Consultant, Software Engineering, Red Hat; (He created the Groovy programming language)
- Rob Davies, Technical Directory for Fuse Engineering, Red Hat; (One of the authors of the book, “ActiveMQ in Action”)
- Steve Gaines, Head of Middleware, Red Hat UK and Ireland.
The audience was varied; varied in where they work – some in private companies, in institutions of education, in public sector organisations, some as industry analysts; varied in what they do, in their interests, concerns, and outlook; out of which Steve Gaines addressed three important ones bringing all the rest in harmony, as the different musical notes, when suitably combined, form a harmonious sound.
The start of the day was an indication that Red Hat had arranged the sessions optimally – they started with breakfast 🙂
Then onto the business overview, followed by the theoretical concepts of Integration and Messaging. After this was a short coffee break. Then James Strachan demonstrated Integration using Apache Camel with Fuse IDE. Next was Steve’s short and well-arranged talk, which led into the Question and Answer (Q & A) session.
Werner explained three important things:
That Open Source was not Red Hat’s business model. Rather, it was the way that Red Hat developed software;
Red Hat’s acquisition of FuseSource (link) gives Red Hat a stepping stone (and a place) into Enterprise Integration, which is to become part of their product suite centred around Integration.
Red Hat’s acquisition of Polymita (link) means that Red Hat is moving into the BPM (Business Process Management).
In this way, Red Hat covers two areas: the front end with BPM; the middle end with FuseSource, and back end with the JBoss Application Server.
After the sessions with James and Rob, two questions required fuller explanations from the speakers, namely:
- In JBoss, what is the recommended way to do Messaging to enable Integration without using standalone Messaging Providers?
- What’s the relation between FuseSource Apache ActiveMQ and Apache Camel?
As to the first question, the background is this: in the JBoss Application Server (AS) 4, there was a JBossMQ component which you could use for messaging. Then in JBoss AS 5, 6, and 7, JBoss has a messaging component, which uses HornetQ internally. And now that JBoss has acquired FuseSource, which comes with its own FuseMQ, there’s more choice. What JBoss would like to do is to have one way to do messaging in the future, and that’s by using FuseMQ.
What then is FuseMQ and how is related to FuseSource? FuseMQ is a product developed by FuseSource. Building on top of ActiveMQ, FuseSource has made FuseMQ to address few important requirements of enterprise messaging, such as Clustering and High Availability.
Another requirement which FuseSource seeks to satisfy is that of providing patches and upgrades as soon as possible, if it’s part of your agreement (Service Level Agreement – SLA) with them. Suppose that during production, you found a FuseMQ (or ActiveMQ) bug which affects your application, submitted it, and according to its severity and SLA, required a patch in 48 hours, then FuseSource can provide the patch. If the same bug was submitted to the Apache Software Foundation (ASF), ASF would need at least 72 hours to vote to include the bug fix in the next release.
From the Apache HTTP Server documentation, we have these statements which apply to the ASF projects:
In fact, each Apache Software Foundation project has its own PMC (Project Management Committee), to determine committers, project direction and overall management. . . .
The project is a meritocracy — the more work you have done, the more you will be allowed to do. The group founders set the original rules, but they can be changed by vote of the active PMC members. There is a group of people who have logins on our server and access to the source code repositories. Everyone has read-only access to the repositories. Changes to the code are proposed on the mailing list and usually voted on by active members — three +1 (‘yes’ votes) and no -1 (‘no’ votes, or vetoes) are needed to commit a code change during a release cycle; docs are usually committed first and then changed as needed, with conflicts resolved by majority vote. . . .
Anyone on the mailing list can vote on a particular issue, but only those made by active members or people who are known to be experts on that part of the server [application] are counted towards the requirements for committing. Vetoes must be accompanied by a convincing technical justification.
Since some of those who develop ActiveMQ, i.e., committers, work for FuseSource and FuseMQ is a fork of ActiveMQ, FuseSource is not as restrained, and is therefore free to provide patches when you need them. Later on, these patches are merged into the main ActiveMQ branch, after the usual ASF voting system.
The relation and process described above exists between, and is applicable to, Apache Camel and the FuseSource’s Mediation Router.
Steve Gaines was the final speaker. Using four case studies as examples, he described the three requirements of three enterprises that ActiveMQ was able to satisfy. Naturally, the numbers (or metrics) are still exciting to see.
- Performance: For this example, their client, through ActiveMQ, was able to handle 32,000 transaction per second. I don’t remember if, in this case, transactions mean the same thing as messages. But since the context is Messaging and Integration, I’ll assume so for now.
Nevertheless, the default implementation of ActiveMQ can handle 6000 messages per second, assuming that the rate you produce messages is at least the same rate that the receiver will consume them. Imagine producing 6000 message per second but the receiver consuming 10 messages per second. And of course, before discerning this, you raise a defect with ActiveMQ 🙂
Global Scalability: For this client (SpecSavers), the challenge was threefold: rolling out Messaging to 1900 global retail stores, managing the installations, and affording to pay for the product to use in that many stores. The installation and service costs of ActiveMQ made it attractive to SpecSavers.
Proven Enterprise Quality of Service (QoS): this client (CERN) cared about running the operational grid for the Hadron Collider. The goal here was to distribute 100, 000 messages in more than 140 facilities in 20 countries.
You’ve got to admit, that’s an impressive list of what JBoss and ActiveMQ were able to accomplish.
__
During the demo and Q & A sessions, James Strachan, using the Fuse IDE, showed us how easy it is to use Apache Camel to integrate several systems. In addition, with Camel, you’re middleware logic is separate from your business logic; and this makes testing integration simple. Because most of the Camel classes have corresponding JMX MBeans, Fuse IDE takes advantage of that to make it easy to visualise as messages pass through Camel and are routed to different destinations.
I enjoyed this forum; and it wasn’t all because of the red hat.