quickfixj-users

[Quickfixj-users] Adding qualifier to quickfix Message

[Toli K. <to...@ma...>]

Hey guys,

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.

any other ideas/advice?

thanks!

-- 
Toli Kuznets
http://www.marketcetera.com: Open-Source Trading Platform
download.run.trade.

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

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

[Oren M. <or...@qu...>]

Yes.  The only reason the qualifier was added is because of a counter  
party that had different subsystems that were only differentiated by  
connectivity and otherwise share identical session identification.  I  
would not recommend ever using it unless a counterparty forces you  
into the situation and is too stubborn to do anything about it.  It  
is intended strictly as an internal identifier.

I'm not really sure how SubID and LocationID solve the same problem  
as they don't do anything to uniquely identify a session since  
multiple subid and locationid combinations can be sent through a  
session.

In this case, however, subids are the appropriate solution.

--oren

On Nov 8, 2006, at 2:33 PM, st...@te... wrote:

> 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
>
>
> ---------------------------------------------------------------------- 
> ---
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>

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

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

> Yes.  The only reason the qualifier was added is because of a counter
> party that had different subsystems that were only differentiated by
> connectivity and otherwise share identical session identification.  I
> would not recommend ever using it unless a counterparty forces you
> into the situation and is too stubborn to do anything about it.  It
> is intended strictly as an internal identifier.
>
> I'm not really sure how SubID and LocationID solve the same problem
> as they don't do anything to uniquely identify a session since
> multiple subid and locationid combinations can be sent through a
> session.

Do you have pointers in the spec related to this? The thirdparty
routing fields seem to imply that the subId and locationId can
be used for routing at the session protocol level. The session
protocol would only know how to route between sessions so it seemed
to me that subId and locationId were being used as optional parts
of a session identifier. I agree there is nothing to prohibit using
those fields for application level purposes as well although
the fields are defined as part of the session protocol. My experience
has been that counterparties used them for session identification
purposes but I know there are many variations of FIX usage.

> In this case, however, subids are the appropriate solution.

A possible approach would be to support subId and locationId as
identification fields if they are specified in the session settings.
Otherwise, those fields would be ignored for routing purposes (party-
to-party or third-party) and just passed to the application.

Steve

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

[Oren M. <or...@qu...>]

Whatever the case concerning the academics various FIX ids, I agree  
with this approach.

--oren

> A possible approach would be to support subId and locationId as
> identification fields if they are specified in the session settings.
> Otherwise, those fields would be ignored for routing purposes (party-
> to-party or third-party) and just passed to the application.
>
> Steve