On Mon, Feb 4, 2008 at 4:02 PM, James Strachan <[EMAIL PROTECTED]> wrote: > 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.
Fwiw, wsdl2 defines a MEP (In-Optional-Out) where at some point, the exchange can contains a In, a Out and a Fault message. Imho, this is not something we need to support. > > 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. I'm not sure about that. if the exchange does not formalize the a set of messages being somehow an "invocation", I'm not sure what the purpose of the Exchange is. See below. > > > 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? I think this would be very usefull to analyze what happens. > > 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? We could also use a property pointing to a context (instead of an exchange, the context containing some generic information, usually static), plus a property to a related message (it could be the IN message, or maybe simply the message that is the cause for this message). I think we could drop the notion of exchange, and go for context + properties, which may simplify the api. > > 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 > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/
