2009/7/10 James Strachan <james.strac...@gmail.com>:
> 2009/7/10 Roman Kalukiewicz <roman.kalukiew...@gmail.com>:
>> 2009/7/10 Claus Ibsen <claus.ib...@gmail.com>:
>>> Now that we have opened the box with IN OUT FAULT api changes I would
>>> like to point out issues related to OUT
>>>
>>> Given this code:
>>>
>>> Exchange out = template.send("direct:start", new Processor() {
>>> public void process(Exchange exchange) throws Exception {
>>> exchange.getIn().setBody("Hello World");
>>> exchange.setPattern(ExchangePattern.InOnly);
>>> }
>>> });
>>>
>>> And this route:
>>>
>>> from("direct:start").transform(constant("Bye World"));
>>>
>>> What would the expected output of Exchange be?
>>>
>>> The current code asserts this:
>>>
>>> assertEquals("Hello World", out.getIn().getBody());
>>> assertEquals("Bye World", out.getOut().getBody());
>>>
>>> That looks fair. The route transforms (= set an OUT body) and we
>>> preserve the original IN.
>>> But the exchange pattern was InOnly but we get data in OUT also? Camel
>>> does not adhere strictly to the patterns.
>>
>> This is another point I would like to see changed - exchange patterns.
>>
>> My personal impression is that exchange shouldn't have pattern at all.
>> When I create a flow I (usually) know at design time if I want given
>> endpoint to operate as InOnly or InOut. I really cannot imagine a
>> situation, when I design a flow and I don't really know if it should
>> operate in InOnly or in InOut mode, especially that sometimes it
>> changes a lot in the behavior of the flow.
>>
>> I would like to see it as an endpoint property rather than exchange
>> property especially, that in majority of endpoints the pattern is
>> ignored anyway.
>>
>> My proposal: Remove MEP concept at all from Camel API. Leave it for
>> specific components.
>
> So what about consuming a JMS message which could be an InOnly or
> InOut based on the presence of a JMSReplyTo header?
>
> Or invoking a (say) JMS endpoint from application code using either
> InOnly or InOut where the client decides based (say) an @InOnly
> annotation on a Java method when doing Spring Remoting or a different
> method on the ProducerTemplate in application code?
>
> The endpoint cannot always decide by itself the MEP; sometimes the
> client or the message it receives can decide it. So I think the MEP
> needs to be associated with the Exchange.
OK - My fault (don't confuse it with FAULT discussion ;)). I would
rather propose MEP to be specified on Producer/Consumer. In fact Camel
2.0 somehow did it by introducing to(Pattern, Endpoint) construct, so
MEPs are specified on a producer - not on an exchange (at least from
logical point of view).
Moreover the fact, that you sent InOut JMS message to an endpoint,
doesn't really mean, that it should be processed this way in Camel -
we even have "disableReplyTo" option on the endpoint, so we already
have a kind of MEP control on the endpoint level.
So this is the client or server, who should decide how MEPs are used
(if they make sense for given protocol). But there is no need to
PROPAGATE it with the exchange, because then the decision made by
client in one endpoint influences the behavior of totally different
endpoint.
So two facts:
1) MEPs are used in just few components, so I don't think they should
be in Camel API - they could be customized at producer/consumer level
2) We already have some options that affect MEPs on endpoint level
like "disableReplyTo".
Because of this we could have:
from("direct:start").
to("jms:in-queue?mep=InOut")
as it makes sense in case of JMS - then we know what will happen here.
Now when I see:
from("direct:start").
to("jms:in-queue")
I don't really know if my message is affected or not. Will I wait for
some response, or not. It simply depends on MEP I receive from
"direct:start".
>> My impression is that there are more common things that could be
>> included into API than MEP, like timeout concept. I don't propose
>> timeout on API level, but definitely it is more useful and common than
>> MEP.
>
> Timeouts are really useful for InOuts! Something we might want to add
> - or at least have standard header/properties on the exchange?
Definitely agree.
>> Then (if we agree that OUT is needed) everything creates OUT always -
>> this way we are consistent and no guesses are needed. Moreover if we
>> agree that everything creates OUT then everything can operate on IN
>> the same way. What you can always do in your code is
>>
>> Object in = exchange.getMessage().getBody();
>> exchange.getMessage().setBody(out);
>>
>> This way IF YOU NEED, you can have your IN message in the code, but it
>> doesn't spoil an API.
>
> Not sure how you'd access the in and out together after the out had
> been modified in some way?
I have a reference to the IN message here (or the old message if we
decide to have only one). I can do whatever I want with it as it is a
variable - i don't really have to have it referenced from the exchange
itself.
Roman
