tags:

views:

68

answers:

3

My situation is: A c++ program needs to talk with a Java program using FIX protocol.

My solution: - Messaging: C++ program publishes a text in FIX format which Java progrma can consume and parse with quickfix/j. - Socket: Setup a FIX server in Java program, then C++ program as a client can connect to this socket and write byte stream into it using quickfix. Java program uses quickfix/j to parse the byte stream.

My questions: 1. Is there any compatiblity problem for socket solution, i.e. ,the byte stream coded with quickfix can be fully decoded by quickfix/j? 2. Which one is better? Cons and pros.

Thanks in advance.

A: 

FIX messaging would be an easier solution, rather than implementing sockets. There are socket communications already embedded in the quickfix libraries. It is no use to reimplement then unless you are doing something very different. The engine is meant to decipher FIX messages. And if you want to modify any of the socket communications for the libraries, you can change the libraries itself. You have the source code anyways.

If you try implementing sockets you may have to write wrappers around the sockets to parse messages from C++ along to Java and vice versa.

You have the C++ version of quickfix library. Use that as a initiator to send FIX messages across to the Java acceptor. You probably wouldn't have to worry about writing a C++ server to send FIX messages in a bytestream. Let the underlying library do the work of doing the communication rather than yourself.

DumbCoder
Many thanks for your reply. I also prefer FIX messaging. Now c++ program send a TextMessage to a queue, and Java program consume message from the queue, construct a Message using this text message. Is this the right solution?
lostinmoney
If you don't want to use the C++ quickfix library that is fine. Is your queue designed for multi threading ? Quickfix takes care of that multiple sessions send across messages at the same time. Queuing may take time for the messages to be sent, FIX conversion is slow, so if you aren't concerned about latency using a queue mayn't be an issue. Sending a TextMessage and then converting is a 2 step process. Take your data and create a FIX message in the first instant would be much faster, as your final aim is to create a FIX message only.
DumbCoder
My queue is well designed for multi-threading, and we use quickfix in C++ side, quiickfix/j in Java side. My concern is the same with you, it seems TextMessage solution is 2 steps process which is indirect. I want to know if there is any build-in messaging mechanism for quickfix or quickfix/j? Is there any out of sequence issue if using multiple sessions since the message order is very critical for us?
lostinmoney
Better idea would be to make the process which writes to a file, create the FIX message and send it across to the acceptor. There is no point queing when it is better to send the message as soon as it is created. Out of sequence would be Quickfix issue, not your application issue, if you send messages in the order you want to send. Quickfix uses a Threaded socket for C++ and Java. It uses Mina for Java and basic sockets for C++ depending on the platform.
DumbCoder
A: 

FIX might be easier. But if you choose sockets, make sure to convert data send/recv from/on the C++ program to/from network byte order. (See reference for: htons(), htonl() ntohs(), and ntohl()). Java always uses network byte order so you don't have to do any conversion there.

Vijay Mathew
That is not an issue with the libraries along multiple architectures. Quickfix library user doesn't have to worry about that.
DumbCoder
A: 

FIX is a text based protocol, i.e. you don't have to worry about byte order. At the wire level, all you're doing is sending buffers of characters. So if you're writing in a C++ program to a java (quickfixj) based client/server, as long as you adhere to the FIX protocol, you'll have no issues.

Then again, as DumbCoder pointed out above, if you're not overly concerned about performance, you could use quickfix (the C++ version!)

Nim
Many thanks for your reply, then my concern is not a problem.
lostinmoney