Extensibility/configuration questions

Hi, we are starting to evaluate MarketCetera, I have some questions about how flexible some parts of it can be:
1. We are using MRG RedHat for messaging
It is based on Apache Qpid porject, which is opens source implementation of AMQP protocol. There is a JMS compliant implementation for a client.

Question: since MarketCetera chose ActiveMQ as underlying messaging protocol, how easy would be to have MarketCetera/AMQP setup?
Are you considering supporting AMQP?

2. QuickFIX/J
MarketCetera uses QuickFIX/J internally. While being open-source QuickFIX/J lags in speed considerably versus C++ counterpart. How deeply wired is MarketCetera with QuickFIX/J and what would it entail to use a different FIX engine?
Do you think this makes sense? It is like bundling MySQL but providing JDBC protocols if people want to use a different database, I think it would be great to have some connectivity layer that can encompass different FIX engines

3. How do objects are passed between components (not FIX messages)? Is it some sort of serialized Java objects or XML? I could use clients written in different languages if object are passed in language-neutral format

4. Last but not least, could you point me to some benchmarks of ORS system - throughput, latency?

Regards,
Slava

This message was edited 1 time. Last update was at 01/09/2009 22:44:15

Hi Slava,

Question: since MarketCetera chose ActiveMQ as underlying messaging protocol, how easy would be to have MarketCetera/AMQP setup?
Are you considering supporting AMQP?

It should be doable assuming AMQP is really JMS compliant and has similar capabilities as we are JMS compliant - we try to abstract away the fact that we are using ActiveMQ. Can you share why you would prefer using AMQP over ActiveMQ? Currently AMQP support is not on our roadmap - but you should file an RFE here - especially if you have datapoints on why AMQP is better suited for the platform than ActiveMQ.

How deeply wired is MarketCetera with QuickFIX/J and what would it entail to use a different FIX engine?
Do you think this makes sense? It is like bundling MySQL but providing JDBC protocols if people want to use a different database, I think it would be great to have some connectivity layer that can encompass different FIX engines

That makes sense. We are considering building such a layer that will allow ORS to connect to FIX and non FIX destinations. In this context you will be able to use other FIX engines as well. Can you share your experience with other FIX engines and how those compare to QuickFIX/J?

How do objects are passed between components (not FIX messages)? Is it some sort of serialized Java objects or XML? I could use clients written in different languages if object are passed in language-neutral format

I assume you mean objects/messages passed between clients such as strategyagent and ORS? We use serialized XML on the wire for that. We do have client APIs (more details available here) that we ported to .NET for some customers (leveraging the fact that we use XML representation on the wire). Note that the XML objects on the wire format is not an official API (i.e., it is considered an "internal" protocol) and can change between releases.

4. Last but not least, could you point me to some benchmarks of ORS system - throughput, latency?

We didn't publish generic ORS throughput and latency data yet. It is hard to just publish such numbers without establishing the context and configuration especially since there are so many options and capabilities that affect the measurements. We do work with specific customer deployments to optimize those based on the features enabled/used, hardware, strategies, routing, etc. We continuously use those datapoints where applicable and other in-house performance benchmarks and tuning to improve overall "out of the box" platform performance. Any feedback/suggestions are always welcome.

Hi,
thank you for your reply.
Here are some clarifications to my previous questions:
1. AMQP
AMQP is becoming an open standard for messaging systems. Originally developed my JPChase out of frustration of TIbco, and extensively tested/used in production for mission critical systems, it was open sourced and now has backers such as Cisco Systems, Credit Suisse, Deutsche Börse Systems, GoldmanSachs etc. If you are presenting an open source trading system, that would be supported messaging layer expected by many people looking at it. Right now it is a flagship messaging product at RedHat, and they expect to push it for entering financial markets.
2. Other FIX engines
I worked on a real project where initially we used QuickFIX/J and just could not get benchmarks where we wanted them. We wrote a FIX abstraction level, and started using Appia (just as example) as a FIX engine. We got x10 speed improvement for free. QuickFIX is just a 3rd party library for MarketCetera, it should not be inseparable component.
Also check out RapidAdditon, they have the fastest FIX engine on earth. I would see no reason MarketCetera would be inherently incompatible with it. QuickFIX/J is just functionally complete, nobody was saying it is fast (and btw it is considerably slower than QuickFIX in C++, we did the benchmarking)
3. Formats
As for formats, it is fine if you have .NET librariesa
4. Benchmarks
Benchmarks are really important, and I believe if you use different messaging/fix engine, you will see a noticeable improvement there as well.
Apart from that, you could describe some generic scenarios, simplest algos and some throughput values - people pay attention to that and nobody wants to start committing to the system that it is clear form the beginning would not perform adequately.

Please let me know if that makes sense, we are a small hedge fund looking at your system but some things need to be clarified there for us

Regards,
Slava

Slava,

Thanks for the feedback and information and for sharing your experience per AMQP and FIX engines.

Thanks,
Yoram

Footer Links