James, 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? Cheers, Dan James.Strachan wrote: > > On 17/10/2007, dmd <[EMAIL PROTECTED]> wrote: >> Hi all, >> >> I saw someone comment on the upcoming integration of Camel into >> ServiceMix, >> http://www.nabble.com/Camel-and-ServiceMix-tf4443716s22882.html. 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... > http://activemq.apache.org/camel/components.html > > to implement different enterprise integration patterns... > http://activemq.apache.org/camel/enterprise-integration-patterns.html > > 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... > http://activemq.apache.org/camel/bean-integration.html > > 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, >> http://activemq.apache.org/camel/bam-example.html, 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. > > http://activemq.apache.org/camel/artix-data-services.html > > -- > James > ------- > http://macstrac.blogspot.com/ > > Open Source SOA > http://open.iona.com > > -- View this message in context: http://www.nabble.com/Camel-based-workflow-tf4638443s22882.html#a13264443 Sent from the Camel - Users mailing list archive at Nabble.com.
