Imported from previous forum
[ original email was from Ranjit M - ranjit_unni@yahoo.com ]
Hi,
Seems a silly question but please bear with me.
I needed some clarification on the terminology used widely w.r.t FIX-based applications. I get to see FIX "Engine" mentioned frequently as also FIX "Gateway".
Some assumptions made about “Gateway”'s:
- a gateway to multiple destinations
- implements the Session protocol
- no business level validations (like ClOrdID checks, etc.)
“Engine”'s:
-
- and 2. as above
- includes business level checks (implements application protocol)
OR - should i look at "Engine" as a box of may be a Gateway + OMS???
I have often come across responses where a "FIX engine talks to the business processing system" and the like…hence the question.
Thanks in advance,
Ranjit
I think you will see those terms used synonymously and thus if you are looking at a specific implementation (e.g. vendor offering) which is offering either a "FIX Engine" or a "FIX Gateway", I would suggest that you get all of the details and differentiating features.
From a software development perspective, FIX is generally implemented using a layered approach in which the FIX Session protocol implementation (establishing and maintaining a connnection, MsgSeqNum, Resend Requests, etc.) is separate from business logic (e.g. integration with one’s OMS). We commonly refer to the software implementation of the FIX Session protocol (e.g. Vol 2 in FIX 4.3) as a “FIX Engine”.
Some may also refer to this as a "FIX Gateway". This might be representative of how the FIX engine is implemented, for instance a large brokerage firm with multiple Order Management Systems might have a single "FIX Gateway" which combines (or perhaps layers on top of a FIX engine) the functionality of a FIX Engine with some internal routing rules to direct traffic the the appropriate internal destination for true business message processing.
In the end, you’re best to consider the terms “FIX Engine” and “FIX Gateway” to be the same and ask for details on how they are differentiated. You may also find a 4 part presentation dated Feb 2001 which is located under “More Information”, “Presentations” helpful in understanding FIX implementations.
> Hi,
>
> Seems a silly question but please bear with me.
>
> I needed some clarification on the terminology used widely w.r.t FIX-based applications. I get to see FIX “Engine” mentioned frequently as also FIX “Gateway”.
>
> Some assumptions made about “Gateway”'s:
> 1. a gateway to multiple destinations
> 2. implements the Session protocol
> 3. no business level validations (like ClOrdID checks, etc.)
>
> “Engine”'s:
> - 1. and 2. as above
> - includes business level checks (implements application protocol)
> OR
> - should i look at “Engine” as a box of may be a Gateway + OMS???
>
> I have often come across responses where a “FIX engine talks to the business processing system” and the like…hence the question.
>
> Thanks in advance,
> Ranjit
>
> I think you will see those terms used synonymously and thus if you are looking at a specific implementation (e.g. vendor offering) which is offering either a “FIX Engine” or a “FIX Gateway”, I would suggest that you get all of the details and differentiating features.
>
> From a software development perspective, FIX is generally implemented using a layered approach in which the FIX Session protocol implementation (establishing and maintaining a connnection, MsgSeqNum, Resend Requests, etc.) is separate from business logic (e.g. integration with one’s OMS). We commonly refer to the software implementation of the FIX Session protocol (e.g. Vol 2 in FIX 4.3) as a “FIX Engine”.
>
> Some may also refer to this as a “FIX Gateway”. This might be representative of how the FIX engine is implemented, for instance a large brokerage firm with multiple Order Management Systems might have a single “FIX Gateway” which combines (or perhaps layers on top of a FIX engine) the functionality of a FIX Engine with some internal routing rules to direct traffic the the appropriate internal destination for true business message processing.
I agree with Scott’s interpretation of “FIX Engine”. Personally, I like to draw a distinction between FIX Engines and Gateways; my definition of a FIX Gateway includes, but isn’t limited to, three broad functions:
- Implement the FIX session layer (the FIX
Engine). - Perform mapping and translation between FIX
and one or more internal protocols. - Perform routing and distribution of messages
between the FIX connections and internal
systems.
I like dictionary.com’s definition of the word “gateway”, from which the following excerpt is taken:
gate·way
n.
3. Software or hardware that enables
communication between computer networks
that use different communications protocols.
Also called router.
I may well be in a minority with my interpretation of FIX Gateway, so take Scott’s advice and ask for more details when researching existing FIX Engines and Gateways.
[ original email was from Tayloe Draughon - tayloed@capital-mkts.com ]
I agree with Shay’s definition of engines and gateways.
Historically a gateway is considered to be a program that translates from one protocol to another protocol for the purpose of moving information or transactions to a different system. For example, Sybase used to sell a product called “open server” which allowed a programmer to communicate to non-Sybase databases or systems. Sybase’s sample program was a gateway into an email system.
In FIX terms, a gateway would be a program that falls into one of the following:
-
A program that receives fix messages and translates to another API. For example, a FIX program that receives FIX execution reports (fills) and reports the fills to a clearing system using another message structure.
-
A program that receives another protocol and translates that protocol into FIX.
-
A combination of #1 and #2.
Typically, a FIX gateway will include a FIX engine (for encoding, decoding, and transmission of messages.) But a FIX engine does not need to be a gateway.
Tayloe Draughon
Capital Markets Consulting
tayloed@capital-mkts.com
> > I think you will see those terms used synonymously and thus if you are looking at a specific implementation (e.g. vendor offering) which is offering either a “FIX Engine” or a “FIX Gateway”, I would suggest that you get all of the details and differentiating features.
> >
> > From a software development perspective, FIX is generally implemented using a layered approach in which the FIX Session protocol implementation (establishing and maintaining a connnection, MsgSeqNum, Resend Requests, etc.) is separate from business logic (e.g. integration with one’s OMS). We commonly refer to the software implementation of the FIX Session protocol (e.g. Vol 2 in FIX 4.3) as a “FIX Engine”.
> >
> > Some may also refer to this as a “FIX Gateway”. This might be representative of how the FIX engine is implemented, for instance a large brokerage firm with multiple Order Management Systems might have a single “FIX Gateway” which combines (or perhaps layers on top of a FIX engine) the functionality of a FIX Engine with some internal routing rules to direct traffic the the appropriate internal destination for true business message processing.
>
> I agree with Scott’s interpretation of “FIX Engine”. Personally, I like to draw a distinction between FIX Engines and Gateways; my definition of a FIX Gateway includes, but isn’t limited to, three broad functions:
>
> 1. Implement the FIX session layer (the FIX
> Engine).
> 2. Perform mapping and translation between FIX
> and one or more internal protocols.
> 3. Perform routing and distribution of messages
> between the FIX connections and internal
> systems.
>
> I like dictionary.com’s definition of the word “gateway”, from which the following excerpt is taken:
>
> gate·way
> n.
> 3. Software or hardware that enables
> communication between computer networks
> that use different communications protocols.
> Also called router.
>
> I may well be in a minority with my interpretation of FIX Gateway, so take Scott’s advice and ask for more details when researching existing FIX Engines and Gateways.
>