Re: Quickfix send/receive messages in both directions

[Steve Bate <ba...@technoetic.com>]

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.

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.

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?

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.

Re: Quickfix send/receive messages in both directions

[Claus Ibsen <cl...@gmail.com>]

Hi

Sorry for the late reply by the community.


On Fri, Apr 16, 2010 at 6:22 PM, Steve Bate <ba...@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