Imported from previous forum
I have seen that the mayority of engines are not VB6 compatible and that quickfix appears to be the most popular engine. All our developments are limited to VB6 (not VB.NET) for this project so we have to either use a specific VB6 compatible engine, or consider a technical encapsulation of a FIX Engine with C++ or Java, etc. The technical encapsulation would have to be performed by another team with C++/Java resources and make it available via an API/Active X to VB6 for business logic fuctionality developments.
Has anyone performed the encapsulation mentioned above ? Does anyone foresee any difficulties with this ? Does anyone have any alternative suggestions.
If the encapsulation route is problematic, can you recomend a suitable VB6 engine ?
Our inital requirements revolve around an engine capable of less than 50 daily transactions, but in the furture this could go up to 10000 daily transactions. For now we will only be performing simple single order and order cancellation requests. We will also need to receive the relevant confirmation and settlement messages for these orders. We would use fix verions 4.2 or 4.4
Many, many thanks.
[ original email was from Richard Ney - rney@innerex.com ]
Hi,
I may have a suitable engine for you but this forum is not the best place to discuss product solutions.
If you are interested feel free to contact me at rney@innerex.com
Best,
Richard
I have seen that the mayority of engines are not VB6 compatible and that
quickfix appears to be the most popular engine. All our developments are
limited to VB6 (not VB.NET) for this project so we have to either use a
specific VB6 compatible engine, or consider a technical encapsulation of
a FIX Engine with C++ or Java, etc. The technical encapsulation would
have to be performed by another team with C++/Java resources and make it
available via an API/Active X to VB6 for business logic fuctionality
developments.Has anyone performed the encapsulation mentioned above ? Does anyone
foresee any difficulties with this ? Does anyone have any alternative
suggestions.If the encapsulation route is problematic, can you recomend a suitable
VB6 engine ?Our inital requirements revolve around an engine capable of less than 50
daily transactions, but in the furture this could go up to 10000 daily
transactions. For now we will only be performing simple single order and
order cancellation requests. We will also need to receive the relevant
confirmation and settlement messages for these orders. We would use fix
verions 4.2 or 4.4Many, many thanks.
[ original email was from John Greenan - john.greenan@alignment-systems.com ]
Don’t do it this way - you’ll enter a world of pain…
Get a FIX engine with an adapter for a compatible message based middleware layer - like MQ Series, TIBCo, MSMQ, whatever.
Then get your VB6 app to pub/sub onto middleware and get the FIX engine tto pub/sub as well. Commercial FIX engines like CameronFIX or TransactTools will do this - I am pretty sure that the open source tools will do the same.
I have seen that the mayority of engines are not VB6 compatible and that
quickfix appears to be the most popular engine. All our developments are
limited to VB6 (not VB.NET) for this project so we have to either use a
specific VB6 compatible engine, or consider a technical encapsulation of
a FIX Engine with C++ or Java, etc. The technical encapsulation would
have to be performed by another team with C++/Java resources and make it
available via an API/Active X to VB6 for business logic fuctionality
developments.Has anyone performed the encapsulation mentioned above ? Does anyone
foresee any difficulties with this ? Does anyone have any alternative
suggestions.If the encapsulation route is problematic, can you recomend a suitable
VB6 engine ?Our inital requirements revolve around an engine capable of less than 50
daily transactions, but in the furture this could go up to 10000 daily
transactions. For now we will only be performing simple single order and
order cancellation requests. We will also need to receive the relevant
confirmation and settlement messages for these orders. We would use fix
verions 4.2 or 4.4Many, many thanks.
Don’t do it this way - you’ll enter a world of pain…
Just out of interest, why do you not recommend this ? What do you mean ?
Don’t do it this way - you’ll enter a world of pain…
Just out of interest, why do you not recommend this ? What do you mean ?
Instead of encapsulating quickfix in an c++ API, I guess it would be best to create a small c++ app to write/read to/from something like MQseries and then do all the functional processing from VB6 and MQseries. Do you guys see any problems with this type of solution ?
Don’t do it this way - you’ll enter a world of pain…
Just out of interest, why do you not recommend this ? What do
you mean ?Instead of encapsulating quickfix in an c++ API, I guess it would be
best to create a small c++ app to write/read to/from something like
MQseries and then do all the functional processing from VB6 and
MQseries. Do you guys see any problems with this type of solution ?
Can someone familiar with the quickfix calls advise if we will loose any functionality by performing the proposed with MQseries ?
Don’t do it this way - you’ll enter a world of pain…
Just out of interest, why do you not recommend this ? What do you
mean ?Instead of encapsulating quickfix in an c++ API, I guess it would be
best to create a small c++ app to write/read to/from something like
MQseries and then do all the functional processing from VB6 and
MQseries. Do you guys see any problems with this type of solution ?Can someone familiar with the quickfix calls advise if we will loose any
functionality by performing the proposed with MQseries ?
I have been working on quickfix client, as far as I understand the MQ Series will add to the performance of quickfix.
I must agree with this point of view …
you could choose from 2 different approachs
1.- the Programmatic Approach (i must say your first impression)
if you encapsulate a FIX Solution under VB or any other Programming language.
That could lead to corrupt the core (Operative System, and/or the Fix Engine software).
By hand you will are close to failure if you don’t master the Core of your platform.
2.- The protocol Approach.
you use the proved solutions; you buy a fix engine and an approved solution (MQ, Socks or any other Adapter to your technology)
this could have the problem that if you don’t use it well you
could be led to False patrons and would lead also to a slow production environment.
Don’t do it this way - you’ll enter a world of pain…
Just out of interest, why do you not recommend this ? What do you
mean ?Instead of encapsulating quickfix in an c++ API, I guess it would be
best to create a small c++ app to write/read to/from something like
MQseries and then do all the functional processing from VB6 and
MQseries. Do you guys see any problems with this type of solution ?Can someone familiar with the quickfix calls advise if we will loose any
functionality by performing the proposed with MQseries ?
I have done implementation of FIX Engine in VB6 and I can help you to solve your problem.
If you need to discuss further, you may contact me on my private email
I have seen that the mayority of engines are not VB6 compatible and that
quickfix appears to be the most popular engine. All our developments are
limited to VB6 (not VB.NET) for this project so we have to either use a
specific VB6 compatible engine, or consider a technical encapsulation of
a FIX Engine with C++ or Java, etc. The technical encapsulation would
have to be performed by another team with C++/Java resources and make it
available via an API/Active X to VB6 for business logic fuctionality
developments.Has anyone performed the encapsulation mentioned above ? Does anyone
foresee any difficulties with this ? Does anyone have any alternative
suggestions.If the encapsulation route is problematic, can you recomend a suitable
VB6 engine ?Our inital requirements revolve around an engine capable of less than 50
daily transactions, but in the furture this could go up to 10000 daily
transactions. For now we will only be performing simple single order and
order cancellation requests. We will also need to receive the relevant
confirmation and settlement messages for these orders. We would use fix
verions 4.2 or 4.4Many, many thanks.