You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Hiram Chirino <hi...@hiramchirino.com> on 2008/02/01 19:15:04 UTC
Re: in/out/fault messages discussion
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.
Just my 2 cents.
Regards,
Hiram
On Jan 31, 2008 1:18 PM, Roman Kalukiewicz <ro...@gmail.com> wrote:
> 2008/1/31, Hadrian Zbarcea <hz...@gmail.com>:
> > Actually to Guillaume's point, I am strongly in favor of keeping the
> > input. And to be honest, I like the model the way it is, for many
> > reasons. One is that the model is very intuitive for people familiar
> > with certain standards, myself included, and the emtpy chairs don't
> > bother me. If I understand correctly you are not claiming that there
> > are features that the current model (vs yours) cannot support, just
> > that your proposal will make it clearer.
>
> That is right. I believe that current model could be harder to
> implement all different scenarios, that we don't have to think about
> in mine, but everything could be done in the current one (with 3
> messages available you can for sure implement everything that can be
> done with 1, right? ;) ). I even believe that I was able to show, that
> my solution also can handle all features we need.
>
> > Well, de gustibus non est disputandum. If you really feel strongly
> > about that, a vote is the way to settle it :).
>
> This is what I say from the very beginning. I was simply curious if my
> impressions are common. But the fact is, that if I want camel to
> change in this direction, I need creators of camel to be convinced to
> this direction and I cannot do it alone (or I have to think about my
> own one-message-branch ;) ). It looks that you are not really
> convinced ;)
>
> Anyway thank you for all your feedback
> Roman
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://open.iona.com
Re: in/out/fault messages discussion
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Hi, Gary,
I don't think that's what James has in mind :).
Based on James' post I would also like to amend one of my previous
posts in this thread :). I was saying that I like it the way it is,
with a differentiation made between in/out/exception. I think we
agree at this point, from Hiram's comment that a distinction between
out and fault doesnt make much sense (it may in some for some
components, but then they'd be responsible to attach a flag to the out
to qualify its semantics).
So I believe James suggested somthing like a stack (or list) in which
first in is the IN, and instead of creating new exchanges we would
just push a new out on the stack. A producer would just send the last
message on the stack as an IN and if there's any out it pushes it on
the stack. That way we'll have the whole message history. I am not
sure how this scales for large messages, so we might want to make this
optional. Maybe keep all the messages and drop just the large
bodies, preserve the headers, that may contain useful metadata, such
as timestamps for measuring SLAs, etc. The IN at the bottom of the
stack should stay, I guess.
How does that sound?
Hadrian
On Feb 13, 2008, at 10:33 AM, gtully wrote:
>
>> 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?
>>
> Would N out messages result in N exchanges for the next hop?
>
> For WS-Addressing, where the original 'in' message is important,
> would it
> makes sense to stash the (important) in message in the exchange as a
> property. The pipeline will propagate exchange properties so the
> important
> in message will be visible from the pipeline to those who care.
> This may alleviate the need to traverse the set of chained exchanges
> to get
> a handle on the original in message.
>
> --
> View this message in context: http://www.nabble.com/in-out-fault-messages-discussion-tp14170013s22882p15459603.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
Re: in/out/fault messages discussion
Posted by gtully <ga...@gmail.com>.
>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?
>
Would N out messages result in N exchanges for the next hop?
For WS-Addressing, where the original 'in' message is important, would it
makes sense to stash the (important) in message in the exchange as a
property. The pipeline will propagate exchange properties so the important
in message will be visible from the pipeline to those who care.
This may alleviate the need to traverse the set of chained exchanges to get
a handle on the original in message.
--
View this message in context: http://www.nabble.com/in-out-fault-messages-discussion-tp14170013s22882p15459603.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: in/out/fault messages discussion
Posted by 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/
Re: in/out/fault messages discussion
Posted by James Strachan <ja...@gmail.com>.
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.
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
Re: in/out/fault messages discussion
Posted by Hadrian Zbarcea <hz...@gmail.com>.
This totally makes sense, especially given the fact that many
components don't make that distinction.
I created camel-316 https://issues.apache.org/activemq/browse/CAMEL-316
Cheers
hadrian
On Feb 1, 2008, at 1:15 PM, Hiram Chirino 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.
>
> Just my 2 cents.
>
> Regards,
> Hiram
>
> On Jan 31, 2008 1:18 PM, Roman Kalukiewicz <roman.kalukiewicz@gmail.com
> > wrote:
>> 2008/1/31, Hadrian Zbarcea <hz...@gmail.com>:
>>> Actually to Guillaume's point, I am strongly in favor of keeping the
>>> input. And to be honest, I like the model the way it is, for many
>>> reasons. One is that the model is very intuitive for people
>>> familiar
>>> with certain standards, myself included, and the emtpy chairs don't
>>> bother me. If I understand correctly you are not claiming that
>>> there
>>> are features that the current model (vs yours) cannot support, just
>>> that your proposal will make it clearer.
>>
>> That is right. I believe that current model could be harder to
>> implement all different scenarios, that we don't have to think about
>> in mine, but everything could be done in the current one (with 3
>> messages available you can for sure implement everything that can be
>> done with 1, right? ;) ). I even believe that I was able to show,
>> that
>> my solution also can handle all features we need.
>>
>>> Well, de gustibus non est disputandum. If you really feel strongly
>>> about that, a vote is the way to settle it :).
>>
>> This is what I say from the very beginning. I was simply curious if
>> my
>> impressions are common. But the fact is, that if I want camel to
>> change in this direction, I need creators of camel to be convinced to
>> this direction and I cannot do it alone (or I have to think about my
>> own one-message-branch ;) ). It looks that you are not really
>> convinced ;)
>>
>> Anyway thank you for all your feedback
>> Roman
>>
>
>
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
> Open Source SOA
> http://open.iona.com