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.
> 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?
> 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?
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/
