Thoughts on order handling by the OMS

[dumitriu]

Hi all,

I have a few thoughts about the division of responsibility between Photon and the OMS.

It seems to me that logically there are multiple communication sessions going on.  The first is from each Photon client to the OMS, whose transport is JMS and which happens to use FIX as the message encoding.  The second is from the OMS to the exchange, which uses FIX because presumably that's what the exchange supports.  These protocols don't necessarily need to use the same encoding.  In practice they do use the same encoding because it's convenient and standardized, and there is one less translation step (other than the message modifiers applied by the OMS before sending the message out to the exchange).

What I'd like to see is an OMS which can handle an entire complex order execution process.  For a simple example, let's take executing options spreads at the ISE.  After sending a multi-leg order to the ISE, execution reports will be received separately for each leg.  Now, say I'm a trader and I don't want to see all those separate messages coming to me.  How about the OMS keeping track of the order, its status, and the execution reports received, and when it's finally done, it can send one execution report for the entire order to Photon.  More generally, and once the OMS can connect to multiple brokers, why not allow the users/traders to send complex orders which may span exchanges.

These changes require the OMS to be more aware of the orders it is handling, and manage more state, possibly durably in a database for recovery purposes.  OMS itself is largely stateless now, delegating state management to quickfixj.  The problem with letting FIX do all that work is that it understands only the low level stuff, like messages, but not the high level 'intentions', like the process of executing an order.  Perhaps using Apache Camel's BAM (Business Activity Monitoring) pattern http://activemq.apache.org/camel/bam-example.html, or describing the execution using a BPEL workflow using Apache Ode http://ode.apache.org/.  I'm just throwing out ideas...

Also, I noticed that all replies to Photon are sent to the "oms-messages" JMS topic.  If that is the case, does that mean that all Photons connected to one OMS will receive all status messages and execution reports?  Is that the desired behavior?  Wouldn't we want to isolate users from one another?

I hate to be a troublemaker, but I am very excited about this project and would like to see it go in [what I believe is] the right direction!  :)

Cheers,
Dan

[toli]

Dan,

These are very good points. let me address them separately.

> same encoding.  In practice they do use the same encoding because it's
> convenient and standardized, and there is one less translation step (other
> than the message modifiers applied by the OMS before sending the message out
> to the exchange).

that's exactly why we chose to use FIX throughout - it saves a lot of
effort on translation from one format to another.

> What I'd like to see is an OMS which can handle an entire complex order
> execution process.  For a simple example, let's take executing options

I believe someone (you?) has already created a ticket for that:
http://trac.marketcetera.org/trac.fcgi/ticket/450

I'll add your comments to the ticket. You are right, we do want to
support this behaviour in the future. Not quite sure how it will look
yet but we've been asked by multiple people about this.
Another requested related feature is support for allocations - sending
out one order and letting it be allocated across multiple
destinations.

> Also, I noticed that all replies to Photon are sent to the "oms-messages"
> JMS topic.  If that is the case, does that mean that all Photons connected
> to one OMS will receive all status messages and execution reports?  Is that
> the desired behavior?  Wouldn't we want to isolate users from one another?

Dan, this is indeed the desired behaviour. We envisioned ability to
send orders one way (say with OrderLoader, or with another
algorithmic/batch process) and then view and manage them in Photon.

If you want to start separating your traders, it's entirely possible
to create multiple queue/topic combinations in the same OMS and have
different traders configure Photon to use separate queue/topic
combinations.

In addition, we realize that you may want to prevent others from
accessing your OMS altogether, and we have an outstanding RFE to add
authentication: http://trac.marketcetera.org/trac.fcgi/ticket/208 .
It's a feature that we realize is absolutely necessary in the future.

> I hate to be a troublemaker, but I am very excited about this project and
> would like to see it go in [what I believe is] the right direction!  :)

Not at all! Thanks a lot for your input, and if you feel like filing
the bugs directly you can create a Trac account and i'll give you
ticket admin access, or you can use the anon/market login to edit it
anonymously. If you sign up, sign up with a full email address,
otherwise it'll try to short-circuit and send emails to
yourname@marketcetera which isn't very helpful.

thanks again for your feedback.

