Message bus for OSGi services

Question

I'm in the middle of a project where we will migrate a major software system based on a larger set of custom made technologies to be based on OSGi services. For this we will likely need a some sort of message bus that plays nice with OSGi services.

• Sync and ASync delivery
• Point-to-point only
• Guaranteed delivery - preferable with persistence via files
• Strict message ordered from the same client (Async mode), but necessarily from different clients
• Support for process-to-process and node-to-node nice but not strictly required

Open source solutions will be preferred, but not required.

I have looked at eventbus (as recommended in https://stackoverflow.com/a/1953453/796559), but that does not seem to work well.

So the question is, which technologies match the above?

Answer 1

Tonny,

Having just come from a very similar, and successful project, please let me share my experience with you to save you some time and your company some money. First and foremost, ESB's were a really good idea 8 years ago when they were proposed. And, they solved an important problem: how do you define a business problem in a way that those pesky coders will understand? The goal was to develop a system that would allow a business person to create a software solution with little or no pesky developer interaction needed that would suck up money better spent on management bonuses.

To answer this the good folks at many organizations came up with JBI, BPMN and a host of other solutions that let business folks model the business processes they wanted to "digitize". But really, they were all flawed at a very critical level: they addressed business issues, but not integration issues. As such, many of these implementations were unsuccessful unless done by some high-priced consultant, and even then your prospects were sketchy.

At the same time, some really smart folks in the very late 90's published a book called "Enterprise Integration Patterns" which identified over 60 design patterns used to solve common integration problems. Many of the folks performing ESB stuff realized that their problem wasn't one of business modelling. Rather the problem was how to integrate thier existing applications. To help solve this Michael Strachan and some really smart guys started the Apache Software Foundation Project "Camel". Camel is a strict implementation of Enterprise Integration Patterns in addition to a huge number of components designed to allow folks like you and I to hook stuff together.

So, if you think of your business process as simply a need to send data from one application to another to another, with the appropriate data transformations between, then Camel is your answer. Now, what if you want to base the "route" (a specified series of application endpoints you want to send data thorugh) off of a set of configurable rules in a database? Well, Camel can do that too! There's an endpoint for that! Anyhow, dont' do the traditional ESB, its old and busted. And Absolutely do the camel thing.

Please let me know if this helps.

Answer 2

The OSGi specification defines a component "Event Admin" which is a lightweight pub-sub event subsystem. From the RFC0157:

Event Admin specifies a means for an event source to send events to event listeners. Event sources can create events with a topic and properties and request Event Admin to deliver the events to event listeners which have declared interest in specific event topics and/or property values. The event source can request synchronous (and unordered) delivery or asynchronous (and ordered) delivery.

Compared to your requirements, it would score as follows:

• Sync and ASync delivery: Check
• Point-to-point only: No. Pub-Sub
• Guaranteed delivery - preferable with persistence via files: NO
• Strict message ordered from the same client (Async mode): YES
• Support for process-to-process: if (process == OSGi service) -> Yes
• Support for node-to-node: Not yet. The guys of Distributed OSGi have been working on this, but I've not seen anything concrete.

I like the concept of Camel, but recently decided to go for the (lighter) Event Admin as my requirements are limited. +1 to Mike on the Camel motivation. I'd look into it and then compare options before deciding.