StreamInsight: Rx and Adapters
Over the last few evenings I’m managed to move the Strategy Pricer on somewhat. To fully prove out StreamInsight I needed to implement a market to allow round-tripping of orders. To simply my life, I decided to develop an input/output adapter that would handle my view of a market, this forcing me into the adapter world of StreamInsight.
When implementing your own adapter, you need to implement a factory for the adapter creation. Your factory need to implement IInputAdapterFactory or IOutputAdapterFactory depending on if your developing an input or output adapter.
The adapter itself needs to derive from an appropriate base class based on the event type you are going to be using e.g. TypedPointInputAdapter, TypedEdgeOutputAdapter etc. Now since I’m a bit of an Rx fan I obviously going to use Rx in the input adapter to subscribe to events coming in, and push them into StreamInsight. Going from the StreamInsight input adapter samples, I need to effectively make a subscription in ProduceEvents(), whereas the samples execute a while(true) loop. You need to remember to dispose of the subscription on the adapter stopping.
From a Linq perspective, I’ve found it easier to break the overall expression into smaller pieces and filter (Where clause) before doing a join – it makes life easier from the Event Flow debugger as well.
Things I’d like the StreamInsight team to consider:
- The Adapter design just doesn’t feel right when used from an Rx perspective – maybe its my code, but I just feel I have to write to much code when implementing a simple adapter
- The restriction on atomic .NET data type with say UDF’s are painful. StreamInsight needs support for upport complex data types prior to a 1.0 release
- Command line passing of an .ETL filename for the StreamInsight Even Flow Debugger
- Ability to send though lists etc in the event payload
- Add an asyn input adapter to the samples ideally with Rx usage
