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

Reply via email to