BTW thanks to everyone's thoughts on this thread; keep 'em coming. (I guess it should have been on camel-dev but never mind :)...
On 01/02/2008, Hiram Chirino <[EMAIL PROTECTED]> wrote: > I personally would like to get rid of the Fault message. It should be > possible ti interpret the output message as a Fault or interpret an > Exception as Fault. Having an exception, a fault, and an output > message be all valid outputs of a processor makes creating a DSL to > handle all those cases MUCH more complex. Agreed. Maybe the OUT v Fault is kinda meaningless and is more a kinda helper method on a message. Something like exchange.isFault() or exchange.getOut().isFault() etc. Certainly from the DSL its kinda meaningless currently to be able to set the IN versus the OUT messages etc (thats a bit of legacy DSL from the early days of Camel when a route was kinda an interceptor - we should remove that I think...). I'm still digesting this thread; I'm not yet sure what I think so far but I thought I'd throw some other random thoughts into the mix. I hit an issue today with a transformation that I'd written as a Processor that wanted to spit out multiple OUT messages. Now you could argue, well the transformation should have some kinda ProducerTemplate or whatever so it could send multiple messages out of itself. Though one thing I kinda like about a Processor is it doesn't need to care about where the output goes; it just makes an OUT message and the route it is invoked from takes care of the routing. So I've been wondering if an Exchange should have one IN and zero to many OUT messages so that the contract of a Processor (or Transformer) is to make 0..N OUT messages that the router its inside then routes to some place. If a more complex Transformer wants to start sending messages to specific destinations itself, thats cool too - but most transformations or processors don't really care where the output goes - thats up to the caller to decide. In my mind the Exchange was generally the object that owns the context in which a message is being processed and some output (if any) is being generated. So a Processor in generally should be able to access the input message which caused it to be invoked - get access to the Endpoint its being invoked from even - plus the CamelContext its living inside. So I guess another thing we could consider is, should I be able to see previous Exchange instances which caused this Exchange to be invoked? e.g. in some pipeline spanning patterns and transports, could I look back at the history of exchanges which caused me to be invoked? BTW yet another detail is, we used generics in the definition of an Exchange, Endpoint, Component, Producer, Consumer. In hindsight this is a bit of a mistake I think; I'd like to see the generics removed from that. As it means we have to internally copy exchanges whenever we send them (as the Producer usually casts it to a T rather than an Exchange). So I think its definitely worth revisiting what is an Exchange and what should its contract be... I'm starting to wonder if its just a context for the exchange (so you can access the IN) and a place in which to register one or more OUT messages? I still need to ponder Roman's various mails and patch though... Keep the thoughts coming though! :) -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://open.iona.com
