On Mon, May 30, 2011 at 3:09 PM, Glattfelder Beat <[email protected]> wrote: > 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? >
Sure something like this: <endpoint id="myEndpoint" uri="blah"/> <route> <from ref="myEndpoint"/> ... The ref will lookup an id in the spring registry, so you can also use a spring bean style if you like <bean id="myEndpoint" class="...."> ... </bean> > 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. > -- Claus Ibsen ----------------- FuseSource Email: [email protected] Web: http://fusesource.com CamelOne 2011: http://fusesource.com/camelone2011/ Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
