Re: in/out/fault messages discussion

[Guillaume Nodet <gn...@gmail.com>]

On Mon, Feb 4, 2008 at 4:02 PM, James Strachan <ja...@gmail.com> 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 <hi...@hiramchirino.com> 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/