At first sight, StreamInsight doesn’t appear to offer any support for dynamic queries. Once you have got over the initial ’wow’ factor of creating continuous queries over streams using LINQ, rather than some SQL dialect or specialised DSL, the reality hits you that your query is just code. You wrote the LINQ using C# or VB.NET, and you ended up compiling it into some assembly.
That’s all very well, but it’s not very flexible. How are you going to store and manage your queries in a repository so that you can review, change and version them? Does Microsoft really expect you to recompile and re-deploy assemblies every time you want to create or change a query in StreamInsight? Surely you should be able to dynamically deploy queries straight from a repository.
Have no fear. All is well. The QueryTemplate is serialisable. It isn’t serialisable in the .NET sense (i.e., it isn’t marked up as serilaisable, and it doesn’t implement ISerializable). Rather, it implements the QueryTemplate.Definition property which returns an XML document containing a complete rendering of your template, complete with a full dataflow and all the operators. To deserialise the XML, you use Application.CreateQueryTemplate. You have to pass in an XmlReader that you have created over the XML. You get back a clone of the original QueryTemplate which you can now bind to input and output adapters and emit to the engine as a Query. Nothing could be simpler.
There are a couple of gotchas. First, don’t do what I did while experimenting. I created a QueryTemplate and serialised it to XML. I then tried to deserialise it as a second, identical, QueryTemplate in the same Server instance. I got back an InvalidDefinition error. It seems you can’t have identical QueryTemplates in a single StreamInsight Server instance.
The second thing to note is that the serialised QueryTemplate does not contain fully qualified references to your event types. You still have to define the event types in your application by calling the CreateEventType method. If you plan to store QueryTemplate XML in some custom repository, you will also need to store the fully qualified names of the .NET types your have defined for your events. Of course, you will also need to ensure that these types are available at runtime.
Much the same argument applies to adapters. The QueryTemplate XML does not contain any information on which input and output adapters you want to bind to your query. However, once you realise that your QueryTemplates are serialisable, it is simple to work out how you might store and manage the template in some repository together with event type and adapter information. All this information, taken together, defines the StreamInsight concept of a query. You can write code to extract it from the repository at run-time and run the query.
The current CTP is just a glorified SDK. Will Microsoft provide a repository and tooling in the release version? I have no idea. Given the freedom StreamInsight offers in terms of event definition, and given the fact that the engine can be hosted in custom applications, it is difficult to see how Microsoft could provide a totally generic end-to-end solution that would support externalisation of queries in any and all circumstances. They could provide a repository and API, and leave it to developers to write the code to exploit the repository. However, you would still need to write the LINQ together with code to create QueryTemplates and extract and upload XML to the repository.