Steve, 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? Cheers, Beat PS: please call me Beat, in the old world we sometimes place the family name first in addresses ;) -----Ursprüngliche Nachricht----- Von: Stephen Bate [mailto:[email protected]] Gesendet: Montag, 30. Mai 2011 13:24 An: [email protected] Betreff: Re: AW: Symmetric routes 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 > --------------------------------------------------------- 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.