--
Toli Kuznets
http://www.marketcetera.com: Open-Source Trading Platform
download.run.trade.
_______________________________________________
m-etc-users mailing list
[hidden email]
http://lists.marketcetera.org/cgi-bin/mailman/listinfo/m-etc-users

[Rick Labs-2]

Dan,

I very much appreciate your thoughts here as it impacts the FIX algo
standard.

 >What I'd like to see is an OMS which can handle an entire complex
order execution process. For a simple example, let's take executing options
> spreads at the ISE.  After sending a multi-leg order to the ISE, execution
> reports will be received separately for each leg.  Now, say I'm a trader and
> I don't want to see all those separate messages coming to me.  How about the
> OMS keeping track of the order, its status, and the execution reports
> received, and when it's finally done, it can send one execution report for
> the entire order to Photon.  
We have not recently spent much time at FIX talking about how algo
orders are reported back and especially in process "status reporting".
We took the low road in V1 so you just slam in a standard FIX order and
get back plain vanilla FIX executions as they occur.

One of the things I brought up (and was shot down on V1.0) was a
publish/subscribe model of execution/status events that the OMS could
subscribe to. Each algo might offer a variety of status messages ranging
from everything in great detail,  up to just occasional heartbeats and
just two messages back - "failed to execute" or "I'm all done." That way
algos that for example hunt for liquidity could hunt all day and scoop
up liquidity, but the OMS would not be burdened by tons and tons of
small execution messages occurring every minute for trivial amounts. The
statusing back could be "adjustable". Also, you could get a message back
via FIX, with an with an SSL link that would bring up a graphical
dashboard on the algo executing in process. Traditionally all traders
have now is a dynamically updating grid control showing dynamic numbers
on whats left to go. The SSL link would open up some standardized
graphical reporting of what is going on. The SSL part of course would be
totally outside of the dedicated FIX pipes.

For V1 however the philosophy is to keep it simple. Use only standard
FIX messages with standard FIX responses. Otherwise the standard would
be too delayed before we can all agree on a new flexible, event driven
statusing model. I'm pretty sure however you can easily send an
acknowldgement back to the buy side that would contanin a ssl link right
after the order is processed. After that the statusing would occur
outside of the FIX standard.

> More generally, and once the OMS can connect to
> multiple brokers, why not allow the users/traders to send complex orders
> which may span exchanges.
>  
Again the FIX standard model in V1.0 is that a single "buy side" sends a
single algo order to a single "sell-side" for execution. The
"sell-side"  is 100% responsible for the the breakdown  and routing to
separate exchanges, ecns, etc.

However, it was also envisioned that algos would be created in house and
likewise executed in-house. In this instance there would be an algo
order, and a "traditional" OMS. The single entity algo order would get
passed through the OMS to an in house order EXECUTION management system
(EMS). The EMS would open the order and could break it down according to
the house order router and other preferences the "house" had for low
cost trading, at that particular moment. It would then handle all
elements of the execution. I know some firms do this - take in FIX
orders from standard OMS front ends, take those orders 100% apart and
operate in their own internal format, then "reconstitute" standard FIX
order on various output lines, going to various execution endpoints.

We also envisioned where higher level algos would in turn fire off lower
level algos, which in turn would fire off plain vanilla orders. For V1
however we declined persuing that type of multi tiered execution
environment because the party idendification becomes complex and the
order routing becomes complex. Thats not to say we couldn't reexamine
that again after V1 ships. However there are "challenges" at FIX beyond
the algo standard domain that impact our ability to really innovate
there. The dedicated party to party IP pipe heritage of FIX (think slow
"switched newtork") has yet to fully give way to someting that is fully
routable. Also, the commission arrangement and multiple "fingers in the
execution pie" (multiple intermediaries) is very challenging from a
regulatory prospective. Is everything fully disclosed to the the client?
Who exactly is responsible when a part of this blows up? As you can
envision, insuring the responsibilities are clear at every point in
time, and having a regulatory friendly, indelible audit path that can be
synchronized up might be especially challenging.

