QuickFix or QuickFix/J?

, ,
1

Imported from previous forum

2

Hi, We’re interested in installing either QuickFix or QuickFix/J in our shop. I know that one is written in C++ and the other in Java, but I’d like to get some opinions as to which platform to go with.

Thanks for any replies!

3

Hi, We’re interested in installing either QuickFix or QuickFix/J in our
shop. I know that one is written in C++ and the other in Java, but I’d
like to get some opinions as to which platform to go with.

Thanks for any replies!

Well, if you plan on developing in Java, then I’d say quickfix/j is a better choice, no JNI. If you plan on using C++ then quickfix is the only option.

4

Hi, Thanks for the quick reply. I’m at a new firm (formely of BofA) and we’re essentially a .NET shop here, although we are installed webMethods as an ESB which is Java based.

I’ve heard that QuickFix is no longer being supported and all the resources are going into QuickFix/J. Is this true? Once I have the engine up and running does it matter what language I am developing in? I’m assuming that the FIX engine is a stand-alone entity that we communicate with …no?

Thanks for any more info.

5

[ original email was from Dean Kauffman - dean.kauffman@tradeweb.com ]
I use C++ QuickFIX to build simulators and sample applications, but a number of our customers have built to our API using QuickFIX/J. Both are equally reliable but only QuickFIX/J has been upgraded to 5.0. On the other hand the C++ version can be significantly faster.

QuickFIX is not a standalone FIX engine but an object library. The typical way of implementing is to build your application around the libraries and deploy a single executable (C++) or a .jar file (Java). This means that it’s easier to build a Java application around QuickFIX/J and a C++ app around QuickFIX.

Hi, Thanks for the quick reply. I’m at a new firm (formely of BofA) and
we’re essentially a .NET shop here, although we are installed webMethods
as an ESB which is Java based.

I’ve heard that QuickFix is no longer being supported and all the
resources are going into QuickFix/J. Is this true? Once I have the
engine up and running does it matter what language I am developing in?
I’m assuming that the FIX engine is a stand-alone entity that we
communicate with …no?

Thanks for any more info.

6

Dean, Thanks for the clarification - I understand what you are saying. Since .NET uses neither Java or C++ which do you think is the better choice? Also what about QuickFix no longer being developed. Are bug fixes resolved faster with QuickFix/J? Is one community now much larger than the other? Thanks for any info!

7

Dean, Thanks for the clarification - I understand what you are saying.
Since .NET uses neither Java or C++ which do you think is the better
choice? Also what about QuickFix no longer being developed. Are bug
fixes resolved faster with QuickFix/J? Is one community now much larger
than the other? Thanks for any info!

Hi Erik,

If you’re talking native language integration, then from a .NET perspective it might be easier to use QuickFix/C++ since it comes with a set of C# wrappers that allow you to integrate it right into a .NET project. On the other hand, as Dean mentioned, the QuickFix/J project does support FIX 5.0. Not only that, but the QuickFix/J project seems to be more active in general. I guess it depends on your requirements, but there are plenty of ways you could integrate QuickFix/J with your C#/.NET applications.

Regards,

Russ

8

Russ, Thanks for the info. Not a big .NET guy myself…most of my work lately has been with Flex-Trade on UNIX. Does QuickFix/J supply the same C# wrappers? Thanks for any info.

9

Erik,
QuickFIX is still being supported. There is expected to be a new release later this month. We moved the code base from SVN to GIT. We have set up various build environments for different flavors of Linux and GCC on Amazon EC2. The daily build results can be viewed at

http://connamara.com:8010/waterfall

Jim

Hi, Thanks for the quick reply. I’m at a new firm (formely of BofA) and
we’re essentially a .NET shop here, although we are installed webMethods
as an ESB which is Java based.

I’ve heard that QuickFix is no longer being supported and all the
resources are going into QuickFix/J. Is this true? Once I have the
engine up and running does it matter what language I am developing in?
I’m assuming that the FIX engine is a stand-alone entity that we
communicate with …no?

Thanks for any more info.

10

Hi, We’re interested in installing either QuickFix or QuickFix/J in our
shop. I know that one is written in C++ and the other in Java, but I’d
like to get some opinions as to which platform to go with.

Thanks for any replies!

Eric, you may also want to take a look at the RA-4QF, a native .NET/C# port of Quickfix that was done by RapidAddition/Thoughtworks, as opposed to C# wrappers around C++ in the original QF product. Here’s a press release, though it does not give a lot of technical info:

http://www.automatedtrader.net/news/data-news/10777/rapid-addition-partners-with-thoughtworks

11

Thanks Andy - we’ll definitely look into this one. I’m assuming that this version is NOT free. Appreciate the info.

Regards, Erik

12

Thanks Andy - we’ll definitely look into this one. I’m assuming that
this version is NOT free. Appreciate the info.

Regards, Erik

Yeah, I think you have to pay for it. The other thing about it, is that it is not open source. It is pretty much a version of the RapidAddition engine with a QuickFIX API around it.

I guess I brought it up because it is a native .NET codebase and would integrate more seamlessly into your systems if you are embedding the FIX engine into your apps.

13

Andy,

No problem - I appreciate the extra information as this is what I am looking for…some more color on QuickFix and whether it’s a viable solution or whether we need to introduce some vendor tools as well into the mix. As I mentioned we are a .NET shop here at Fiserv for better or for worse. I came from BofA where we were not using .NET. I’m also trying to find out how difficult it would be to access QuickFix/J from .NET. Thanks again for your post.

14

Andy,

No problem - I appreciate the extra information as this is what I am
looking for…some more color on QuickFix and whether it’s a viable
solution or whether we need to introduce some vendor tools as well into
the mix. As I mentioned we are a .NET shop here at Fiserv for better or
for worse. I came from BofA where we were not using .NET. I’m also
trying to find out how difficult it would be to access QuickFix/J from
.NET. Thanks again for your post.

It all depends on what your architecture looks like. If you can deal with QuickFIX/J running in a separate process and communicating with your .NET apps through some type of IPC mechanism then it is fairly straightforward. If you want to have them live in the same process space, you basically have to use JNI to call Java (I think there are some third party products that can make this process easier through code generation). That approach is a lot less straightforward and robust…

15

[ original email was from Steve Bate - steve@technoetic.com ]
> I’m also trying to find out how difficult it would be to access QuickFix/J from

.NET. Thanks again for your post.

It’s possible to compile QuickFIX/J into a managed .NET library (in contrast to the unmanaged QuickFIX API) using the IKVM compiler from the Mono project. The build targets are included in the QuickFIX/J build scripts although the .NET binaries are not released as part of the official releases. However, I know at least one commercial vendor who uses this technique for using QFJ from a .NET user interface.