Too start with its fantastic to see an open source system which has abstract components which the end user can tailor for their own requirements.
I had a question regarding live data. My understanding to build our own live data server we can extend the StandardLiveDataServer abstract class. Would that be correct?
If we had to build a LiveDataServer which based on Product type would be able to determine which vendor to subscribe. e.g. for Bonds --> Bloomberg, Equities --> Reuters… etc. This would give additional flexibility to clients to chose multiple vendors. I understand that open gamma is not built just to provide live data and this may be an over-engineered solution. Do you think this would be possible and would appreciate getting your had thoughts on this.
My initial thoughts are
The subscription object looks generic enough to handle this as it works with a security unique id. (The ticks are also stored in the FieldHistoryStore in the subscription object)
When overriding subscribe and unsubscribe we could have strategies to determine which vendor to subscribe with.
However, the method to determine the uniqueID is based on the method which returns ExternalScheme, getUniqueIdDomain i.e.
String securityUniqueId = fullyQualifiedSpec.getIdentifier(getUniqueIdDomain()) [StandardLiveDataServer:Subscribe(line 495)]. The unique Id this way is linked to the Server and not the product (or some other identifier).
Another alternative, maybe to implement multiple StandardLiveDataServers (for each required vendor) and build a layer on top which delegates responsibility to appropriate StandardLiveDataServer based on requirements (e.g. product), however in this case i believe we would have to move the Subscriptions(tick data) into this new layer as an aggregation point for subscriptions.
The other question was around load balancing and cache synchronization, As the cache is with the StandardLiveDataServer, if live data server is unavailable how would one load balance, would you envisage this to be custom implementation where the caches are kept synchronized across multiple nodes. (We would be expecting multiple clients outside of OpenGamma, hence availability/redundancy would be a key issue).
Thanks for your positive feedback and apologies for the delay in responding.
You are correct that to implement your own live market data server you would extend StandardLiveDataServer. Each live data server is intended to be responsible for handling market data requests for a specific ExternalId scheme - the one returned by getUniqueIdDomain(). This would normally be a Bloomberg or Reuters ID as you have probably seen in our Bloomberg implementation. Note that we also have a Reuters implementation which can be provided as part of a commercial licence.
I think the best approach here would be to keep the concept of separate live data servers and delegate to the one you want to use on the client side (i.e. the OpenGamma engine or other clients using OpenGamma live data). To do this you would need to implement a custom LiveDataClient that is able to delegate a subscription request to an appropriate underlying LiveDataClient (e.g. Bloomberg or Reuters). Each subscription request is represented by a LiveDataSpecification from which you can obtain an ExternalIdBundle of the target. To classify the target, you could use the ExternalIdBundle to attempt to look up a security in the SecurityMaster to inspect its type. Not all targets will be (or can be) in the SecurityMaster, so you might need to fall back to something like our BloombergSecurityTypeResolver which performs a reference data lookup.
Hope that helps. Please let us know if you have any more questions.
Ideally i wanted to keep the client agnostic of the feed implementation. A security might be part of a larger cache of instruments from which a client can request/subscribe. (Making the vendors easily pluggable without the downstream clients being affected).
In this case you would want to implement a custom StandardLiveDataServer that is able to do the delegation on the server side to some underlying provider-specific StandardLiveDataServers. The same kind of logic for classifying the incoming subscription request could be used here too but the clients would only know about your implementation.
We have a PriorityResolvingCombiningLiveDataServer which might give you some ideas. This is similar, except that it allows subscriptions to fall through to the first underlying server that can satisfy the subscription.