Still, one of the easiest to see use cases we had in this area is two
algos offered by two different brokers - one on an algo server co
located at the NYSE and one colocated at the Tokyo exchange. Each "low
level" algo would be perfectly tuned to each marketplace and very plain
vanilla. A third algo writer might come along and find a way to add
value to the two lower level algos by writing a third, higher level algo
that would fire off orders to the two lower level algos. The lower level
algo providers might be in the high volume, intensely facility based,
low latency business. The "high level" algo writer might be a single
"genius" arb trader that operated with only a few clients, virtually
zero facility, and very low volume - i.e. a trading boutique. Ultimately
the FIX algo standard would like to accommodate this type of scenario.
However for right at the moment, to prevent short term insanity, only
the simple model - one buy-side, one sell-side is supported. You have to
climb inside the EMS / order router to gain control of the execution
details.

Rick

--
Rick Labs
CL&B Capital Management, LLC
7583 Hunt Lane
Fayetteville, NY 13066-2554
315-637-0915 x11
FAX [phone]

_______________________________________________
m-etc-users mailing list
[hidden email]
http://lists.marketcetera.org/cgi-bin/mailman/listinfo/m-etc-users

[dumitriu]

Rick,

Man, it sounds like you basically read my mind!  Especially the last paragraph is describing almost exactly what I need.  Alas, it seems like we'll be building it ourselves in the foreseeable future.  However, I wouldn't mind collaborating, at least on design issues.  There are limits to how much I can disclose, of course.

One high level question to the Marketcetera crew is, will this be a tool primarily for the buy side or the sell side?

Cheers,
Dan

Rick Labs-2 wrote:

Dan,

I very much appreciate your thoughts here as it impacts the FIX algo
standard.

 >What I'd like to see is an OMS which can handle an entire complex
order execution process. For a simple example, let's take executing options
> spreads at the ISE.  After sending a multi-leg order to the ISE, execution
> reports will be received separately for each leg.  Now, say I'm a trader and
> I don't want to see all those separate messages coming to me.  How about the
> OMS keeping track of the order, its status, and the execution reports
> received, and when it's finally done, it can send one execution report for
> the entire order to Photon.  
We have not recently spent much time at FIX talking about how algo
orders are reported back and especially in process "status reporting".
We took the low road in V1 so you just slam in a standard FIX order and
get back plain vanilla FIX executions as they occur.

One of the things I brought up (and was shot down on V1.0) was a
publish/subscribe model of execution/status events that the OMS could
subscribe to. Each algo might offer a variety of status messages ranging
from everything in great detail,  up to just occasional heartbeats and
just two messages back - "failed to execute" or "I'm all done." That way
algos that for example hunt for liquidity could hunt all day and scoop
up liquidity, but the OMS would not be burdened by tons and tons of
small execution messages occurring every minute for trivial amounts. The
statusing back could be "adjustable". Also, you could get a message back
via FIX, with an with an SSL link that would bring up a graphical
dashboard on the algo executing in process. Traditionally all traders
have now is a dynamically updating grid control showing dynamic numbers
on whats left to go. The SSL link would open up some standardized
graphical reporting of what is going on. The SSL part of course would be
totally outside of the dedicated FIX pipes.

For V1 however the philosophy is to keep it simple. Use only standard
FIX messages with standard FIX responses. Otherwise the standard would
be too delayed before we can all agree on a new flexible, event driven
statusing model. I'm pretty sure however you can easily send an
acknowldgement back to the buy side that would contanin a ssl link right
after the order is processed. After that the statusing would occur
outside of the FIX standard.

> More generally, and once the OMS can connect to
> multiple brokers, why not allow the users/traders to send complex orders
> which may span exchanges.
>  
Again the FIX standard model in V1.0 is that a single "buy side" sends a
single algo order to a single "sell-side" for execution. The
"sell-side"  is 100% responsible for the the breakdown  and routing to
separate exchanges, ecns, etc.

However, it was also envisioned that algos would be created in house and
likewise executed in-house. In this instance there would be an algo
order, and a "traditional" OMS. The single entity algo order would get
passed through the OMS to an in house order EXECUTION management system
(EMS). The EMS would open the order and could break it down according to
the house order router and other preferences the "house" had for low
cost trading, at that particular moment. It would then handle all
elements of the execution. I know some firms do this - take in FIX
orders from standard OMS front ends, take those orders 100% apart and
operate in their own internal format, then "reconstitute" standard FIX
order on various output lines, going to various execution endpoints.

