Wednesday, August 11, 2010

Building your First End to End StreamInsight Application (Going Deep on Adapters)

So you’ve heard about this shiny StreamInsight thing, perhaps from my last post, and want to build something for yourself and understand how all of this stuff fits together.  At this point you should have your Visual Studio environment up and running, along with StreamInsight installed (if you don’t, have a look at this post).  Every StreamInsight application consists of the following core components:
1643.image_5F00_thumb_5F00_3E133118.png

Input adapters.  Input adapters provide the interface for collecting data from a variety of sources (web services, databases, data feeds, sensors).  A StreamInsight input adapter is a set of .NET classes implementing a set of interfaces.
They can be typed or untyped.  Typed adapters have a fixed (or known at compile time) input data type, whereas untyped adapters infer their type at runtime based on configuration information.  For example, a SQL Server input adapter would infer a data type based on a SELECT statement, stored procedure, etc, given to it at runtime.
Queries.  Standing queries define the questions being asked of the data streaming through.  Queries can be chained together, with a complete end to end query consisting of a set of input adapters, series of queries, and a set of output adapters.
Queries are defined in StreamInsight’s flavour of LINQ (lots more later).
Output adapters.  Output adapters provide the interface for delivering query results to external systems and applications.  Output adapters are the mirror image of input adapters (i.e. can be typed or untyped, etc).
Host.  StreamInsight supports a variety of deployment models to best suit the needs of your application or deployment.  The API (i.e. all of the StreamInsight code) can target an in-process “embedded” StreamInsight server, or a remote server (typically hosted in a Windows Service, such as the StreamInsightHost.exe that ships with StreamInsight).
Read more: StreamInsight Factotum