Camel Component Design: Handling InOptionalOut for Consumers?

[Victor NOËL <vi...@linagora.com>]

Hi,

I am implementing a Camel component for the Petals ESB (an 
implementation of the infamous JBI specification ;) and I'm struggling a 
bit with one little design question.

It is happening at the Consumer level (so the code that corresponds to 
injecting an exchange coming from the service bus into a camel route).

We only plan to support the first four message patterns (In*), and for 
InOnly, RobustInOnly or InOut messages, there is no problem: an exchange 
is handled by the Consumer implementation and passed to its processor, 
and then the result is optionally sent back to the service bus with an 
OUT message.

With InOptionalOut, the design question is the following from the point 
of view of the Consumer implementation:
I receive an exchange with an IN, I process the exchange in the processor ;
When the processing is finished, if there is an OUT, I send it back to 
the service bus ;
Now, what should I do if the service that originally sent me this 
exchange decide to sent back a Fault (as defined by the InOptionalOut 
pattern)?

I feel like this question is half-out-of-scope of the purpose of Camel, 
because I think there is nothing to do with such information once it is 
received: a from(...) does return something after the execution of the 
route it is the beginning of, but I don't see it having any impact on 
anything once the route has been executed… could there be some use case 
of Camel where the end of executing the route of a from(...) triggers 
something else?
In that case it would make sense to behave differently if a fault is 
received back in the aforementioned example maybe…

More generally, the same question happens with the acknowledgement that 
should arrive (to the Consumer implementation after it executed the 
route, as before) in response to the sent Out for the InOut pattern: 
should I worry about that acknowledgement arriving and is there anything 
that would be impacted by it?

I thought that maybe Camel developers with experience of writing Camel 
routes would have an opinion on what would be expected (by a route 
designer) to happen in these special cases :)

The actual implementation is already available here: 
https://github.com/petalslink/petals-camel
There is two module, camel-petals is the component implementation I'm 
talking about here, and petals-se-camel is the service bus side of the 
equation: it instantiates the camel context and gives arriving exchanges 
to the consumer implementation.

Thank you!

Victor