Designing reusable FIX configuration

, ,
1

Imported from previous forum

2

Hi,

I am a relative newbie to the FIX world and was looking to design a faily reusable configuration format for setting up FIX sessions and custom plugins.

The idea here is to be able to take the configuration and be able to use it to customise a different FIX engine (custom build or off the shelf) with minimal changes.

I would appreciate any ideas/articles/thoughts on this subject.

Thanks in advance for your help!

~Arpita

3

Hi,

I am a relative newbie to the FIX world and was looking to design a
faily reusable configuration format for setting up FIX sessions and
custom plugins.

The idea here is to be able to take the configuration and be able to use
it to customise a different FIX engine (custom build or off the shelf)
with minimal changes.

I would appreciate any ideas/articles/thoughts on this subject.

Thanks in advance for your help!

~Arpita

Hi Arpita,

Most FIX engines, both commercial and open-source, provide reasonably flexible mechanisms for configuring sessions. I would suggest you start by taking a look at both the QuickFIX and VersaFix open source engines, as both of these systems provide good examples of how to configure sessions and extensions in a manner that provides a good degree of flexibility.

You can find QuickFIX at:

http://www.quickfixengine.org

You can find VersaFix at:

http://www.assimilate.com/Products/VersaFix

The complete source code for both of those engines is available from those locations, as well as documentation that describes how their configuration systems work.

Cheers,

Russ

4

[ original email was from Toby Corballis - toby.corballis@rapidaddition.co.uk ]
> > Hi,

I am a relative newbie to the FIX world and was looking to design a
faily reusable configuration format for setting up FIX sessions and
custom plugins.

The idea here is to be able to take the configuration and be able to
use it to customise a different FIX engine (custom build or off the
shelf) with minimal changes.

I would appreciate any ideas/articles/thoughts on this subject.

Thanks in advance for your help!

~Arpita

Hi Arpita,

Most FIX engines, both commercial and open-source, provide reasonably
flexible mechanisms for configuring sessions. I would suggest you start
by taking a look at [… snip …]

Cheers,

Russ

As the open source FIX Engines also drive commercial revenue, ,I would respectfully suggest that promotion of them, and links to their sites are not permissible in this forum and that the right thing is to direct people to the Product Discussion forum for more information. Can I request that the above message (from which I have snipped the promotional information in this reply] be deleted for that reason? Many thanks

5

Hi,

I am a relative newbie to the FIX world and was looking to design a
faily reusable configuration format for setting up FIX sessions and
custom plugins.

The idea here is to be able to take the configuration and be able to use
it to customise a different FIX engine (custom build or off the shelf)
with minimal changes.

I would appreciate any ideas/articles/thoughts on this subject.

Thanks in advance for your help!

~Arpita

Hi Arpita,

Since you’re asking for ideas, here are my thoughts - if you are going to try and build a universal configuration system of some sorts, you should start out by just taking a look at the configuration systems that are used by various FIX engines. If you don’t have access to any of the commercial ones, start with the open source ones like QuickFIX, QuickFIX/J, or VersaFix - you can google any of those terms for more information, and just take it from there.

By looking at the configuration schemes from a couple of different engines, you should be able to get a reasonable idea of the common criteria that are used across engines to configure them.

Cheers,

Russ

6

Hi,

I am a relative newbie to the FIX world and was looking to design a
faily reusable configuration format for setting up FIX sessions and
custom plugins.

The idea here is to be able to take the configuration and be able to
use it to customise a different FIX engine (custom build or off the
shelf) with minimal changes.

I would appreciate any ideas/articles/thoughts on this subject.

Thanks in advance for your help!

~Arpita

Hi Arpita,

Since you’re asking for ideas, here are my thoughts - if you are going
to try and build a universal configuration system of some sorts, you
should start out by just taking a look at the configuration systems that
are used by various FIX engines. If you don’t have access to any of the
commercial ones, start with the open source ones like QuickFIX,
QuickFIX/J, or VersaFix - you can google any of those terms for more
information, and just take it from there.

By looking at the configuration schemes from a couple of different
engines, you should be able to get a reasonable idea of the common
criteria that are used across engines to configure them.

Cheers,

Russ

Thank You Russ and Toby for your view points.

I would definitely get some research started on this. In your opinion, what is a more suitable idea - an XML based configuration or a database based one or do you prefer a different way?

7

Hi,

I am a relative newbie to the FIX world and was looking to design a
faily reusable configuration format for setting up FIX sessions and
custom plugins.

The idea here is to be able to take the configuration and be able to
use it to customise a different FIX engine (custom build or off the
shelf) with minimal changes.

I would appreciate any ideas/articles/thoughts on this subject.

Thanks in advance for your help!

~Arpita

Hi Arpita,

Since you’re asking for ideas, here are my thoughts - if you are going
to try and build a universal configuration system of some sorts, you
should start out by just taking a look at the configuration systems
that are used by various FIX engines. If you don’t have access to any
of the commercial ones, start with the open source ones like QuickFIX,
QuickFIX/J, or VersaFix - you can google any of those terms for more
information, and just take it from there.

By looking at the configuration schemes from a couple of different
engines, you should be able to get a reasonable idea of the common
criteria that are used across engines to configure them.

Cheers,

Russ

Thank You Russ and Toby for your view points.

I would definitely get some research started on this. In your opinion,
what is a more suitable idea - an XML based configuration or a database
based one or do you prefer a different way?

Hi Arpita

We have seen organisations use both options (XML and database).

A database configuration has the advantage when scaling a system (for example to support DR) that the details can be centrally maintained on a clustered database server.

For smaller installations, where you want minimal effort for deployment then an XML based configuration file may be more suitable.

Clive

8

Hi Arpita, Russ, Toby, Clive,

Sorry for the very late reply. I was looking into this topic and I believe there are two parts of a FIX engine config -

1 Counterparty details - this could be standardizable but Counterparty config for Session initiators would be different from config for Session acceptors

2 Config required for FIX engine to communicate with Trading application behind it - I think this part would be tough to standardize because there are so many different integration methods between FIX engine and trading application

Regards,
K. Mahesh

9

Hi Mahesh

This is interesting,

FIX engines are used in a variety of scenarios including gateways to exchanges and in routing hubs (to mention 2).

Depending on the destination for the FIX messages there are several integration “methods”. The easiest is obviously a destination that can handle FIX messages (and sessions) natively. But there are other standard and proprietary interfaces.

Tieing down config options for FIX end points would include sender / target comp id details, ip-addresses, ports, max message size supported, default FIX session version, supported FIX message versions, heart beat interval etc.

Clive

Hi Arpita, Russ, Toby, Clive,

Sorry for the very late reply. I was looking into this topic and I
believe there are two parts of a FIX engine config -

1 Counterparty details - this could be standardizable but Counterparty
config for Session initiators would be different from config for
Session acceptors

2 Config required for FIX engine to communicate with Trading application
behind it - I think this part would be tough to standardize because
there are so many different integration methods between FIX engine and
trading application

Regards,
K. Mahesh