camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: Canonical Setup
Date Tue, 07 Oct 2008 08:47:06 GMT
2008/10/6 Coder One <>:
> I have read through "all" camel docs and managed a few simple setup, but I can't figure
the below "canonical" setup:
> WebApp (uses Srping and starting point to send data to all endpoints)
> EndPoint1 ... EndPoint-n (all pojos, need to keep them as pojos and independent of camel
as much as possible).

Have a look at the bean integration; it allows you to use beans as
endpoints or as Message Translators within routes

you can then use beans to consume messages

and flexibly bind messages to method calls

> Between the WebApp and the EndPoints, in a production system, we will probably use JMS.
 In the dev environment, we'd like WebApp and EndPoint to exist in the WebApp "process context".

BTW one approach is to use JMS everywhere, but when testing use an
in-memory JMS broker with no persistence - which effectively gives you
in-memory SEDA communication within the JVM while still testing the
JMS semantics you wanna use in production.

Then you can switch from dev-to-prod configuration by just changing a
single property value (the brokerURL in the ActiveMQ component)

which avoids you having 2 totally different configurations to maintain.

> How do I go about with a setup to enable fast boot and test in the dev environment and
at the same time I can achieve the prod architecture with minimal configuration changes?
> In other words, I need to keep the communications between the WebApp and its EndPoints
as independent of the underlying transport and isolate Camel API classes as much as possible.

The Bean Integration is what you're looking for - your business
logic/endpoints are just beans with no Camel APIs in there at all -
other than maybe some annotations to help the binding

Open Source Integration

View raw message