There are some points I miss here. From the initial description I understand that your use case is fairly simple: consume message from A, enrich / transform them using B & finally send them to C. What I don't get is how you ended up having like 20 processors. The number sounds really big to me. I would understand having like 2 processors in a problem like the one describe, but 20 is really big and of course if you are trying to have them loosely coupled (which I don't see why) will eventually create a problem harder to solve than the initial one.
Since you have the integration libraries ready, beyond doubt is simpler to code just a class that calls the methods and not use any framework at all. It's simple, but also a bit "simplistic". What I want to say is how are you going to handle in your code some typical integration problems? i) You receive messages from A in higher rate than B responds, and you keep on piling messages in memory? ii) You loose connection with service B, while receiving messages from A? iii) You loose connection with service C? iv) You go live and you find out that service B crashes when the load is increasing and you need some kind of throttling? v) Specs change B responds asynchronously using a new service D (you need some correlation)? Then you are going to need retry policies, maybe do some stuff async. On top of that you may also need some logic to filter out duplicate messages etc, throttling etc. Are you going to code all these on your own? So I would say that using 20 processors loosely coupled, might be an over engineering, but all the rest when we are talking about integration doesn't sound like over engineering to me. Ioannis Canellos FuseSource Blog: http://iocanel.blogspot.com Apache Karaf Committer & PMC Apache Camel Committer Apache ServiceMix Committer Apache Gora Committer Apache DirectMemory Committer