We also envisioned where higher level algos would in turn fire off lower
level algos, which in turn would fire off plain vanilla orders. For V1
however we declined persuing that type of multi tiered execution
environment because the party idendification becomes complex and the
order routing becomes complex. Thats not to say we couldn't reexamine
that again after V1 ships. However there are "challenges" at FIX beyond
the algo standard domain that impact our ability to really innovate
there. The dedicated party to party IP pipe heritage of FIX (think slow
"switched newtork") has yet to fully give way to someting that is fully
routable. Also, the commission arrangement and multiple "fingers in the
execution pie" (multiple intermediaries) is very challenging from a
regulatory prospective. Is everything fully disclosed to the the client?
Who exactly is responsible when a part of this blows up? As you can
envision, insuring the responsibilities are clear at every point in
time, and having a regulatory friendly, indelible audit path that can be
synchronized up might be especially challenging.

Still, one of the easiest to see use cases we had in this area is two
algos offered by two different brokers - one on an algo server co
located at the NYSE and one colocated at the Tokyo exchange. Each "low
level" algo would be perfectly tuned to each marketplace and very plain
vanilla. A third algo writer might come along and find a way to add
value to the two lower level algos by writing a third, higher level algo
that would fire off orders to the two lower level algos. The lower level
algo providers might be in the high volume, intensely facility based,
low latency business. The "high level" algo writer might be a single
"genius" arb trader that operated with only a few clients, virtually
zero facility, and very low volume - i.e. a trading boutique. Ultimately
the FIX algo standard would like to accommodate this type of scenario.
However for right at the moment, to prevent short term insanity, only
the simple model - one buy-side, one sell-side is supported. You have to
climb inside the EMS / order router to gain control of the execution
details.

Rick

--
Rick Labs
CL&B Capital Management, LLC
7583 Hunt Lane
Fayetteville, NY 13066-2554
315-637-0915 x11
FAX [phone]

_______________________________________________
m-etc-users mailing list
[e-mail]
http://lists.marketcetera.org/cgi-bin/mailman/listinfo/m-etc-users

[dumitriu]

Toli,

Yes, ticket 450 was indeed created by me. :)

Let me reiterate my question about the intended users of this product.  Do you see this as being a tool for the buy side or the sell side?

In either case I see the need for routing to multiple FIX destinations - on the buy side, routing to multiple brokers, and on the sell side, routing to multiple exchanges.  I'm not sure who the complex order execution would be good for, but possibly for both sides.  But again, is building an EMS (Execution Management System), as Rick mentioned, going beyond what this tool is intended for?

On the security front, if this tool is to be used by a sell side party, who offers a version of Photon to their clients, then it does seem important to isolate traders from one another.  You mentioned that it would be possible to isolate traders from one another by using multiple queues and topics, presumably with the appropriate authorization to access them.  How would one do that currently?  I see that ActiveMQ can use JAAS to authenticate and authorize connections from Photon.  I must confess my ignorance and as a silly question.  Is it possible for JAAS to use a database or LDAP to store the credentials and ACLs?

Toli, if you could give me access to enter tickets, that would be great.  I would certainly like to participate more, as time permits.

Cheers,
Dan

toli wrote:

Dan,

These are very good points. let me address them separately.

> same encoding.  In practice they do use the same encoding because it's
> convenient and standardized, and there is one less translation step (other
> than the message modifiers applied by the OMS before sending the message out
> to the exchange).

that's exactly why we chose to use FIX throughout - it saves a lot of
effort on translation from one format to another.

> What I'd like to see is an OMS which can handle an entire complex order
> execution process.  For a simple example, let's take executing options

I believe someone (you?) has already created a ticket for that:
http://trac.marketcetera.org/trac.fcgi/ticket/450

I'll add your comments to the ticket. You are right, we do want to
support this behaviour in the future. Not quite sure how it will look
yet but we've been asked by multiple people about this.
Another requested related feature is support for allocations - sending
out one order and letting it be allocated across multiple
destinations.

> Also, I noticed that all replies to Photon are sent to the "oms-messages"
> JMS topic.  If that is the case, does that mean that all Photons connected
> to one OMS will receive all status messages and execution reports?  Is that
> the desired behavior?  Wouldn't we want to isolate users from one another?

Dan, this is indeed the desired behaviour. We envisioned ability to
send orders one way (say with OrderLoader, or with another
algorithmic/batch process) and then view and manage them in Photon.

