Re: [Quickfixj-users] Adding qualifier to quickfix Message

[<st...@te...>]

> Wanted to ask for advice on the best way to decouple the business
> logic from sending logic in quickfixj.
>
> For example, we are trying to use a messaging framework where our
> "OrderManager" would drop a completely configured FIX message on a
> queue that will then be sent out by another thread.
>
> To send the message, we need to have the FIX message configured with
> all the sessionID routing info (sender/targetIDs + beginString +
> qualifier).
>
> However, currently it's not possible to set the qualifier on the
> Message object itself - there's no setter for that, and we don't want
> to invent a custom FIX field to store it in the message itself either.
>
> What would you recommend the best approach to solve this?
> A change to the API (adding quickfix.Message.setQualifier() and
> changing quickfix.Message.setSessionID to be public instead of
> package-protected) would solve our problem, but it's a change to the
> API and i'm not sure it's the best approach.

I don't mind making the setSessionID method to be public. Adding methods
to the QFJ classes doesn't break compatibility from QF to QFJ.

However, I'd recommend not using the qualifier. Other than for
compatibility I'd not have it in the code at all. I'd rather identify
sessions by standard compID, subID, and locationID. This is another future
change on my list, although I can't remove session qualifier without
breaking QF compatibility. The use of session qualifier also makes it
difficult or impossible to support standard third party routing in the
session protocol engine because there is no standard message field defined
for the qualifier (qualifiers can't be /sent/ to a counterparty in any
standard way). In other words, it's not part of the protocol. It's a trick
to handle a situation where a counterparty wants to have two simultaneous
sessions with the same protocol-level identification.

As you may have guessed, I'm not inclined to add more support for session
qualifier. :-) However, I'm open to more discussion.

Regards,

Steve

Steve