Canonical Setup

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Canonical Setup

Me Coder
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).

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".

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.

Does anyone have a setup handy they can share?

Thanks...


     

Reply | Threaded
Open this post in threaded view
|

Re: Canonical Setup

Charles Moulliard
I propose that you have a look to the spring-integration project which is integrated with Camel as a component now.

http://activemq.apache.org/camel/springintegration.html

According to this approach, you can spring endpoint to send from spring messages and/or consume them from Camel. This approach creates a kind of abstraction that you are looking for. Otherwise, you have to use by example webservices (designed with apache cxf) that you will use between Camel and your web application

Regards,

Charles Moulliard


Me Coder wrote
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).

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".

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.

Does anyone have a setup handy they can share?

Thanks...


     
Apache Committer / Sr. Pr. Consultant at FuseSource.com
Email: [hidden email]
Twitter : @cmoulliard, @fusenews
Blog : http://cmoulliard.blogspot.com
Reply | Threaded
Open this post in threaded view
|

RE: Canonical Setup

Claus Ibsen
In reply to this post by Me Coder
Hi

You can use camel-spring that supports a nice spring XML style configuration where you can use property placeholders etc.

You can also have different spring XML files for environments
- test
- production

Then in your production you can have endpoints and routing using JMS
And in test you can use simpler endpoints such as SEDA.

Since you endpoints is POJO you can use the bean-component to keep your POJO 100% independent of camel.




Med venlig hilsen
 
Claus Ibsen
......................................
Silverbullet
Skovsgårdsvænget 21
8362 Hørning
Tlf. +45 2962 7576
Web: www.silverbullet.dk

-----Original Message-----
From: Coder One [mailto:[hidden email]]
Sent: 6. oktober 2008 21:42
To: [hidden email]
Subject: Canonical Setup

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).

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".

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.

Does anyone have a setup handy they can share?

Thanks...


     

Reply | Threaded
Open this post in threaded view
|

Re: Canonical Setup

jstrachan
In reply to this post by Me Coder
2008/10/6 Coder One <[hidden email]>:
> 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
http://activemq.apache.org/camel/bean-integration.html

you can then use beans to consume messages
http://activemq.apache.org/camel/pojo-consuming.html

and flexibly bind messages to method calls
http://activemq.apache.org/camel/bean-binding.html

> 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.
http://activemq.apache.org/how-to-unit-test-jms-code.html

Then you can switch from dev-to-prod configuration by just changing a
single property value (the brokerURL in the ActiveMQ component)
http://activemq.apache.org/camel/activemq.html

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
--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://open.iona.com