You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by grabiarz <gr...@gmail.com> on 2010/03/10 21:24:29 UTC
Quickfix send/receive messages in both directions
I wanted to use camel and Quickfix combo in my project and I noticed this
warning (on http://camel.apache.org/quickfix.html) :
Warning: You cannot use a quickfix engine to send or receive messages in
both direction as the FIX protocol handle logon/logout sessions with
heartbeat messages which are send to verify if the server or client is still
alive in only one direction.
I'm not quite sure how to understand it as I managed to get camel to forward
a message from one endpoint to another like this:
from("quickfix-server:server.cfg").to("quickfix-client:client.cfg");
(Listen for incoming fix messages and then forward them to a different
system)
Does the warning mean I would not be able to return an "ACK" type message to
whoever sent a message to my 'server' unless I configured another endpoint
to point back to them and an endpoint to target system I want to forward to?
--
View this message in context: http://old.nabble.com/Quickfix-send-receive-messages-in-both-directions-tp27855316p27855316.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Quickfix send/receive messages in both directions
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Its Charles Moulliard who wrote that wiki page AFAIR.
Maybe he can tell why.
As said we would love someone to help with the camel-quickfix. So if
you have the time to help with both the wiki and the component that
would be great.
On Wed, Mar 10, 2010 at 9:24 PM, grabiarz <gr...@gmail.com> wrote:
>
> I wanted to use camel and Quickfix combo in my project and I noticed this
> warning (on http://camel.apache.org/quickfix.html) :
>
> Warning: You cannot use a quickfix engine to send or receive messages in
> both direction as the FIX protocol handle logon/logout sessions with
> heartbeat messages which are send to verify if the server or client is still
> alive in only one direction.
>
> I'm not quite sure how to understand it as I managed to get camel to forward
> a message from one endpoint to another like this:
>
> from("quickfix-server:server.cfg").to("quickfix-client:client.cfg");
>
> (Listen for incoming fix messages and then forward them to a different
> system)
>
> Does the warning mean I would not be able to return an "ACK" type message to
> whoever sent a message to my 'server' unless I configured another endpoint
> to point back to them and an endpoint to target system I want to forward to?
> --
> View this message in context: http://old.nabble.com/Quickfix-send-receive-messages-in-both-directions-tp27855316p27855316.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
Re: Quickfix send/receive messages in both directions
Posted by kostabanderas <ko...@gmail.com>.
cmoulliard,
Thanks for the reply! Let me try to explain the problem again. FIX protocol
is session based where client is the initiator. That is:
client ------> server (IP:port)
never:
client (IP:port) <------- server
As you say, after client makes the connection to server, a session is
established. So, we practically have something like this:
client ----------------> server (IP:port)
| ---------> |
| <--------- |
i.e. both client and server can send messages (whether heartbeat or real
business messages) through the tunnel (what I tried to draw with |). This is
not analogous with jetty/http you mentioned - jetty/http is really
client-server and you actually listen with jetty, but connect with http -
but rarely to the client, mostly to other web sites to gather data.
With Quickfix, you don't connect from a server side - you use the tunnel
initiated by the client to both send and receive messages. This is similar
to jetty - a client requests some path on your server (e.g.
myserver.example.com/abc/def), you create a jetty server there and anything
for that URL goes to your bean at the end. The important thing here is that
whatever your bean returns goes back, but HTTP protocol is stateless and
closes the tunnel. In FIX it's very similar - you just continue using the
same tunnel. In both cases, the client is the only initiator - with jetty,
you don't say "connect to client", you just say "return the data to the
client using the already established tunnel".
What I don't understand is: when you say
from(quickfixserver).to(quickfixclient), you actually say - receive from
quickfixserver and send to quickfixclient. You configure quickfixserver as
acceptor and quickfixclient as initiator. Making quickfixserver an acceptor
is OK, however quickfixserver cannot be an initiator - on the server side,
you cannot initiate any connections - you just use the tunnel initiated by
the client to send FIX messages back.
Is there an example of something like the above?
Let me give you an example of what is needed:
- Say you have a client
- Client initiates the connection to server at some IP:port
- Server accepts the connection, thus creating a tunnel they will use going
forward
- Client can send messages and server can accept them (I have this part
working)
- After the connection is established, server sends a FIX message (e.g. a
test request or any other type) each 10 seconds to the client using the
established tunnel
- Server does not know anything about the client, specifically there is no
IP:port on the client side that server can even try to connect (for
simplicity, let's assume the client is behind a very restrictive firewall
that only allows client to initiate traffic)
- The question is - how do I reuse the tunnel I made above for this purpose?
How would the above be configured? I looked at all the examples, however
none of them were clear enough to me to make the above - any help would be
appreciated.
Thanks!
--
View this message in context: http://old.nabble.com/Quickfix-send-receive-messages-in-both-directions-tp27855316p27999544.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Quickfix send/receive messages in both directions
Posted by Charles Moulliard <cm...@gmail.com>.
Hi Kostabanderas,
You are not doing something wrong. FIX Protocol has been designed in a non
client - server mode but as session created over HTTP protocol allowing to
send incoming OR outgoing messages. More info here :
http://www.fixprotocol.org/specifications/
1. Is it fair to say that Camel quickFix Component handles ONLY the "session
- level" messages (=logon, logout, heartbeat, testRequest...) ?
Camel component, when the session is established will receive all the
"technical" messages (logon,logout, heartbeat, ...) but business too
depending if you are connected to a FIX server 4.1, 4.2, ...
2. Is it anyhow possible to implement a "client - server" architecture using
this component? Meaning to be able to respond to messages that get to the
quickFixAcceptor? By looking at quickFix dist examples the response is sent
over the session.send(response). Is it possible to achieve similar behavior
using a Camel component? I didn't get the chance to investigate Mina yet but
maybe using plain Mina to send to the socket (just to make sure to use the
same SessionId, if applicable at all)??
I don't think that this is the good solution but you can receive messages
from quickfix:client, process them and finally resend them using another
quickfix:server endpoint but the parameters (session, ...) will be
different. To send messages to the same endpoint, your route must be defined
as InOut. So after processing the messages, validating it and so on, you can
send the ACK to the FIX server through the same endpoint
You can compare the quickFix compare with camel-jetty or camel-http
componants. To send HTTP messages (or produce) to an HTTP Server, you will
use the component camel-http like this in your route
(from().to(bean:process).to(http://). When you want to process HTTP request
messages (=consume) you will use a camel-jetty component. You will never
use camel-http or camel-jetty to both consume or produce using the same
endpoints
Kind regards,
Charles Moulliard
Senior Enterprise Architect
Apache Camel Committer
*****************************
blog : http://cmoulliard.blogspot.com
twitter : http://twitter.com/cmoulliard
Linkedlin : http://www.linkedin.com/in/charlesmoulliard
Apache Camel Group :
http://www.linkedin.com/groups?home=&gid=2447439&trk=anet_ug_hm
On Fri, Mar 19, 2010 at 5:47 PM, kostabanderas <ko...@gmail.com>wrote:
>
> Hi all,
>
> I'm still confused about this. I started investigating the quickFix
> component and I noticed this behavior but was sure that I was doing
> something wrong :)
> So, a couple of questions:
>
> 1. Is it fair to say that Camel quickFix Component handles ONLY the
> "session
> - level" messages (=logon, logout, heartbeat, testRequest...)?
> 2. Is it anyhow possible to implement a "client - server" architecture
> using
> this component? Meaning to be able to respond to messages that get to the
> quickFixAcceptor? By looking at quickFix dist examples the response is sent
> over the session.send(response). Is it possible to achieve similar behavior
> using a Camel component? I didn't get the chance to investigate Mina yet
> but
> maybe using plain Mina to send to the socket (just to make sure to use the
> same SessionId, if applicable at all)??
> This from(quickfixserver).to(quickfixclient) configuration seems to be
> applicable only if I want to use fixClient and fixServer inside the same
> app. Is that fair to say? Can I anyhow make the client and server separate
> apps not aware of each other?
> 3. Is it possible to reconfigure these "session - level" message handlers?
> For example, how to decide who can logon to my server?
>
>
>
> cmoulliard wrote:
> >
> > Hi,
> >
> > Communication with FIX engine is different from a pure client - server
> > communication. AS mentioned in the documentation the quickfix engine that
> > we
> > use behind the camel-quickfix endpoint will establish a communication
> with
> > a
> > FIX Server and FIX messages will be exchanged regularly (=hearbeat,
> logon,
> > logout) to keep the communication alive. So this is not a true socket
> > channel created between the two partners but a communication channel. To
> > send messages to FIX server you must use the quickfix-client even if FIX
> > will provide you feedback on the messages exchanged and to receive from a
> > FIX server messages (as a client), you to use the other endpoint.
> >
> > So you can use from(quickfixserver).to(quickfixclient) otherwise you will
> > resend messages receive through a FIX session to another FIX server with
> > same sesssion id.
> >
> > Kind regards
> > Charles Moulliard
> > Senior Enterprise Architect
> > Apache Camel Committer
> >
> > *****************************
> > blog : http://cmoulliard.blogspot.com
> > twitter : http://twitter.com/cmoulliard
> > Linkedlin : http://www.linkedin.com/in/charlesmoulliard
> >
> > Apache Camel Group :
> > http://www.linkedin.com/groups?home=&gid=2447439&trk=anet_ug_hm
> >
> >
> > On Wed, Mar 10, 2010 at 9:24 PM, grabiarz <gr...@gmail.com> wrote:
> >
> >>
> >> I wanted to use camel and Quickfix combo in my project and I noticed
> this
> >> warning (on http://camel.apache.org/quickfix.html) :
> >>
> >> Warning: You cannot use a quickfix engine to send or receive messages in
> >> both direction as the FIX protocol handle logon/logout sessions with
> >> heartbeat messages which are send to verify if the server or client is
> >> still
> >> alive in only one direction.
> >>
> >> I'm not quite sure how to understand it as I managed to get camel to
> >> forward
> >> a message from one endpoint to another like this:
> >>
> >> from("quickfix-server:server.cfg").to("quickfix-client:client.cfg");
> >>
> >> (Listen for incoming fix messages and then forward them to a different
> >> system)
> >>
> >> Does the warning mean I would not be able to return an "ACK" type
> message
> >> to
> >> whoever sent a message to my 'server' unless I configured another
> >> endpoint
> >> to point back to them and an endpoint to target system I want to forward
> >> to?
> >> --
> >> View this message in context:
> >>
> http://old.nabble.com/Quickfix-send-receive-messages-in-both-directions-tp27855316p27855316.html
> >> Sent from the Camel - Users mailing list archive at Nabble.com.
> >>
> >>
> >
> >
> > -----
> > Charles Moulliard
> > SOA Architect
> >
> > My Blog : http://cmoulliard.blogspot.com/
> >
>
> --
> View this message in context:
> http://old.nabble.com/Quickfix-send-receive-messages-in-both-directions-tp27855316p27950996.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
Re: Quickfix send/receive messages in both directions
Posted by kostabanderas <ko...@gmail.com>.
Hi all,
I'm still confused about this. I started investigating the quickFix
component and I noticed this behavior but was sure that I was doing
something wrong :)
So, a couple of questions:
1. Is it fair to say that Camel quickFix Component handles ONLY the "session
- level" messages (=logon, logout, heartbeat, testRequest...)?
2. Is it anyhow possible to implement a "client - server" architecture using
this component? Meaning to be able to respond to messages that get to the
quickFixAcceptor? By looking at quickFix dist examples the response is sent
over the session.send(response). Is it possible to achieve similar behavior
using a Camel component? I didn't get the chance to investigate Mina yet but
maybe using plain Mina to send to the socket (just to make sure to use the
same SessionId, if applicable at all)??
This from(quickfixserver).to(quickfixclient) configuration seems to be
applicable only if I want to use fixClient and fixServer inside the same
app. Is that fair to say? Can I anyhow make the client and server separate
apps not aware of each other?
3. Is it possible to reconfigure these "session - level" message handlers?
For example, how to decide who can logon to my server?
cmoulliard wrote:
>
> Hi,
>
> Communication with FIX engine is different from a pure client - server
> communication. AS mentioned in the documentation the quickfix engine that
> we
> use behind the camel-quickfix endpoint will establish a communication with
> a
> FIX Server and FIX messages will be exchanged regularly (=hearbeat, logon,
> logout) to keep the communication alive. So this is not a true socket
> channel created between the two partners but a communication channel. To
> send messages to FIX server you must use the quickfix-client even if FIX
> will provide you feedback on the messages exchanged and to receive from a
> FIX server messages (as a client), you to use the other endpoint.
>
> So you can use from(quickfixserver).to(quickfixclient) otherwise you will
> resend messages receive through a FIX session to another FIX server with
> same sesssion id.
>
> Kind regards
> Charles Moulliard
> Senior Enterprise Architect
> Apache Camel Committer
>
> *****************************
> blog : http://cmoulliard.blogspot.com
> twitter : http://twitter.com/cmoulliard
> Linkedlin : http://www.linkedin.com/in/charlesmoulliard
>
> Apache Camel Group :
> http://www.linkedin.com/groups?home=&gid=2447439&trk=anet_ug_hm
>
>
> On Wed, Mar 10, 2010 at 9:24 PM, grabiarz <gr...@gmail.com> wrote:
>
>>
>> I wanted to use camel and Quickfix combo in my project and I noticed this
>> warning (on http://camel.apache.org/quickfix.html) :
>>
>> Warning: You cannot use a quickfix engine to send or receive messages in
>> both direction as the FIX protocol handle logon/logout sessions with
>> heartbeat messages which are send to verify if the server or client is
>> still
>> alive in only one direction.
>>
>> I'm not quite sure how to understand it as I managed to get camel to
>> forward
>> a message from one endpoint to another like this:
>>
>> from("quickfix-server:server.cfg").to("quickfix-client:client.cfg");
>>
>> (Listen for incoming fix messages and then forward them to a different
>> system)
>>
>> Does the warning mean I would not be able to return an "ACK" type message
>> to
>> whoever sent a message to my 'server' unless I configured another
>> endpoint
>> to point back to them and an endpoint to target system I want to forward
>> to?
>> --
>> View this message in context:
>> http://old.nabble.com/Quickfix-send-receive-messages-in-both-directions-tp27855316p27855316.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>>
>
>
> -----
> Charles Moulliard
> SOA Architect
>
> My Blog : http://cmoulliard.blogspot.com/
>
--
View this message in context: http://old.nabble.com/Quickfix-send-receive-messages-in-both-directions-tp27855316p27950996.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Quickfix send/receive messages in both directions
Posted by 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
Re: Quickfix send/receive messages in both directions
Posted by 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
Posted by Charles Moulliard <cm...@gmail.com>.
Hi,
Communication with FIX engine is different from a pure client - server
communication. AS mentioned in the documentation the quickfix engine that we
use behind the camel-quickfix endpoint will establish a communication with a
FIX Server and FIX messages will be exchanged regularly (=hearbeat, logon,
logout) to keep the communication alive. So this is not a true socket
channel created between the two partners but a communication channel. To
send messages to FIX server you must use the quickfix-client even if FIX
will provide you feedback on the messages exchanged and to receive from a
FIX server messages (as a client), you to use the other endpoint.
So you can use from(quickfixserver).to(quickfixclient) otherwise you will
resend messages receive through a FIX session to another FIX server with
same sesssion id.
Kind regards
Charles Moulliard
Senior Enterprise Architect
Apache Camel Committer
*****************************
blog : http://cmoulliard.blogspot.com
twitter : http://twitter.com/cmoulliard
Linkedlin : http://www.linkedin.com/in/charlesmoulliard
Apache Camel Group :
http://www.linkedin.com/groups?home=&gid=2447439&trk=anet_ug_hm
On Wed, Mar 10, 2010 at 9:24 PM, grabiarz <gr...@gmail.com> wrote:
>
> I wanted to use camel and Quickfix combo in my project and I noticed this
> warning (on http://camel.apache.org/quickfix.html) :
>
> Warning: You cannot use a quickfix engine to send or receive messages in
> both direction as the FIX protocol handle logon/logout sessions with
> heartbeat messages which are send to verify if the server or client is
> still
> alive in only one direction.
>
> I'm not quite sure how to understand it as I managed to get camel to
> forward
> a message from one endpoint to another like this:
>
> from("quickfix-server:server.cfg").to("quickfix-client:client.cfg");
>
> (Listen for incoming fix messages and then forward them to a different
> system)
>
> Does the warning mean I would not be able to return an "ACK" type message
> to
> whoever sent a message to my 'server' unless I configured another endpoint
> to point back to them and an endpoint to target system I want to forward
> to?
> --
> View this message in context:
> http://old.nabble.com/Quickfix-send-receive-messages-in-both-directions-tp27855316p27855316.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>