camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dmd <>
Subject Re: Camel based workflow
Date Wed, 17 Oct 2007 22:43:24 GMT


Thank you for the clarifications!  That will be very helpful.

So, given your observations, and further reading on ODE, I am inclined to go
for the model of using Java beans for the business logic components and
Camel to wire it up.

Regarding the payloads and predicates, I'm still not 100% clear on which
predicate languages can be used with what payload types.  For instance, if I
use a POJO as the payload, what kind of predicate can I use on it?


James.Strachan wrote:
> 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
> whatever).
>>  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.
> -- 
> James
> -------
> Open Source SOA

View this message in context:
Sent from the Camel - Users mailing list archive at

View raw message