Hi Sorry for the late reply by the community.
On Fri, Apr 16, 2010 at 6:22 PM, Steve Bate <b...@technoetic.com> wrote: > > > cmoulliard wrote: >> >> Hi, >> >> Communication with FIX engine is different from a pure client - server >> communication. >> > > Hello, > > I'm the author of QuickFIX/J. I wanted to clarify a few points. As you've > said FIX is different from client/server protocols. In fact, it's not > client/server at all. The initiator/acceptor roles are for creating the > message transport and the session. Once the session is established, all > communication is peer to peer. > Welcome and great that you share your thoughts and views with us. > If I can find some time, I'd like to contribute some changes to the existing > QuickFIX/J component. I'm much more familiar with QuickFIX/J than with Camel > so feel free to tell me if what I'm suggesting is not in the spirit of the > Camel framework. > Oh that would be fantastic. Then we know for sure that it works with QuickFix as its supposed to do. The current implementation is a bit shaky and I think someone like you would be ideal to step up and make it first class integrated with QuickFix. > I'd like to modify the implementation to support both initiator and acceptor > roles in the same component. The required roles can be determined by looking > at the QFJ session-level settings and then an initiator and/or acceptor > connector can be internally created as needed. The message store and message > log implementation can typically be inferred from the settings as well and > created automatically. Initiator sessions must be specified explicitly in > the QFJ settings file. However, QFJ supports dynamically created acceptor > sessions so those may be specified explicitly or created on demand (based on > a validated incoming connection). > > When the component is created, QFJ will initialize itself based on the > settings file. The Camel endpoints will correspond to FIX sessions. These > endpoints would be able to support both producing and/or consuming messages. > I'd also like provide some additional options to specify what categories of > messages to send from the endpoint (application sent/received, admin > sent/received, session events like logon/logout, etc.). By default the > endpoint would only forward application-level received messages. It might be > useful to support receiving messages for all sessions and then using Camel > to route or filter messages based on session ID or some other criteria. > > From the endpoint user perspective, they are just sending and receiving > messages between FIX sessions. Any initiator/acceptor issues are handled by > whoever is configuring the FIX engine through creating the QFJ settings > file. > > Is this a reasonable approache? > Yes sounds like a good plan. Remember Camel is just "syntax sugar". The hard work is in the integration with QuickFix. If you have any issues with Camel let us know. Mostly the Camel component should do is to bind to/from QuickFix to the Camel Exchange which is the carrier of the messages being routed in Camel. > Regards, > > Steve Bate > -- > View this message in context: > http://old.nabble.com/Quickfix-send-receive-messages-in-both-directions-tp27855316p28268960.html > Sent from the Camel - Users mailing list archive at Nabble.com. > > -- Claus Ibsen Apache Camel Committer Author of Camel in Action: http://www.manning.com/ibsen/ Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
