camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: Camel based workflow
Date Wed, 17 Oct 2007 13:35:05 GMT
On 17/10/2007, dmd <> wrote:
> Hi all,
> I saw someone comment on the upcoming integration of Camel into ServiceMix,
>  I am
> curious how Camel compares to Apache ODE (if at all).

>From a high level, ODE is an orchestration engine; using a persistent
model of business processes with steps and state.

Camel is primarily a routing and integration engine; integrating
endpoints together using routing rules with different transports...

to implement different enterprise integration patterns...

So they have kinda different focusses; ODE focusses on creating an
executable stateful business model; Camel focusses on integrating
anything to anything in a frequently stateless way using EIP.

Both could be used together; e.g. Camel could route different
transports together and feed them into an ODE business process.

> For some background, here's the problem I need to solve.  I am building an
> order execution system, which receives some kind of complex (financial)
> transaction from a user, and then must talk to several endpoints (such as
> several exchanges) in order to execute it.  The workflow is asynchronous,
> can have exception cases, etc.  And of course it must be fault tolerant, in
> the sense that if the execution engine, or an exchange gateway, crashes, it
> must be able to restart and retrieve it's state from some durable
> transactional store (e.g. RDBMS) and get back on track.

> ODE seems to be able to do what I need.

If you were to use ODE then you'd probably write services & WSDLs then
write a BPEL to describe the orchestration; of how messages flow from
the endpoints to the process etc.

Camel tends to focus on binding endpoints (like transports) to beans &
components; so each service in the process would just be a POJO thats
bound to some JMS endpoint or whatever. In the Camel approach its up
to a specific bean to do whatever state management it wants; rather
than there being a central, generic business process model. More
detail of how Camel binds to beans here...

You could use either approach really; whatever seems most natural to you.

What I would say is that these days, middleware and infrastructure
should be mostly invisible apart from maybe a few annotations here and
there. i.e. I'd recommend you write most of your services as just
POJOs then bind them to whatever middleware you're using (say web
services or using Camel to bind JMS messages to bean methods or

>  However, I am looking into Camel
> because it's nicely integrated with ActiveMQ, which is being used as the
> transport between my services, and it seems more lightweight.  However, I
> can't tell if it's powerful enough, or expressive enough to solve this
> problem with.

In Camel for example, you could write a bean to represent your
business logic, then create proxies for services for remote services
that are bound to a JMS queue; then your logic and code is just
regular Java

I guess the place to start is - how do you want to design and
implement your business process? In BPEL - if so ODE's what you want.
If its POJOs bound to message queues (maybe with some content based
routing or transformation) then Camel might be better.

> I did look at the BAM example,
>, but so far the bulb has
> not lit up.


So the BAM stuff is more like the inverse of ODE. Imagine you have a
bunch of systems in your company that are already integrated together.
So system A generates events that are sent via some transport to
system B which also has some kind of output. BAM is all about
monitoring an existing process - something which already exists in
some form which might be Java code, BPEL, duct tape, carrier pigeons,
humans dual-typing - whatever.

The basic concept is rather like having probes you add into an
existing electricity circuit in a building; to check things are still
flowing as they should. Its not really meant to be the flow - its more
to monitor an existing flow to check its working as expected.

So BAM kinda reverse engineers an existing business process by
monitoring messages and correlating them together - by being outside
of the flow but just monitoring business events.

ODE / BPEL are the other way around - they are for creating new
business process where they are the real business process in the
middle of the flow.

If you are using ODE/BPEL then you'd probably use your ODE/BPEL engine
to monitor processes. However if they are legacy systems wired
together somehow; then BAM comes in.

> Lastly, is it the case that the payload of messages must be XML in order to
> be interpretable by Camel rules, or could I send serialized Java objects
> and/or FIX messages?

It can be any POJO for the payloads. Indeed we support Artix Data
Services for the payloads; so you can use a commercial
FIX/SWIFT/FpML/FixML handling library for marshalling and
unmarshalling messages, transforming between data formats and doing
XQuery routing on POJOs etc.


Open Source SOA

View raw message