Glattfelder, 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. Regards, Steve On 5/30/11 6:22 AM, "Glattfelder Beat" <[email protected]> wrote: > 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 [mailto:[email protected]] > Gesendet: Freitag, 27. Mai 2011 15:53 > An: [email protected] > 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) > http://fusesource.com > > Blog: http://opensourceknowledge.blogspot.com > CamelOne 2011: http://fusesource.com/camel2011 > ---------------------------------------------------------
