FIX Protocol router on top of HornetQ

[falcnair]

Hi,
I'm trying to figure out how difficult it might be to integrate FIX protocol (used in the financial industry) with HornetQ. I am encouraged to see that the transport subsystem is completely pluggable. The motivation for this project (if it ever gets off the ground) is to learn FIX, HornetQ and high speed messaging in general. I'd specifically like to see how HQ's speed, high availability, clustering, etc. work with FIX.

Some questions off the top of my head:

1. FIX messages carry sequence numbers and don't need every single message acknowledged. If there is a gap in sequence numbers, the producer or the consumer can request a re-synchronization (or a request to ignore the gap). This mechanism requires some crash-recoverable state, specifically the sequence number counters. Is this something HQ already provides or do I have to handle this myself?

2. FIX messages need to survive server crashes, even if the client has already acknowledged them. Am I wrong in my understanding that HQ's durable queues delete messages once they have been acknowledged?

3. FIX server (which would be HQ) needs to be able to resync both the producer and the consumers--it doesn't look like HQ currently worries about re-syncing the message producer. (producer sends message to HQ, which routs it to consumers).

4. While party A might initiate a connection to HQ, party B might expect HQ to initiate a connection to it. Am I correct in assuming that such functionality simply handled by the transport plug?

5. FIX is not as loosely coupled as typical messaging systems. If party A sends a message to party B, but party B is not 'connected' (the message is undeliverable), party A will expect to receive some sort of reject message. Would I accomplish this by forwarding the undeliverable message to the dead-letter queue, which will forward the message back to party A, and some sort of interceptor will block the message and generate a reject message instead?

6. Each connection has a unique ID pair associated with it (sender ID and target ID). If two parties, A and B want HQ to rout messages between them, A will logon and provide it's own ID and an ID assigned by HQ to party A, B will do the same. In other words, there may be 4 IDs involved when two parties connect to a single HQ instance (actually, possibly more). These IDs are usually assigned at the business level, therefore are expected to change. Obviously I have to store and authenticate these IDs myself, but should this also be done within the custom transport plug?

7. Connections might be scheduled. For example, party A might only be authorized to connect to the server between 8 am and 6 pm, while party B might expect the 'server' to initiate and maintain a connection to it between 8 am and 4:30 pm. Outside HQ's scope?

This is all I can think of right now. From the questions so far, does a FIX integration seem within HQ's scope or am I trying to fit a square peg in a round hole?

Thanks

[timfox]

Interesting post, I'll try and answer as best I can:

"falcnair" wrote:
Hi,
I'm trying to figure out how difficult it might be to integrate FIX protocol (used in the financial industry) with HornetQ. I am encouraged to see that the transport subsystem is completely pluggable. The motivation for this project (if it ever gets off the ground) is to learn FIX, HornetQ and high speed messaging in general. I'd specifically like to see how HQ's speed, high availability, clustering, etc. work with FIX.

Some questions off the top of my head:

1. FIX messages carry sequence numbers and don't need every single message acknowledged. If there is a gap in sequence numbers, the producer or the consumer can request a re-synchronization (or a request to ignore the gap). This mechanism requires some crash-recoverable state, specifically the sequence number counters. Is this something HQ already provides or do I have to handle this myself?

Can you explain a little more what you mean by "request a re-syncronization"?

2. FIX messages need to survive server crashes, even if the client has already acknowledged them. Am I wrong in my understanding that HQ's durable queues delete messages once they have been acknowledged?

Yes they would get deleted.

I guess if we wanted to retain messages after acknowledgement we could subclass the queue class to do this.

3. FIX server (which would be HQ) needs to be able to resync both the producer and the consumers--it doesn't look like HQ currently worries about re-syncing the message producer. (producer sends message to HQ, which routs it to consumers).

Not sure what you mean by resync.

4. While party A might initiate a connection to HQ, party B might expect HQ to initiate a connection to it. Am I correct in assuming that such functionality simply handled by the transport plug?

Can you expand a bit more on what you mean by this? What would trigger the server to initiate a connection to a client?

5. FIX is not as loosely coupled as typical messaging systems. If party A sends a message to party B, but party B is not 'connected' (the message is undeliverable), party A will expect to receive some sort of reject message. Would I accomplish this by forwarding the undeliverable message to the dead-letter queue, which will forward the message back to party A, and some sort of interceptor will block the message and generate a reject message instead?

Could you not have party A consuming from the dead letter queue?

6. Each connection has a unique ID pair associated with it (sender ID and target ID). If two parties, A and B want HQ to rout messages between them, A will logon and provide it's own ID and an ID assigned by HQ to party A, B will do the same. In other words, there may be 4 IDs involved when two parties connect to a single HQ instance (actually, possibly more). These IDs are usually assigned at the business level, therefore are expected to change. Obviously I have to store and authenticate these IDs myself, but should this also be done within the custom transport plug?

7. Connections might be scheduled. For example, party A might only be authorized to connect to the server between 8 am and 6 pm, while party B might expect the 'server' to initiate and maintain a connection to it between 8 am and 4:30 pm. Outside HQ's scope?

This is all I can think of right now. From the questions so far, does a FIX integration seem within HQ's scope or am I trying to fit a square peg in a round hole?

Thanks

There's a lot of information in your email. I suggest breaking it down into manageable chunks and asking more specific questions - bear in mind none of us have experience of FIX!