Design Requests
|
|
Brett Rogers-3
|
After experimenting with the platform for the last few months, and going live with it as of September, I've got a few design / feature suggestions. I considered sending these directly to the development team, but with at least a couple of the items I'm not entirely sure what the ultimate optimal solution should be, so thought that the mailing list might be a better place to start. I'll start with Equity Order issues.
- For single order entry using the Stock Order Ticket, I'd like to streamline the input methodology. For mouse entry, I'd like to see: - Radio buttons instead of pull-down menus for Side, Time in Force, Order Type. I find radio buttons faster than pull-down menus because (a) they're fewer clicks (b) one glance at the order ticket gives you an idea where each of your choices can be clicked (vs. hunting one-by-one through pull-downs) - Clickable default sizes in or near the Quantity field, and clickable default prices (would require price feed integration) in or near the Price field - Up / Down arrow buttons in the Quantity and Price fields that can be clicked to quickly adjust by default (or configurable) increments For keyboard entry, I'd like to see: - For the radio button sections, ability to both use hot keys to jump right to a choice, and arrow keys to navigate - Up / Down arrow keys function like the Up / Down arrow buttons above (Generally speaking, if I go Keyboard, I'd like to be able to go All-Keyboard. If I go Mouse, I'd like to be able to go as All-Mouse as I can. I find that shifting between input methodologies in the same order adds a lot of time.) - I'd like to see Configurable Defaults for the Order Tickets. - Quantity and Time in Force are the obvious early candidates - Routes and Up / Down Increments would also be very helpful - Configurable Defaults for Price and Quantity warnings (too far away from the market, or too many shares) would be extremely helpful - I'd like to see better ways to notice rejected orders (I'm uncertain about the best ways to accomplish this however). - Rejects tab that bolds or highlights with new reject information? - Order highlights in Open Orders tab for some time frame? - Plays distinctive (and configurable) sound file? - Menu bar flashes when unacknowledged rejects exist? - Small message appears above system tray (I think MSFT now calls this the "notification area")? - Others ideas / suggestions? - I should note that I loathe pop-up windows - I'd like to see a cross-route Cancel / Replace option - Most OMS that I've used allow for exchange-level Cancel / Replace orders. It's a specific order type in which the exchange handles the logical heavy lifting (ensuring no double-fills, etc.) - I'd like to be able to Cancel / Replace between exchanges. For example, I might try to lift an offer on a secondary exchange, but miss it. I would still like to work the order, but now I'd prefer to leave it on a more liquid exchange. I'd like to Cancel / Replace the order, switching exchanges. - The logic would have to operate at the level of the Marketcetera platform - the platform would not be able to send a Cancel / Replace order itself, but rather a cancel to one exchange, wait for an out, and then originate a new order to a second exchange (and link these orders internally in a way that the platform and the user both understand). That's it for now. Comments welcome. I'll have more input in the coming days, rest assured. _______________________________________________ m-etc-users mailing list [hidden email] http://lists.marketcetera.org/cgi-bin/mailman/listinfo/m-etc-users |
||||||||||||||||
toli
|
Brett,
These are all excellent suggestions. I see that you've created a few Trac tickets for these, thanks a lot, it helps us with tracking the RFEs and lets others add their ideas a well. Others on the list, do you have any comments on these features? I like the "system tray" notification for rejected orders, or small fading popup at the bottom (the way Trillian and other IM clients signal new messages). What about others? what do you think/prefer/suggest? What do others think of the input methodology RFEs? Combo boxes or radio buttons? Hot keys for all the fields in the order ticket? or is that overkill? let me know... and don't forget that you can see all the RFEs at http://trac.marketcetera.org/trac.fcgi/report/1 Let me know when you register on Trac so that i can give you ticket edit privileges if you want to add comments (or login as anon/market, see http://trac.marketcetera.org/trac.fcgi/wiki/Marketcetera/NewTicket). thanks again for taking the time to give us feedback! On 10/4/07, Brett Rogers <[hidden email]> wrote: > After experimenting with the platform for the last few months, and going > live with it as of September, I've got a few design / feature suggestions. > I considered sending these directly to the development team, but with at > least a couple of the items I'm not entirely sure what the ultimate optimal > solution should be, so thought that the mailing list might be a better place > to start. I'll start with Equity Order issues. > > > - For single order entry using the Stock Order Ticket, I'd like to > streamline the input methodology. > For mouse entry, I'd like to see: > - Radio buttons instead of pull-down menus for Side, Time in Force, > Order Type. I find radio buttons faster than pull-down menus because > (a) they're fewer clicks > (b) one glance at the order ticket gives you an idea where each of > your choices can be clicked (vs. hunting one-by-one through pull-downs) > - Clickable default sizes in or near the Quantity field, and clickable > default prices (would require price feed integration) in or near the Price > field > - Up / Down arrow buttons in the Quantity and Price fields that can be > clicked to quickly adjust by default (or configurable) increments > > > For keyboard entry, I'd like to see: > - For the radio button sections, ability to both use hot keys to jump > right to a choice, and arrow keys to navigate > - Up / Down arrow keys function like the Up / Down arrow buttons above > > (Generally speaking, if I go Keyboard, I'd like to be able to go > All-Keyboard. If I go Mouse, I'd like to be able to go as All-Mouse as I > can. I find that shifting between input methodologies in the same order > adds a lot of time.) > > > - I'd like to see Configurable Defaults for the Order Tickets. > - Quantity and Time in Force are the obvious early candidates > - Routes and Up / Down Increments would also be very helpful > - Configurable Defaults for Price and Quantity warnings (too far away > from the market, or too many shares) would be extremely helpful > > > - I'd like to see better ways to notice rejected orders (I'm uncertain about > the best ways to accomplish this however). > - Rejects tab that bolds or highlights with new reject information? > - Order highlights in Open Orders tab for some time frame? > - Plays distinctive (and configurable) sound file? > - Menu bar flashes when unacknowledged rejects exist? > - Small message appears above system tray (I think MSFT now calls this > the "notification area")? > - Others ideas / suggestions? > - I should note that I loathe pop-up windows > > - I'd like to see a cross-route Cancel / Replace option > - Most OMS that I've used allow for exchange-level Cancel / Replace > orders. It's a specific order type in which the exchange handles the > logical heavy lifting (ensuring no double-fills, etc.) > - I'd like to be able to Cancel / Replace between exchanges. For > example, I might try to lift an offer on a secondary exchange, but miss it. > I would still like to work the order, but now I'd prefer to leave it on a > more liquid exchange. I'd like to Cancel / Replace the order, switching > exchanges. > - The logic would have to operate at the level of the Marketcetera > platform - the platform would not be able to send a Cancel / Replace order > itself, but rather a cancel to one exchange, wait for an out, and then > originate a new order to a second exchange (and link these orders internally > in a way that the platform and the user both understand). > > > That's it for now. Comments welcome. I'll have more input in the coming > days, rest assured. > > _______________________________________________ > 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 |
James Webster-2
|
Are there any plans to integrate a CEP/ESP product like Esper into Marketcetera?
http://esper.codehaus.org/ On 10/9/07,
Toli Kuznets <[hidden email]> wrote: Brett, -- James Webster SA Fin blog: http://www.thenewsbeforethenews.com photos: http://flickr.com/photos/jim twitter: http://twitter.com/jimmcslim _______________________________________________ m-etc-users mailing list [hidden email] http://lists.marketcetera.org/cgi-bin/mailman/listinfo/m-etc-users |
||||||||||||||||
|
toli
|
James,
Most definitely. We've been looking at Esper for a while now, just haven't had the time to prototype any implementations yet. I've met with a few people who've suggested it as well last time I were in New York, so we'll try to integrate it soon. I created an RFE to track it: http://trac.marketcetera.org/trac.fcgi/ticket/435. Great suggestion! On 10/10/07, James Webster <[hidden email]> wrote: > Are there any plans to integrate a CEP/ESP product like Esper into > Marketcetera? > > http://esper.codehaus.org/ > > > On 10/9/07, Toli Kuznets <[hidden email]> wrote: > > Brett, > > > > These are all excellent suggestions. I see that you've created a few > > Trac tickets for these, thanks a lot, it helps us with tracking the > > RFEs and lets others add their ideas a well. > > > > Others on the list, do you have any comments on these features? > > > > I like the "system tray" notification for rejected orders, or small > > fading popup at the bottom (the way Trillian and other IM clients > > signal new messages). What about others? what do you > > think/prefer/suggest? > > > > What do others think of the input methodology RFEs? Combo boxes or > > radio buttons? > > Hot keys for all the fields in the order ticket? or is that overkill? > > > > let me know... > > > > and don't forget that you can see all the RFEs at > > http://trac.marketcetera.org/trac.fcgi/report/1 > > Let me know when you register on Trac so that i can give you ticket > > edit privileges if you want to add comments (or login as anon/market, > > see > http://trac.marketcetera.org/trac.fcgi/wiki/Marketcetera/NewTicket). > > > > thanks again for taking the time to give us feedback! > > > > On 10/4/07, Brett Rogers <[hidden email]> wrote: > > > After experimenting with the platform for the last few months, and going > > > live with it as of September, I've got a few design / feature > suggestions. > > > I considered sending these directly to the development team, but with at > > > least a couple of the items I'm not entirely sure what the ultimate > optimal > > > solution should be, so thought that the mailing list might be a better > place > > > to start. I'll start with Equity Order issues. > > > > > > > > > - For single order entry using the Stock Order Ticket, I'd like to > > > streamline the input methodology. > > > For mouse entry, I'd like to see: > > > - Radio buttons instead of pull-down menus for Side, Time in Force, > > > Order Type. I find radio buttons faster than pull-down menus because > > > (a) they're fewer clicks > > > (b) one glance at the order ticket gives you an idea where > each of > > > your choices can be clicked (vs. hunting one-by-one through pull-downs) > > > - Clickable default sizes in or near the Quantity field, and > clickable > > > default prices (would require price feed integration) in or near the > Price > > > field > > > - Up / Down arrow buttons in the Quantity and Price fields that can > be > > > clicked to quickly adjust by default (or configurable) increments > > > > > > > > > For keyboard entry, I'd like to see: > > > - For the radio button sections, ability to both use hot keys to > jump > > > right to a choice, and arrow keys to navigate > > > - Up / Down arrow keys function like the Up / Down arrow buttons > above > > > > > > (Generally speaking, if I go Keyboard, I'd like to be able to go > > > All-Keyboard. If I go Mouse, I'd like to be able to go as All-Mouse as > I > > > can. I find that shifting between input methodologies in the same order > > > adds a lot of time.) > > > > > > > > > - I'd like to see Configurable Defaults for the Order Tickets. > > > - Quantity and Time in Force are the obvious early candidates > > > - Routes and Up / Down Increments would also be very helpful > > > - Configurable Defaults for Price and Quantity warnings (too far > away > > > from the market, or too many shares) would be extremely helpful > > > > > > > > > - I'd like to see better ways to notice rejected orders (I'm uncertain > about > > > the best ways to accomplish this however). > > > - Rejects tab that bolds or highlights with new reject information? > > > - Order highlights in Open Orders tab for some time frame? > > > - Plays distinctive (and configurable) sound file? > > > - Menu bar flashes when unacknowledged rejects exist? > > > - Small message appears above system tray (I think MSFT now calls > this > > > the "notification area")? > > > - Others ideas / suggestions? > > > - I should note that I loathe pop-up windows > > > > > > - I'd like to see a cross-route Cancel / Replace option > > > - Most OMS that I've used allow for exchange-level Cancel / Replace > > > orders. It's a specific order type in which the exchange handles the > > > logical heavy lifting (ensuring no double-fills, etc.) > > > - I'd like to be able to Cancel / Replace between exchanges. For > > > example, I might try to lift an offer on a secondary exchange, but miss > it. > > > I would still like to work the order, but now I'd prefer to leave it on > a > > > more liquid exchange. I'd like to Cancel / Replace the order, switching > > > exchanges. > > > - The logic would have to operate at the level of the Marketcetera > > > platform - the platform would not be able to send a Cancel / Replace > order > > > itself, but rather a cancel to one exchange, wait for an out, and then > > > originate a new order to a second exchange (and link these orders > internally > > > in a way that the platform and the user both understand). > > > > > > > > > That's it for now. Comments welcome. I'll have more input in the > coming > > > days, rest assured. > > > > > > _______________________________________________ > > > 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 > > > > > > -- > James Webster SA Fin > blog: http://www.thenewsbeforethenews.com photos: > http://flickr.com/photos/jim > twitter: http://twitter.com/jimmcslim > _______________________________________________ > 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 |
||||||||||||||||
Grigory Kagan
|
Toli,
How are you? Integrating a CEP/ESP product like Esper into Marketcetera, adding event driven trading feature, would definitely open new horizons for your creation. Although it sounds like fun, there are many key points to worry about, where the most important one - user friendliness. For example, there is a need for ESQL console to create models. And, what to do down the road when users would decide to build federated model (combined model)? Some CEP product's links: http://www.streambase.com - very popular and expensive :) (java) http://www.aleri.com - less popular (not java) http://www.coral8.com - relatively new, but looks promising (not sure) http://www.streamcruncher.com/ - another interesting open source solution (java) Keep in touch, GK On 10/10/07, Toli Kuznets <[hidden email]> wrote:
James, -- "The world is a dangerous place to live, not because of the people who are evil, but because of the people who don't do anything about it." --Albert Einstein-- _______________________________________________ m-etc-users mailing list [hidden email] http://lists.marketcetera.org/cgi-bin/mailman/listinfo/m-etc-users |
||||||||||||||||
|
toli
|
Grigoriy,
Thanks for the additional links - i've updated the bug. We'll take a look at these once we start integrating Esper. On 10/10/07, Grigory Kagan <[hidden email]> wrote: > Toli, > How are you? > Integrating a CEP/ESP product like Esper into Marketcetera, > adding event driven trading feature, > would definitely open new horizons for your creation. > > Although it sounds like fun, there are many key points to worry about, > where the most important one - user friendliness. > > For example, there is a need for ESQL console to create models. > And, what to do down the road when users would decide to build federated > model (combined model)? > > Some CEP product's links: > http://www.streambase.com - very popular and expensive :) (java) > http://www.aleri.com - less popular (not java) > http://www.coral8.com - relatively new, but looks promising (not sure) > http://www.streamcruncher.com/ - another interesting open source solution > (java) > -- 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 |
||||||||||||||||
dumitriu
|
In reply to this post
by Grigory Kagan
Actually, I am also particularly interested in such a feature. My use case is fairly straightforward. I would like the OMS to listen to market data, and set cancellation rules for outstanding orders based on market movements.
Cheers, Dan
|
||||||||||||||||
gm-mrktc
|
Some javascript/style in this post has been disabled (why?)
Certainly this is exactly the type of trading that we are trying to facilitate. Currently the OMS is responsible for message routing and modification for the purposes of regulatory, reporting and error checking. The higher level abilities to initiate, manage and cancel orders are currently the domain of the trading algorithms that you build on top of our platform, whether as part of the Photon application, or using our integration tools for other languages and development environments.
As we build out our platform we are beginning to provide some pre-canned functionality for trading logic, but this is still evolving. graham On 10/24/07,
dmd <[hidden email]> wrote:
-- Marketcetera Trading Platform download.run.trade. www.marketcetera.org _______________________________________________ m-etc-users mailing list [hidden email] http://lists.marketcetera.org/cgi-bin/mailman/listinfo/m-etc-users |
||||||||||||||||
|
gm-mrktc
|
In reply to this post
by Grigory Kagan
Some javascript/style in this post has been disabled (why?)
Grigory,I would very much like to hear more about what you think the correct way to do this is. I think that I would like to do an Esper integration in the near future. This seems to be the best choice on the open-source side for CEP, do you agree? What do you think is the minimal amount of CEP functionality required for it to be useful. That is, I don't think we can get a nice query builder up and running in short order, so I'd be interested to hear what your thoughts are. graham On 10/10/07, Grigory Kagan <[hidden email]> wrote: Toli, -- Marketcetera Trading Platform download.run.trade. www.marketcetera.org _______________________________________________ m-etc-users mailing list [hidden email] http://lists.marketcetera.org/cgi-bin/mailman/listinfo/m-etc-users |
||||||||||||||||
Andrew M-2
|
In reply to this post
by gm-mrktc
I am in the process of implementing these ideas and would really like
feedback or suggestions. I am still thinking about how I can best fit these ideas in with marketcetera. A diagram is here: http://www.nmedia.net/~andrew/tmp/fix_visio.jpg I want both traders and automated trading strategies written in various languages to be able to direct orders to multiple geographically diverse exchanges. I also need a centralized picture of the firm’s positions. This may mean placing standardized orders on a messaging bus. Putting serialized java order objects on the bus is attractive except that it excludes non-Java trading strategies. I want to be able to extend the order messages to handle various asset classes. The system should be independent of any particular protocol for exchange communication (FIX, CBOE CMI, ISE OTS, etc.). An objective is to reduce latency by locating trading logic as physically close as possible to the relevant exchange. Message brokers need to be configured so that orders and market data only traverse WAN links if there is a subscriber on the other end. The risk management and position management applications would subscribe to all order messages sent to and received from all exchanges. A trading strategy running in London might only use LSE market data and would only subscribe to messages resulting from its own orders so this strategy’s nearest message broker would place outbound order message traffic on the wan but receive no inbound messages. I’m looking at using networked message brokers like Apache ActiveMQ, Red Hat Messaging(Apache Qpid based), JBoss Messaging, RabbitMQ, or OpenAMQ. It looks like I can achieve some of the platform independence I want by using ActiveMQ with OpenWire as its wire protocol. AMQP based messaging would give more platform independence than OpenWire based messaging. Red Hat Messaging should eventually provide good performance on linux by being tied closely to the kernel. A much simpler system could be designed with a single location seeing all market data, operating all trading logic and generating all orders. Going the more complex route of using message brokers near each exchange location should reduce WAN bandwidth requirements and latency as long the dispersed trading strategies are not required to update the central positon/risk mgmt piece transactionally. Then again... Maybe the system should not have strategies placing order messages on an enterprise messaging bus at all. Maybe instead of placing a message broker and trading logic as close as possible to each exchange there should be trading logic and a full j2ee application server there instead. FIX(and other protocol) servers would use RMI to call methods on EJBs representing orders or collections of orders. J2EE servers would be present as near as possible to each exchange and be clustered via WAN links. This could provide a persistent, unified view of the firm’s position from any server in the cluster. Maintaining that cohesive picture in realtime might introduce unacceptable latency just as doing so would with a message broker only system. Persisting the trade blotter is important. If a machine goes down it needs to know what positions existed and which orders were open when it went down. If fills took place when it was down it needs to receive those fills and update the positions accordingly. Thus communication between the FIX(or other protocol) engines and the order management system needs to be transactional. It probably makes sense to use a j2ee server to persist the positions. The app server would receive guaranteed delivery of trade messages and transactionally update the firm position. Other thoughts…** *Not using centralized risk management* Order messages are placed on the messaging bus and directed to the appropriate exchange. A copy of the order also simultaneously goes to the centralized trade blotter where it is persisted. *Using centralized risk management* Sources of orders include traders and algorithms. Traders generate "unapproved" orders which are directed to central risk mgmt system for approval. Risk mgmt system sends approved orders to the appropriate exchange for execution. Algo orders don’t need risk mgmt system approval. Copies of algo orders go to the exchange for execution and the position mgmt(trade blotter) system simultaneously. Thanks for any suggestions or ideas… Andrew _______________________________________________ m-etc-users mailing list [hidden email] http://lists.marketcetera.org/cgi-bin/mailman/listinfo/m-etc-users |
||||||||||||||||
|
toli
|
Andrew,
Apologies for taking so long to reply - your email was buried in our spam folder since it wasn't sent form an account that was signed-up with the mailing list. First of all, thanks for you interest in Marketcetera - it seems that the Marketcetera Platform is very similar to what you have on your diagram - the OMS has an embedded ActiveMQ broker (your message bus), we are built on top of QuickFIX/J and have adapters for C/C++/.NET/etc. So i'm sure that we can find a way for you to leverage the Marketcetera Platform to build your system. We've designed the platform to be flexible with these considerations in mind, to allow people to build systems similar to what you are describing. Let me try to answer your questions. > I want both traders and automated trading strategies written in various > languages to be able to direct orders to multiple geographically diverse > exchanges. I also need a centralized picture of the firm's positions. .. > CBOE CMI, ISE OTS, etc.). An objective is to reduce latency by locating > trading logic as physically close as possible to the relevant exchange. If you are doing mostly US trading (or to cover all of US), you may want to consider colocating your server just in the NYSE SFTI datacenter (http://www.nysetransacttools.com/sfti/co-location.php ). You get access to all the US exchanges and some of Europe as well - it may be easier than colocating near each US exchange. > wan but receive no inbound messages. I'm looking at using networked > message brokers like Apache ActiveMQ, Red Hat Messaging(Apache Qpid > based), JBoss Messaging, RabbitMQ, or OpenAMQ. It looks like I can > achieve some of the platform independence I want by using ActiveMQ with > OpenWire as its wire protocol. AMQP based messaging would give more > platform independence than OpenWire based messaging. Red Hat Messaging > should eventually provide good performance on linux by being tied > closely to the kernel. We've had very good experience with ActiveMQ; and our .NET/COM integration uses the OpenWire protocol. ActiveMQ is a very stable project that has been around for a while, and we haven't had any issues with it. I think RedHat Messaging (and Qpid) may be still too early to be used for anything in production. We are very excited about the Qpid project though, and have been monitoring it to a see when it makes sense to integrate that into the platform. > instead. FIX(and other protocol) servers would use RMI to call methods > on EJBs representing orders or collections of orders. J2EE servers would > be present as near as possible to each exchange and be clustered via WAN I think using the EJB/J2EE framework and using RMI to call into it may be overkill, will make the entire system overly complex and add way too much latency into your application. I think you should design the system to take that possibility into account in the future, but i wouldn't over-engineer anything from the very beginning - you may find out that you over-optimized something that wasn't a bottleneck. > Persisting the trade blotter is important. If a machine goes down it > needs to know what positions existed and which orders were open when it > went down. If fills took place when it was down it needs to receive > those fills and update the positions accordingly. Thus communication > between the FIX(or other protocol) engines and the order management > system needs to be transactional. It probably makes sense to use a j2ee > server to persist the positions. The app server would receive guaranteed > delivery of trade messages and transactionally update the firm position. Persistence is a whole other matter - if you can probably use the J2EE architecture here if you want, or write stuff out directly to the database. If you can offload the persistence to a different thread (or machine) to remove this task from the critical path, you can definitely use something like J2EE w/out worrying about latency too much. Let me know if you have any other questions, and would be happy to get you started on the Marketcetera Platform and to help you see how you can use it to build your system. -- 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 |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
