At times, what we write ends up being longer than we thought, and we’re naturally uneasy that the length of it will dissuade our fellow readers from proceeding. In my previous entries is one sentence that I had started in order to justify the length of that article: that while considering the reader’s time and attention, it was in proportion to the subject-matter. But, in hastening to describe the event to you, I left the thought there incomplete. Now, adding a little to that thought here, is what this entry is about.
When we come across long articles, one of our initial reactions is reaching for that common, though inaccurate, saying, that “a picture is worth a thousand words,” placing it next to the article, and wondering whether it imperceptibly escaped the writer, while we ourselves are subjected to thousands of words when (or so we think), for the same purpose, a couple of pictures would have been just as adequate.
All of which could be true; yet, keeping articles short is often not possible, at least of those that I’ve tried to write. These have been on events whose content I thought worthwhile to transcribe. I am fully conscious of how we all are pressed for time, and how difficult it is to retain anyone’s attention for a long time; and how, even in those moments of relaxation or idleness, we prefer almost any thing that doesn’t tax our attention for long. But we do make time, and compel our attention, for those things we consider worthwhile.
It’s out of this concern, at least in part, that for those blog entries describing the events, I determined to make one or two statements to explain why the length is in proportion to the content. I may be going to more events, which means that, for subsequent blog entries, I’ll probably be repeating those statements. So, applying the DRY (Don’t Repeat Yourself) principle, I thought it convenient to have such an explanation in one place which I can refer to.
As for that common saying, “A picture is worth a thousand words,” wherever it’s appropriately applied, I would add “that describe it.” Consider this: here is a picture; is it worth any thousand words? Would it be worth the first thousand words in a dictionary? What about the last thousand words? I’m accounting for only the number of words, not the “picture,” or the “words” used, or the standard of “worthiness” appealed to.
Now, at these events, there are more things to describe than I have the inclination, and the ability to do so strikingly: there are those one-on-one conversations you have with others who are attending, either during the breaks or over drinks; there are those numerous hints from the expressions of people’s faces, their varying modulation of voice, and their actions which gradually rise from expressing nervousness to confidence; all of which would occupy a curious observer because of the probable lessons they contain.
Furthermore, on stage, all these are somewhat magnified. There, we see the earnestness of the speakers, which diverts us from the familiarity of the day’s routine; and which fixes our attention, at least for a while, on our temporary instructors and on their subject-matter. Stranger still, even those plain announcements take a transient hold on us.
To describe all these would take much more than a thousand words. So far, I, like some others, have limited these summaries to those talks that we’ve been to, and take it for granted that the contents of those talks are able, by themselves, to sustain your interest while reading about them in more than a thousand words.
As always, I’m happy to be corrected.
For others going to events, and writing summaries, I can’t wait to read them, however long they turn out to be.
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.
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.
red hat in the office
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.