camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glattfelder Beat" <>
Subject AW: AW: Symmetric routes
Date Mon, 30 May 2011 13:09:13 GMT

I absolutely agree on your findings, I have been thinking about this as 
well and figured that since you have to set up message / event driven 
processing anyway, the additional complexity in correlating some messages 
to enable a request reply paradigm would not be justified.

What I actually am looking for, is a possibility to reference endpoints in 
camel-spring routes. In Java on can instantiate an endpoint and then use 
it in the from clause - is there a way to do this in spring routes?


PS: please call me Beat, in the old world we sometimes place the
family name first in addresses ;)

-----Ursprüngliche Nachricht-----
Von: Stephen Bate [] 
Gesendet: Montag, 30. Mai 2011 13:24
Betreff: Re: AW: Symmetric routes


I think that in some cases it would make sense to support the InOut MEP for
FIX. Certain pairs of FIX message types are logically a request-reply pair.
Order execution is not in that category because of the multiple asynchrnous
replies, but a FIX OrderStatusRequest could potentially be represented as an
InOut exchange.

On the consumer side, the message would be processed by a synchronous
service (like a status reporting service) and the response would be sent
back to the requesting FIX session.
On the producer side, an InOut message exchange could be supported for FIX
messages that represent request-reply interactions. The behavior would be
similar to using request-reply with JMS. However, it's a little more
complicated in FIX because the correlation key differs between message pairs
and versions of the FIX specification.

I've modified the Quickfix component (locally) to optionally support InOut
for consumers and producers. I created a consumer example that routes InOut
status request messages to a synchronous status reporting service. I've also
created a producer example that receives status requests from a jetty web
component. The web service request is transformed and then routed as an
InOut exchange to a quickfix endpoint. The quickfix reply FIX message is
then transformed to JSON and routed back to the jetty component which
returns it to the web service client.

Although this doesn't remove the duplication in the example you provided, it
might be useful in other situations.



On 5/30/11 6:22 AM, "Glattfelder Beat" <>

> Hi,
> one important thing to take into consideration is the asynchronous nature of
> FIX messaging. I am not sure how an InOut exchange would enable that.
> A typical interaction would be as such:
> ----> order request
> <---- order ack
> <----  partial execution
> ...
> <---- completed execution
> So this would be something like an in exchange followed by several out
> exchanges - 
> if there is such a thing.
> Another aspect to consider is the bidirectional nature of the pipeline, i.e.
> the message needs transformation in both directions.
> Could these requirements be met by adding in-out capability to the quickfixj
> Component?
> Cheers,
> Beat;
> -----Ursprüngliche Nachricht-----
> Von: Ashwin Karpe []
> Gesendet: Freitag, 27. Mai 2011 15:53
> An:
> Betreff: Re: Symmetric routes
> Hi,
> I did a little digging and it turns out that the QuickfixJ Converter creates
> an in-only exchange... Not sure why, but then again I am not very conversant
> with Quickfix and the message exchange patterns it supports.
> If the exchange can be made to be an in-out exchange and the the Quickfix
> event listener can also send responses to the endpoint, then you will not
> need to write the second route.
> Camel is fully capable of sending back responses (as we do in CXF) when
> using in-out exchanges. The camel-quickfix component does not support this.
> If you would like to have this capability and it is a valid usecase per
> quickfix message exchange patterns, I would be happen to add a Jira issue
> for the same.
> Can you please let men know.
> Cheers,
> Ashwin...
> -----
> ---------------------------------------------------------
> Ashwin Karpe
> Apache Camel Committer & Sr Principal Consultant
> FUSESource (a Progress Software Corporation subsidiary)
> Blog:
> CamelOne 2011:
> ---------------------------------------------------------

Bitte oeffnen Sie nicht jedes Mail-/Attachement. Achten Sie auf den Absender und beachten
Sie die Sprache in der das Mail erstellt wurde. Sollten Sie z.B. ein Mail erhalten von einem
Absender der normalerweise Mails in Deutsch verfasst, dann seien Sie doppelt vorsichtig wenn
es Englisch ist.

Diese Nachricht ist ausschliesslich für den obgenannten Empfaenger bestimmt. Sollten Sie
diese Nachricht irrtuemlich erhalten haben, benachrichtigen Sie uns bitte und zerstoeren Sie
diese sofort ohne in irgendeiner Weise davon Gebrauch zu machen. Da elektronische Kommunikation
ohne Ihr oder unser Wissen eingesehen, gefaelscht oder veraendert werden kann, lehnen wir
jede Verantwortung für die Geheimhaltung und Unversehrtheit dieser Nachricht ab.

This message is confidential and only for the use of the above named recipient. Should you
have received this message in error, please contact us and destroy it immediately without
using it in any way. Since electronic communication can be viewed, forged, or altered without
your or our knowledge, we decline any responsibility for the confidentiality or unaltered
content of this message. 

View raw message