Now that you know the StreamInsight metadata (see inside the metadata), its fairly easy to take apart the implicit model because you already know which objects are being created for you. In the implicit development model, you:
1. Create a CepStream for input – specifying
EventType as a template parameter
Event Shape (Point, Edge, or Interval)
Factory class of the input adapter
Config info for the adapter
2. Build your LINQ query over the stream
3. Call Stream.ToQuery on input stream – specifying
Factory class of output adapter
Output configuration
Output event shape
A stream event order
When calling Stream.ToQuery in step 3, the internals have all of the information to build the objects you need. That one call:
Implicitly creates Server and Application
Registers and configures Adapters, QueryTemplate (from step 2), EventType info.
Binds the adapters to the QueryTemplate producing the Query.
All you need to do is start the query. Just to prove that the entire object model is in place, you can use the references to navigate from the Query instance back to the Server, and retrieve the diagnostic information, just like in the Explicit Model. Using the ImplicitServer sample…
Query query = ConsumeQuery(top); // step 3 – see above, now add the following code.
//Now, get the Server
Server server = query.Application.Server;
At the end of the run, you can use your server instance to get the diagnostic views. Cribbing a little code from the ExplicitServer…
RetrieveDiagnostics(server.GetDiagnosticView(new Uri("cep:/Server/EventManager")), tracer);
RetrieveDiagnostics(server.GetDiagnosticView(new Uri("cep:/Server/PlanManager")), tracer);
// View for your query from Stream.ToQuery
RetrieveDiagnostics(server.GetDiagnosticView(query.Name), tracer);
The main differences between this model and the explicit server model are:
Because you're not instanciating the server, you don't specify server options or use Server.Connect
Because you didn't name some of the objects (because you didn't register them yourself), it would be more difficult to reuse them in a robust manner. If you're going to go the trouble of trundling through collections or depending on registration order (if this would work), you might as well use the explicit model. If you look at the query.Name, for example, you can see that the implicit model has made the application name "default" and the query name "DefaultQuery".
But its still the same object model.