I want to deploy the first one (Message Queue) as an OSGI bundle, the second (Content Based Routing) as another OSGI bundle and the third (Transform) and fourth (CXF Remote Provider) both as a single bundle.

 

On the multiple bundle approach - it's actually more straightforward to put the whole route into a single bundle. There's a number of reasons for that

• it means that when the bundle start/stops, there's no ordering issue, the route starts and stops in one step,

• the code/configuration for the route will be quite small, so partitioning it doesn't really give any modularization benefit,

• using Camel, this multi-bundle usecase would need to be implemented as four separate routes, joined by vm: endpoints, so there's probably too many moving parts

Would a single bundle packaging work for you?

I'm trying to bring out some more information, so some further questions,

but I do have a possible solution (although there's no pre-existing tutorial - we can try working this out together).

 

The first bundle will always be re-usable and if it changes on it should affect all other modules using it.

 

The first bundle in this case will contain the equivalent of a Camel from("jms:queuename"), which is quite tiny. The overhead of the metadata a bundle packaging would be more than the actual functional content of the bundle.

If it is envisaged that the queue name would need to change, then it would be a good solution to have that as configuration and a re-start of the route would effect the change.

 

The second bundle changes as long as their are new routes to be added. The third module is also unique as it represents new cxf provider with will be added and hence a new route which should be added as well.

 

I have a little terminology difficulty here. When I write route, I mean the full traversal from the JMS on the input end to the CXF on the output end. I think what you mean here is that you want to be able to add to the choices on the output of a content based router, right?

 

What I really want is a solution that will allow me to add new route + cxf provider without bringing down existing routes + cxf providers.

 

I think what we need here is a set of independent route elements that are joined by persistent queues so we don't lose any messages. I've sketched out such a route using the Integration Designer, and annotated it with rectangles indicating the OSGi bundles - the content of each rectangle is a bundle

Does this kind of match what you are looking for in terms of the deployment characteristics? The extra JMS queues (it's hard to read in the diagram, but they are called Q) are there to ensure we don't drop messages as bundles go up and down.  Because each bundle will have a separate Camel context, you can't use the seda: component to join the individual route segments. You could use the vm: component, which effectively provides SEDA across separate Camel contexts in the same Java VM, but if the VM bounces, then you could lose messages. On a similar topic, you should ensure that the broker for the 'connecting' queues is hosted outside the VM too

Are you familiar with the Eclipse PDE tools? They're the best game in town at the moment for creating OSGi bundles (IMHO) and by constructing your routes in Java it's quite straightforward to make the bundles you will need. If the diagram above is accurate, and you are not familiar with the tools, then I could probably knock a few bundles together at some point.

Hi Oisin,

As long as MyQueue is transacted, couldn't you use camel-nmr endpoints in place of the Q0-3 queues. The MyQueue transaction wouldn't commit until the DONE returns from all the recipient list targets, right? If the vm goes down, the MyQueue transaction is rolled back and it gets retried when the vm is re-started, right?

/Ron

 

As long as MyQueue is transacted, couldn't you use camel-nmr endpoints in place of the Q0-3 queues. The MyQueue transaction wouldn't commit until the DONE returns from all the recipient list targets, right? If the vm goes down, the MyQueue transaction is rolled back and it gets retried when the vm is re-started, right?

 

Ron - I fairly sure you're right on that one, but I would need to test it for 100% surety   Good catch - and I don't think one would even need to have camel-nmr endpoints, one could probably get away with camel-vm endpoints for SEDA-like fast message handoffs in the VM and ditching the dependency on a local broker for persisting the messages.

I am making some assumptions here, but it would be good to try this out -- I won't get a chance to run this up for a while...

I'm glad I am getting closer to understanding this case

 

Sorry, Am a lil bit lost in here. I am new to Fuse/ServiceMix/Camel systems. Can you explain to me what this means. I think you are probably talking about modularizing context-based routes in different deployment, right?

 

Yes, I was thinking out loud about approaches to join the bundles hosting the different segments of the route. Sorry for the confusion, some of the items there were unnecessarily detailed for this stage of explanation.

The PDE tools of Eclipse are used to create Bundles - but they are not maven based. The PAX maven plugin is probably the way to go. I suggest that you take a look at this tutorials Step 1 Initial Project Set-up for information on how to create a maven project and import the project into Eclipse.

There has been some anecdotal reports of issues using Integration Designer 1.2.1 in Eclipse 3.5, but they are not completely isolated. What are the issues that you are having?

 

Lastly, can Fuse HQ monitor the flow of these messages from the from("jms:queuename") to the cxf service for each service? I need to know if/when there is a failure somewhere and find out why the failure ocurred and probably correct it.

 

Yes, Fuse HQ can certainly monitor the queue, but I'm not sure how much it can do in terms of peeking into the various pipelines in the route - this is just because I don't know Fuse HQ quite as well as I should. What I suggest here is that you visit the Fuse HQ Forum and ask questions there.