views:

43

answers:

1

First of all thanks to folks who are currently involved in the development of Camel, I am grateful for all the hard work they have put in.

I am looking for some design advice.

The architecture is something like this: I have a bunch of Java classes which when instantiated are required to connect to each other and send messages using Apache Camel. The design constraints require me to create a framework such that all routing information, producers, consumers, endpoints etc should be a part of the camel-context.xml.

An individual should have the capability to modify such a file and completely change the existing route without having the Java code available to him.(The Java code would not be provided, only the compiled Jar would be)

For example in One setup, Bean A ->Bean B->Bean C->file->email. in another Bean B->Bean A->Bean C->ftp->file->email We have tried various approached, but if the originating bean is not implemented as a Java DSL, the messages rate is very high because camel constantly invokes Bean A in the first example and Bean B in the second(they being the source).

Bean A and Bean B originate messages and are event driven. In case the required event occurs, the beans send out a notification message.

My transformations are very simple and I do not require the power of Java DSL at all. To summarize, I have the following questions:

1) Considering the above constraints, I do I ensure all routing information, including destination addresses, everything is a part of the camel context file?

2) Are there example I can look at for keeping the routing information completely independent of the java code?

3) How do I ensure Camel does not constantly invoke the originating bean?

4) Does Camel constantly invoke just the originating bean or any bean it sends & messages to irrespective of the position of the bean in the entire messaging queue?

I have run out of options trying various ways to set this up. Any help would be appreciated.

+1  A: 

Read about hiding the middleware on the Camel wiki pages. This allows you to let clients use an interface to send/receive messages but totally unaware of Camel (no Camel API used at all).

Even better consider buying the Camel in Action book and read chapter 14 which talks about this. http://www.manning.com/ibsen/

Save 41% on Manning books: Camel in Action or ActiveMQ in Action. Use code s2941. Expires 6th oct. http://www.manning.com/ibsen/

Claus Ibsen
Thanks, got hold of the book. Chapter 14 looks pretty interesting. Will bug you again if I have any more questions.
smschauhan