Message Bus for OSGi Services

Question

I am in the middle of the project, where we will transfer the main software system based on a larger set of custom-made technologies based on OSGi services. To do this, we most likely will need some kind of message bus that works well with OSGi services.

• ASync Sync and Delivery
• Point to point only
• Guaranteed delivery - preferably with saving via files
• A strict message ordered from the same client (Async mode), but always from different clients
• Process support for the process and node-to-node is a nice but not necessary necessity

Initial solutions are recommended, but not required.

I looked at eventbus (as recommended in https://stackoverflow.com/a/3/7/7 ), but this does not work well.

So the question is, which technologies match the above?

Answer 1

Tonnie

Just come from a very similar and successful project, let me share my experience with you to save you time and your company for money. First of all, ESBs 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 the way that annoying coders understand it? The goal was to develop a system that would allow a business person to create a software solution with little or no fragmentary interaction with developers, which could absorb the money better spent on management bonuses.

To answer this, good people in many organizations came up with JBI, BPMN, and many other solutions that allowed businessmen to model the business processes they wanted to “digitize”. But in reality they were all mistaken at a very critical level: they considered business issues, but not integration issues. Thus, many of these implementations were unsuccessful, unless some expensive consultant had done it, and even then your prospects were fragmentary.

At the same time, some really smart people in the late 90s published a book called "Enterprise Integration Patterns", which identified more than 60 design patterns used to solve common integration problems. Many of the people performing the ESB material realized that their problem was not one of the business models. Rather, the problem was how to integrate existing applications. To help solve this, Michael Strachan and some really smart guys started the Apache Software Foundation "Camel" project. Camel is a strict implementation of corporate integration templates, as well as a huge number of components designed to allow people, both you and me, to combine things.

So, if you think that your business process is simply necessary for transferring data from one application to another with the corresponding data transformations between them, then Camel is your answer. Now, what if you want to base a “route” (a specified series of application endpoints that you want to send data) from a set of custom rules in the database? Well, a camel can do it too! There is an end to this! In any case, do not make the traditional ESB, its old and ruined. And absolutely make a camel.

Please let me know if this helps.

Answer 2

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

Event Admin specifies a means for the event source to send events to event listeners. Event sources can create events with a theme and properties and an Event Admin request for delivering events to event listeners who have expressed interest in specific thematic topics and / or property values. An event source may request synchronous (and disordered) deliveries or asynchronous (and ordered) deliveries.

Compared to your requirements, it will be evaluated as follows:

• ASync Sync & Delivery: Check
• Point-to-point only: None. Pub Sub
• Guaranteed delivery - preferably with saving through files: NO
• Strict message ordered from the same client (Async mode): YES
• Process support for the process: if (process == OSGi Service) -> Yes
• Node-to-node support: For now . The guys from Distributed OSGi are working on this, but I have not seen anything specific.

I like the Camel concept, but recently decided to go for the (lighter) Event Admin, since my requirements are limited. +1 Mike for the motivation of a camel. I would look at it and then compare the parameters before making a decision.

Answer 3

Aren't you looking for an ESB? ServiceMix :

flexible open source integration container that integrates the features and functionality of Apache ActiveMQ , Camel , CXF , ODE , Karaf into a powerful runtime platform that you can use to create your own integration solutions. It provides a complete, ready-to-run ESB, exclusively based on OSGi.

Answer 4

iPOJO Event Admin Handlers is a more convenient way to access the Event Admin service mentioned by @maasg.

Answer 5

It looks like you're talking about ESB here. If so, then you can look at wso2 ESB . It works from the Apache synapse . it uses OSGi as a modular structure, so you can add / remove functions to suit your requirements. There is a whole product stack from wso2, such as message brokers, business process servers (ODE), etc. Based on the same OSGi core platform.

Disclaimer: I work for wso2.