Is Blueprint inappropriate for relatively large integration?

[kgwhitaker13]

I have been recently engaged by a company that is making use of JBoss Fuse for the ESB/integration layer.  The implementation will have over 200 business integrations among several systems.  Each business integration consists of at least 2 OSGi bundles, often more depending on the number of consumers of the information being published.  If we assume that there are roughly 3 bundles per business integration, that is upwards of 600 instances of blueprint.xml. 

Here's my concern with Blueprint in this context.  Blueprint does not support any type of inheritance (ala Spring) or xinclude for including XML.  There is a significant amount of XML part of each blueprint that is just "plumbing".  Things like declaring common services, common beans, and so on.  This XML is copied for each Blueprint instance.  That means that we end up with 600 copies of the same thing.  We have found that you can have multiple XML files in the OSGI-INF/blueprint directory so we can brake out the common bits into a single file that is propagated to all business integrations. 

We also have common behavior within the Camel Context for each blueprint.  For example, the OnException block generally does the same thing for each OSGi bundle, so there is a chunk of 4 lines of XML that is copied everywhere.  Common behavior within a Camel Context cannot be broken out to a separate blueprint file.  Not a big deal until you need to change something.  Case in point:  We found that we needed to add a convert to java.lang.String.  So ... back to 100's of XML files to update this one line.

My question is this:  Is there a better way of dealing with parts of Blueprint that is common among the entire implementation?  This leads to the next question: is Blueprint appropriate in this scenario?

Thanks for any feedback on this!

[grgrzybek]

Hello Ken

I can only judge by what you've described here. If you say there are 600 "instances" of blueprint.xml, does it mean there are 600 Camel contexts?

This is probably more architectural question, then technical one. Imagine you don't use Fuse (or other OSGi framework) and you don't use blueprint, but, for example, Spring contexts. Even if you leverage Spring's <import> mechanism, you could end up with 600 instances of Spring's ApplicationContext - this isn't good. Blueprint container instance (made up from all blueprint XML files found by blueprint extender (aries.blueprint.core bundle) in single OSGi bundle is similar to Spring's ApplicationContext instance made up of different XML files.

In OSGi you have to think the OSGi way - the most obvious decision is to publish common "things" as OSGi services.

If blueprint lacks some mechanism (like parent-child relationship of Spring's ApplicationContexts), you have to try to reuse beans as OSGi services (<service> + <reference>).

I'd start with asking a question - how many different (separate) camel contexts ("containers" for routes, dataformats, ...) are there in your application. If you simply need ~600 routes, there's no need to have 600 camel contexts. You could "publish" camel routes using whiteboard pattern and have one (or several) bundles act as "extenders" which monitor these routes being added/removed/modified and act accordingly.

In other words - don't make assumption that each OSGi bundle have to equal separate blueprint container.

best regards

Grzegorz Grzybek