If you want to start separating your traders, it's entirely possible
to create multiple queue/topic combinations in the same OMS and have
different traders configure Photon to use separate queue/topic
combinations.

In addition, we realize that you may want to prevent others from
accessing your OMS altogether, and we have an outstanding RFE to add
authentication: http://trac.marketcetera.org/trac.fcgi/ticket/208 .
It's a feature that we realize is absolutely necessary in the future.

> I hate to be a troublemaker, but I am very excited about this project and
> would like to see it go in [what I believe is] the right direction!  :)

Not at all! Thanks a lot for your input, and if you feel like filing
the bugs directly you can create a Trac account and i'll give you
ticket admin access, or you can use the anon/market login to edit it
anonymously. If you sign up, sign up with a full email address,
otherwise it'll try to short-circuit and send emails to
yourname@marketcetera which isn't very helpful.

thanks again for your feedback.

--
Toli Kuznets
http://www.marketcetera.com: Open-Source Trading Platform
download.run.trade.
_______________________________________________
m-etc-users mailing list
[e-mail]
http://lists.marketcetera.org/cgi-bin/mailman/listinfo/m-etc-users

[Rick Labs-2]

Dan,

I use the terms "Buy-Side" and "Sell-Side" extremely loosely, especially
in terms of Algo trading:

Sell-Side is the group that expresses the xml that describes the
interface to actually use the algo. (both how the order ticket is to be
drawn on the traders workstation and how the FIX message will be
formatted out on the wire after the send button is hit.) The Sell-Side
offers the execution services that actually take in an algo order off
the FIX wire, and makes it happen. They are roughly "the server". In a
regular business model, they add value to plain vanilla market and limit
orders and "mark up" the cost of doing business with various execution
venues such as exchanges, ECN's and ATNs. Algos are worth more
commission because the Sell Side is hopefully doing more intelligent
work and hopefully providing highly competitive execution infrastructure.

Buy-Side is the "user" of the aglo. They are roughly "the client". They
call for actual, real live, algo executions.

In a DIY algo trading shop there are still separated functions - those
that develop the algos and those traders that actually use them. The
algo R&D department is the "Sell Side" and the proprietary trader (in
house) is the "Buy Side". The Sell Side designs the algos and builds out
the execution infrastructure. The Buy Side actually commits the firm's
capital to the specific algo strategies at "run time".

Some integrated trading houses have both an OMS and an EMS in house.
Trader X orders a very standard VWAP strategy from Goldman Sachs via the
OMS. The EMS takes that order apart and decides, hey, this isn't for
Goldman at all and re routes the order to DMA ports on the router. The
trader thought the order was going to Goldman but the EMS thought better
and executed in "in house." In another instance the same trader selects
a Lehman algo and presses send, the EMS looks at that order type and
concludes "just flow this one through", it does esentially nothing to
the order but flows it right through to the Lehman FIX connection.

Rick


