Janne, If you can implement this as a Camel only solution, that's definitely the way to get started. I see you're planning to use ActiveMQ queues to communicate between bundles and to provide additional reliability, which are actually very good reasons for adding ActiveMQ to the 'Mix there. ServiceMix will just make it easy to combine those two because it conveniently packages them together into a single runtime environment. , but I wouldn't go and add more technologies or components than that if you don't need them.
If you ever need an in-memory transport for exchanges or you want to start building exchange listeners to implement common behavior to be added in between routes/bundles (like auditing, security, ...), that might be a good time to start thinking about adding the NMR, but for now it seems to me that you have picked the right technology combo to solve your integration problem. Regards, Gert Vanthienen ------------------------ FuseSource Web: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On Tue, Mar 8, 2011 at 7:01 AM, janne postilista <[email protected]> wrote: > I'm implementing a simple integration solution and wondering about the > best design. > > Solution reads from JMS queue queue-A and writes to queue-B. In > between the message goes through two transformations: first from > queue-A format to standardized format, then from standardized format > to queue-B format. > > To enable easy changing of queue-A format and queue-B format, I'm > implementing this as 3 OSGi bundles: > > 1. main bundle > - reads from queue-A > - writes to transformation1-in > - reads from transformation1-out > - writes to transformation2-in > - reads from transformation2-out > - writes to queue-B > 2. transformation1 > - reads from transformation1-in > - does transformation from queue-A format to standardized > - writes to transformation1-out > 3. transformation2 > - reads from transformation2-in > - does transformation from standardized formation to queue-B format > - writes to transformation2-out > > There's JMS queues (for example) between each step to make processing > reliable, so that if servicemix/camel crashes while doing > transformation1 for example, message does not get lost. > > - I believe this could be implemented as camel-only solution - each > bundle is a separate camel route and does not involve other servicemix > components (such as NMR) at all > - I guess other option would be to involve servicemix NMR (how would I > do it with these 3 bundles?) - would this have some benefits over > camel-only solution? Would it simplify implementing reliability, for > example (would I still need to use explicitly each intermediate queue, > eg. transformation1-out)? >