[Aside: - we had quite a debate if in reality the OMS was actually a
server (I.E a display computer that offered up graphic display services
that were called by the Sell Side (or internal) EMS. That traders
display system would essentially be under the control of the Sell Side
EMS all during order build and execution (albeit very loosely coupled).
It would serve up  a rich, standard set of widgets and other
functionality that would be available to all applications that needed to
essentially "call the trader himself". This is sort of an X windows
approach. The OMS is a display server that the Sell Side calls (after of
course the trader initiates the process). This actually has lots of
merit, especially then teamed with a industry agreed upon set of
standard widgets. This is the approach taken in aircraft glass cockpits
- the cockpit designers are free to innovate in the "look and feel" area
yet the gage makers know they can call upon standard display services.  
A gage is actually the user application that calls on display services
for input and ouput. The entire "dashboard" is a display computer.]



dmd wrote:

> Toli,
>
> Yes, ticket 450 was indeed created by me. :)
>
> Let me reiterate my question about the intended users of this product.  Do
> you see this as being a tool for the buy side or the sell side?
>
> In either case I see the need for routing to multiple FIX destinations - on
> the buy side, routing to multiple brokers, and on the sell side, routing to
> multiple exchanges.  I'm not sure who the complex order execution would be
> good for, but possibly for both sides.  But again, is building an EMS
> (Execution Management System), as Rick mentioned, going beyond what this
> tool is intended for?
>
> On the security front, if this tool is to be used by a sell side party, who
> offers a version of Photon to their clients, then it does seem important to
> isolate traders from one another.  You mentioned that it would be possible
> to isolate traders from one another by using multiple queues and topics,
> presumably with the appropriate authorization to access them.  How would one
> do that currently?  I see that ActiveMQ can use JAAS to authenticate and
> authorize connections from Photon.  I must confess my ignorance and as a
> silly question.  Is it possible for JAAS to use a database or LDAP to store
> the credentials and ACLs?
>
> Toli, if you could give me access to enter tickets, that would be great.  I
> would certainly like to participate more, as time permits.
>
> Cheers,
> Dan
>
>
>
> toli wrote:
>  
>> Dan,
>>
>> These are very good points. let me address them separately.
>>
>>    
>>> same encoding.  In practice they do use the same encoding because it's
>>> convenient and standardized, and there is one less translation step
>>> (other
>>> than the message modifiers applied by the OMS before sending the message
>>> out
>>> to the exchange).
>>>      
>> that's exactly why we chose to use FIX throughout - it saves a lot of
>> effort on translation from one format to another.
>>
>>    
>>> What I'd like to see is an OMS which can handle an entire complex order
>>> execution process.  For a simple example, let's take executing options
>>>      
>> I believe someone (you?) has already created a ticket for that:
>> http://trac.marketcetera.org/trac.fcgi/ticket/450
>>
>> I'll add your comments to the ticket. You are right, we do want to
>> support this behaviour in the future. Not quite sure how it will look
>> yet but we've been asked by multiple people about this.
>> Another requested related feature is support for allocations - sending
>> out one order and letting it be allocated across multiple
>> destinations.
>>
>>    
>>> Also, I noticed that all replies to Photon are sent to the "oms-messages"
>>> JMS topic.  If that is the case, does that mean that all Photons
>>> connected
>>> to one OMS will receive all status messages and execution reports?  Is
>>> that
>>> the desired behavior?  Wouldn't we want to isolate users from one
>>> another?
>>>      
>> Dan, this is indeed the desired behaviour. We envisioned ability to
>> send orders one way (say with OrderLoader, or with another
>> algorithmic/batch process) and then view and manage them in Photon.
>>
>> If you want to start separating your traders, it's entirely possible
>> to create multiple queue/topic combinations in the same OMS and have
>> different traders configure Photon to use separate queue/topic
>> combinations.
>>
>> In addition, we realize that you may want to prevent others from
>> accessing your OMS altogether, and we have an outstanding RFE to add
>> authentication: http://trac.marketcetera.org/trac.fcgi/ticket/208 .
>> It's a feature that we realize is absolutely necessary in the future.
>>
>>    
>>> I hate to be a troublemaker, but I am very excited about this project and
>>> would like to see it go in [what I believe is] the right direction!  :)
>>>      
>> Not at all! Thanks a lot for your input, and if you feel like filing
>> the bugs directly you can create a Trac account and i'll give you
>> ticket admin access, or you can use the anon/market login to edit it
>> anonymously. If you sign up, sign up with a full email address,
>> otherwise it'll try to short-circuit and send emails to
>> yourname@marketcetera which isn't very helpful.
>>
>> thanks again for your feedback.
>>
>> --
>> Toli Kuznets
>> http://www.marketcetera.com: Open-Source Trading Platform
>> download.run.trade.
>> _______________________________________________
>> m-etc-users mailing list
>> [hidden email]
>> http://lists.marketcetera.org/cgi-bin/mailman/listinfo/m-etc-users
>>
>>
>>    
>
>  

--
Rick Labs
CL&B Capital Management, LLC
7583 Hunt Lane
Fayetteville, NY 13066-2554
315-637-0915 x11
FAX [phone]

_______________________________________________
m-etc-users mailing list
[hidden email]
http://lists.marketcetera.org/cgi-bin/mailman/listinfo/m-etc-users

[dumitriu]

Toli,

> If you want to start separating your traders, it's entirely possible
> to create multiple queue/topic combinations in the same OMS and have
> different traders configure Photon to use separate queue/topic
> combinations.

So, in fact, in terms of configuration, how would one do this?  I'm just having a look at the OMS config right now and it seems like too many beans directly or indirectly reference the single queue and single topic.  For instance, the following beans from oms.xml, oms-shared.xml, and quickfixj.xml.

The queue and topic definitions.

<bean id="requestQueue" class="org.apache.activemq.command.ActiveMQQueue">
        <constructor-arg value="oms-commands"/>
    </bean>

    <bean id="replyTopic" class="org.apache.activemq.command.ActiveMQTopic">
        <constructor-arg value="oms-messages"/>
    </bean>

The following bean can send to only one reply topic.

<bean id="outgoingJmsTemplate" class="org.springframework.jms.core.JmsTemplate">
        <property name="connectionFactory">
            <ref bean="pooledConnectionFactory"/>
        </property>
        <property name="messageConverter">
            <bean class="org.marketcetera.spring.JMSFIXMessageConverter"/>
        </property>
        <property name="defaultDestination" ref="replyTopic"/>
    </bean>

Again, in the following bean, any error generated in handleMessage() is sent to the single reply topic.  (One could even send the error back to a specified queue/topic using JMS Message.getReplyTo())

<bean id="listener" class="org.springframework.jms.listener.adapter.MessageListenerAdapter">
        <property name="delegate" ref="outgoingMessageHandler"/>
        <property name="defaultListenerMethod" value="handleMessage"/>
        <property name="defaultResponseDestination" ref="replyTopic"/>
        <property name="messageConverter">
            <bean class="org.marketcetera.spring.JMSFIXMessageConverter"/>
        </property>
    </bean>

    <!-- note that this needs to use the non-pooled connection factory -->
    <bean id="container" class="org.springframework.jms.listener.SimpleMessageListenerContainer">
        <property name="connectionFactory" ref="connectionFactory"/>
        <property name="messageListener" ref="listener"/>
        <property name="destination" ref="requestQueue"/>
    </bean>

The following bean, which actually receives the FIX messages from the broker/exchange, sends all FIX messages to the same reply topic.  I.e., there is no 'demultiplexing' to different topics based on order id.

<bean id="qfApplication" class="org.marketcetera.oms.QuickFIXApplication" scope="singleton">
        <constructor-arg ref="fixMessageFactory"/>
        <constructor-arg ref="jdbcLogFactory"/>
        <property name="jmsOperations" ref="outgoingJmsTemplate"/>
    </bean>

More precisely, say you wanted all the clients to use separate queues and topics to talk to the OMS (so that one could control security at a more fine grained level) but still sharing the same set of FIX sessions.  Naively, this is what I would want.

It seems that what is needed is some component/map that keeps track of which client/JMS queue an order came from, and then demultiplexes status messages coming back from the broker/exchange over FIX and sends them to the appropriate clients/topics.  As far as I can tell, there is no such mapping right now.

In fact, after thinking a little bit more, it seems that all the clients could use the same queue to send orders in, but should use different topics (or temporary queues) for receiving status messages.  This should be easy to specify using the replyTo in each message.

Cheers,
Dan

[toli]

Dan,

Thanks for the thoughtful feedback and overview!
You are right  - there's no easy way to 'demultiplex' the incoming FIX
messages across different reply topics. I've created an RFE to track
this: http://trac.marketcetera.org/trac.fcgi/ticket/458

thanks for your feedback!

> It seems that what is needed is some component/map that keeps track of which
> client/JMS queue an order came from, and then demultiplexes status messages
> coming back from the broker/exchange over FIX and sends them to the
> appropriate clients/topics.  As far as I can tell, there is no such mapping
> right now.
>
> In fact, after thinking a little bit more, it seems that all the clients
> could use the same queue to send orders in, but should use different topics
> (or temporary queues) for receiving status messages.  This should be easy to
> specify using the replyTo in each message.
>
> Cheers,
> Dan
>
> --
> View this message in context: http://www.nabble.com/Thoughts-on-order-handling-by-the-OMS-tf4635437.html#a13504629
> Sent from the m-etc-users mailing list archive at Nabble.com.
>
> _______________________________________________
> m-etc-users mailing list
> [hidden email]
> http://lists.marketcetera.org/cgi-bin/mailman/listinfo/m-etc-users
>

--
Toli Kuznets
http://www.marketcetera.com: Open-Source Trading Platform
download.run.trade.
_______________________________________________
m-etc-users mailing list
[hidden email]
http://lists.marketcetera.org/cgi-bin/mailman/listinfo/m-etc-users