Este artigo foi traduzido por máquina.

StreamInsight

Grandes fluxos de dados mestre com Microsoft StreamInsight

Rob Pierry

[Baixar o código de exemplo](http://archive.msdn.microsoft.com/mag201106streaminsig)

Descobrir que a linha de produção baixou, fluxos de mídia dos usuários estão ignorando ou um dos seus produtos tornou-se um "deve ter" é fácil uma vez que isso já aconteceu. O truque real é identificar esses cenários como eles acontecem ou mesmo prevendo-los com base em tendências passadas.

Com êxito prever cenários como estes exige uma abordagem quase em tempo real. Quando dados relevantes são extraídos, transformados e carregados em uma solução de tradicional business intelligence (BI) como o SQL Server Analysis Services (SSAS), a situação mudou há muito tempo. Da mesma forma, qualquer sistema que se baseia em um padrão de solicitação-resposta para solicitar dados atualizados de um armazenamento de dados transacionais (tais como um SQL Server Reporting Services, ou SSRS, relatórios) são sempre operando em dados obsoletos perto do final do seu intervalo de sondagem de solicitação. O intervalo de sondagem é normalmente corrigido, por isso mesmo se ocorre uma explosão de atividades interessantes, o sistema consome não saberá até o próximo intervalo vem ao redor. Em vez disso, deve ser notificado continuamente o sistema consome o momento interessante os critérios.

Quando detectar tendências emergentes, intervalos de tempo são chave — 100 compras de um item específico nos últimos cinco minutos é claramente um indicador maior de uma tendência emergente do que um gotejamento constante nos últimos cinco meses. Os sistemas tradicionais como SSAS e SSRS exigem o desenvolvedor acompanhar a actualidade dos dados por conta própria, através de uma dimensão separada em um cubo ou uma coluna de carimbo de hora em um armazenamento transacional. Idealmente, ferramentas para identificar cenários emergentes teria o conceito de tempo interno e oferecem uma rica API para trabalhar com ele.

Finalmente, um bom indicador do futuro vem da análise do passado. Na verdade, este é o BI tradicional é toda sobre — agregar e analisar grandes volumes de dados históricos para identificar tendências. Infelizmente, diferentes ferramentas e linguagens de consulta são envolvidas ao usar esses sistemas quando comparado aos sistemas mais transacionais. Identificando com sucesso cenários emergentes requer perfeita correlação de dados passados e presentes. Este tipo de integração só é possível quando as mesmas ferramentas e linguagem de consulta são usados para ambos.

Para cenários específicos tais como linha de produção ferramentas personalizadas de monitorização, altamente específicas existem para executar essas funções, mas essas ferramentas são muitas vezes comparativamente cara e não geral finalidade.

Para evitar que a linha de produção vai para baixo ou para certificar-se de que seus produtos são preços adequadamente, a chave deve ser ágil o suficiente para identificar e ajustar como as alterações da situação. Facilmente e rapidamente identificar esses cenários, consultas históricas e em tempo real devem usar os mesmos desenvolvedor-friendly conjuntos de ferramentas e linguagens de consulta, o sistema devem lidar com grandes volumes de dados em tempo quase real (da ordem de centenas de milhares de eventos por segundo), e o motor deve ser flexível o suficiente para lidar com cenários através de um vasto conjunto de áreas problemáticas.

Felizmente, existe esta ferramenta. É chamado Microsoft StreamInsight.

Visão geral da arquitetura do StreamInsight

StreamInsight é um mecanismo de processamento de eventos complexo capaz de lidar com centenas de milhares de eventos por segundo com latência extremamente baixa. Pode ser hospedado por qualquer processo, tais como um serviço do Windows, ou incorporada diretamente em um aplicativo. StreamInsight tem um modelo simples adaptador para obtenção de dados dentro e fora, e consultas sobre dados históricos e em tempo real usam a mesma sintaxe do LINQ acessada apenas como qualquer outro assembly de qualquer Microsoft.NET Framework idioma. Ele é licenciado como parte do SQL Server 2008 R2.

A arquitetura de alto nível de StreamInsight é bastante simple: eventos são coletados de uma variedade de fontes através de adaptadores de entrada. Esses eventos são analisados e transformados através de consultas, e os resultados das consultas são distribuídos aos outros sistemas e pessoas através de adaptadores de saída. Figura 1 mostra essa estrutura simple.

High-Level Architecture of Microsoft StreamInsight

Figura 1 arquitetura de alto nível da Microsoft StreamInsight

Da mesma forma que arquiteturas orientadas a serviço estão preocupadas com mensagens e sistemas de banco de dados estão preocupados com linhas, sistemas de processamento de eventos complexos como StreamInsight são organizados em torno de eventos. Um evento é um simples pedaço de dados juntamente com o tempo em que esses dados são relevantes — como um sensor de leitura em um determinado momento do dia ou um preço de cotações da bolsa. Os dados transportados pelo evento são chamados de sua carga.

StreamInsight oferece suporte a três tipos de eventos. Ponto eventos são eventos que são instantâneas e não tem nenhuma duração. Intervalo eventos são eventos cujas cargas são relevantes para um período específico de tempo. Eventos de Borda são semelhantes aos eventos de intervalo, exceto a duração do evento não é conhecida à chegada do evento. Em vez disso, o horário de início é definido e o evento efetivamente tem duração infinita até que chega um outro evento de borda que define o tempo final. Por exemplo, uma leitura do indicador de velocidade pode ser um evento de ponto porque ele muda constantemente, mas o preço do leite no supermercado poderia ser um evento de borda porque ele é relevante para um período mais longo de tempo. Quando o preço de venda a retalho de leite altera (digamos, devido a uma alteração no preço de distribuidor), a duração do novo preço não é conhecida, portanto, um evento de borda é mais apropriado do que um intervalo de um. Mais tarde, quando o distribuidor atualiza seus preços novamente, um novo evento de Borda pode coroar a duração da mudança de preço anterior enquanto outro evento de borda será definido um novo preço vai para a frente.

Adaptadores de entrada e saídas em StreamInsight são um exemplo abstrato do padrão de design de adaptador. O mecanismo de StreamInsight opera em sua própria representação de eventos, mas as fontes reais desses eventos podem variar descontroladamente, variando entre uma interface proprietária e um sensor de hardware para mensagens de status gerado pelos aplicativos da empresa. Adaptadores de entrada transformam os eventos de origem em um fluxo de eventos que compreende o mecanismo.

Os resultados de consultas de StreamInsight representam o conhecimento de negócios específicas e podem ser altamente especializados. É importante que estes resultados ser encaminhados para o local mais adequado. Adaptadores de saída podem ser usados para ativar a representação interna de um evento em texto impresso ao console, uma mensagem enviada via Windows Communication Foundation (WCF) para outro sistema para processamento, ou até mesmo um ponto em um gráfico em um aplicativo Windows Presentation Foundation. Adaptadores de amostra para trabalhar com arquivos de texto, WCF, SQL e muito mais estão disponíveis no streaminsight.codeplex.com.

StreamInsight consultas por exemplo

À primeira vista, StreamInsight consultas aparecem semelhantes ao consultar as linhas de um banco de dados, mas há diferenças essenciais. Ao consultar um banco de dados, a consulta é construída e executada e os resultados são retornados. Se os dados subjacentes forem alterados, a saída não é afetada porque a consulta já foi executado. Resultados da consulta de banco de dados representam um instantâneo de um momento no tempo, disponível via o paradigma de solicitação-resposta.

StreamInsight consultas são consultas permanente. À medida que novos eventos entrados chegam, a consulta continuamente reage e novos eventos de saída são criados, se necessário.

Os exemplos de consulta neste artigo são desenhados a partir da solução de exemplo disponível para download. Eles começam simplesmente, mas crescem mais poderosos como novos recursos de linguagem de consulta são introduzidos. As consultas todos usam a mesma classe para a carga. Aqui é a definição de uma classe simple com propriedades para região e valor:

public class EventPayload {
  public string Region { get; set; }
  public double Value { get; set; }

  public override string ToString() {
    return string.Format("{0}\t{1:F4}", Region, Value);
  }
}

As consultas no aplicativo de exemplo fazem uso de um adaptador de entrada que gera aleatoriamente dados e um adaptador de saída que simplesmente escreve cada evento para o console. Os adaptadores no aplicativo de exemplo são simplificados para maior clareza.

Para executar cada consulta, descomente a linha no arquivo Program. CS na solução de amostra que atribui a consulta para a variável local denominada "modelo".

Aqui está uma consulta básica que filtra os eventos pela propriedade Value:

var filtered =
  from i in inputStream
  where i.Value > 0.5
  select i;

Esta consulta deve parecer familiar para qualquer desenvolvedor com experiência usando LINQ. Porque StreamInsight usa LINQ como sua linguagem de consulta, esta consulta parece com um LINQ para consulta SQL bater uma filtragem de na memória de um IList ou um banco de dados. Como eventos chegar do adaptador de entrada, suas cargas são inspecionadas, e se o valor da propriedade Value é maior que 0. 5, são passados para o adaptador de saída onde eles serão impressos para o console.

Quando o aplicativo é executado, observe que eventos continuamente chegar na saída. Isto é, efetivamente, um modelo de envio. StreamInsight calcula novos eventos de saída de insumos como eles chegam, ao invés de um modelo de recepção que um banco de dados onde o aplicativo periodicamente deve sondar o fonte de dados para ver se chegou novos dados. Isso se encaixa bem com o apoio de IObservable disponível na Microsoft.NET Framework 4, que será posteriormente coberto.

Ter um modelo de envio de dados contínuos em vez de sondagem é agradável, mas o verdadeiro poder de StreamInsight se torna aparente quando consultar sobre propriedades relacionadas a tempo. Como eventos chegam através da placa de entrada, eles dão-lhe um timestamp. Esta timestamp pode vir da própria fonte de dados (suponha que os eventos representam dados históricos com uma coluna explícita armazenar o tempo) ou pode ser definido como o tempo chegou o evento. Tempo é, com efeito, primeira classe em linguagem de consulta de StreamInsight.

Consultas frequentemente olham como consultas de banco de dados padrão com um qualificador de tempo preso no final, tais como "a cada cinco segundos" ou "cada três segundos em um período de cinco segundos". Por exemplo, aqui está uma consulta simples que localiza a média da propriedade Value de cada cinco segundos:

var aggregated =
  from i in inputStream
    .TumblingWindow(TimeSpan.FromSeconds(5), 
    HoppingWindowOutputPolicy.ClipToWindowEnd)
  select new { Avg = i.Avg(p => p.Value)};

Windows de dados

Porque o conceito de tempo é uma necessidade fundamental para sistemas de processamento de eventos complexos, é importante ter uma maneira simples de trabalhar com o componente de tempo de lógica de consulta no sistema. StreamInsight usa o conceito de windows para representar agrupamentos por hora. A consulta anterior usa uma janela de tumbling. Quando o aplicativo é executado, a consulta irá gerar um evento de saída simples cada cinco segundos (o tamanho da janela). O evento de saída representa a média durante os últimos cinco segundos. Assim como em LINQ to SQL ou LINQ para objetos, agregação de métodos, como soma e média podem agregar eventos agrupados por hora em valores únicos, ou selecione pode ser usada para a saída do projeto em um formato diferente.

Tumbling windows são apenas um caso especial de outro tipo de janela: janela do salto. Hopping windows têm um tamanho, também, mas eles também têm um tamanho de salto que não é igual ao seu tamanho de janela. Isso significa hopping windows pode se sobrepõem uns aos outros.

Por exemplo, uma janela hopping com um tamanho de janela de cinco segundos e um tamanho de salto de três segundos irá produzir saída de cada três segundos (o tamanho de salto), dando-lhe a média sobre os últimos cinco segundos (o tamanho da janela). Lúpulo frente três segundos por vez e é cinco segundos de duração. Figura 2 mostra um fluxo de evento agrupado em caindo e pulando windows.

Tumbling and Hopping Windows

Figura 2 caindo e pulando Windows

Observe que o windows tumbling não se sobrepõem, mas os windows hopping podem se o tamanho do salto é menor do que o tamanho da janela. Se as janelas sobrepostas, um evento pode acabar em mais de um, como o terceiro evento, que é nas janela 1 e 2. Eventos de Borda (que têm duração) também podem se sobrepor limites de janela e acabar em mais de uma janela, como o segundo ao último evento na janela tumbling.

Um outro tipo de janela comum é a janela de contagem. Contagem windows contêm um número específico de eventos em vez de eventos em um determinado ponto ou a duração de tempo. Uma consulta para encontrar a média dos três últimos eventos que chegou usaria uma janela de contagem. Uma limitação atual do windows de contagem é que não há suporte os métodos de agregação internos como soma e média. Em vez disso, você deve criar um agregado definido pelo usuário. Este simples processo é explicado posteriormente neste artigo.

O tipo de janela final é a janela de instantâneo. Snapshot windows são mais fáceis de compreender o contexto dos eventos de borda. Sempre que um evento começa ou termina, a janela atual é concluída e começa uma nova. Figura 3 mostra como eventos de Borda são agrupados em windows de instantâneo. Observe como cada limite de evento aciona um limite de janela. E1 começa e assim faz w1. Quando começa a E2, w1 é concluída e w2 começa. A borda do próxima é E1 final, que conclui w2 e começa a w3. O resultado é três janelas: w1 contendo E1, w2 contendo E1 e E2 e E3 contendo w3. Uma vez que os eventos são agrupados em janelas, eles estão esticados para que pareça que o evento começa e termina quando a janela faz.

Snapshot Windows

Figura 3 Windows instantâneo

Consultas mais complexas

Tendo em conta estas janelas disponíveis e métodos de consulta básica como where, group by e order by, uma grande variedade de consultas é possível. Aqui está uma consulta que agrupa os eventos de entrada por região e, em seguida, usa uma janela hopping para a soma da carga do valor para cada região de saída para a última hora:

var payloadByRegion =
  from i in inputStream
  group i by i.Region into byRegion
  from c in byRegion.HoppingWindow(
    TimeSpan.FromMinutes(1),
    TimeSpan.FromSeconds(2), 
    HoppingWindowOutputPolicy.ClipToWindowEnd)
  select new { 
    Region = byRegion.Key, 
    Sum = c.Sum(p => p.Value) };

Essas janelas usam um tamanho de salto de dois segundos, então o engine envia eventos de saída cada dois segundos.

Porque os operadores de consulta são definidos na interface IQueryable, compor consultas é possível. O código a seguir usa a consulta anterior que encontra somas por região, em seguida, calcular a região com a maior soma. Uma janela de instantâneo permite que o fluxo de evento a ser classificados pela soma para que o método Take pode agarrar a região com a maior soma:

var highestRegion = 
  // Uses groupBy query 
  (from i in payloadByRegion.SnapshotWindow(
    SnapshotWindowOutputPolicy.Clip)
    from sumByRegion in i
    orderby sumByRegion.Sum descending
    select sumByRegion).Take(1);

Um cenário comum é uma consulta que prende-se com um fluxo de movimento rápido eventos (como a leitura de um sensor) para dados de referência movendo mais lento ou estáticos (como o local fixo do sensor). Consultas usam as associações para atingir esse objetivo.

A sintaxe da associação StreamInsight é o mesmo que qualquer outra junção LINQ, com uma ressalva importante: eventos serão apenas se unem se suas durações se sobrepõem. Se o sensor de 1 relata um valor no tempo (t1), mas os dados de referência sobre a localização de sensor de 1 só são válidos para tempo t2-t3, a junção não irá corresponder. Os critérios de junção de duração não está explicitamente escrito para a definição da consulta; é uma propriedade fundamental do mecanismo de StreamInsight. Ao trabalhar com dados estáticos, é comum para o adaptador de entrada tratar eficazmente os dados como eventos de borda com duração infinita. Desta forma, todas as associações para os fluxos de evento velozes terá êxito.

Correlacionar vários fluxos de eventos por meio de associações é um conceito poderoso. Linhas de montagem, instalações de produção de petróleo ou sites da Web de alto volume muitas vezes não falhar devido a eventos isolados. Uma peça de equipamento disparar um alarme de temperatura geralmente não traz a linha para baixo; é uma combinação de circunstâncias, tais como a temperatura que pode ser demasiado elevados durante um longo período de tempo, é uma ferramenta específica no uso pesado e os operadores humanos estão mudando turnos.

Sem as associações, os eventos isolados não teria tanto valor para os negócios. Usando junções e StreamInsight consultas sobre dados históricos, os usuários podem correlacionar fluxos isolados em critérios de monitoração altamente específicos que, em seguida, são monitorados em tempo real. Uma consulta permanente pode olhar para as situações que iria levar ao fracasso e automaticamente gerar um evento de saída que pode ser roteado para um sistema que sabe como tomar a peça superaquecimento de equipamentos off-line em vez de aguardar até que ele traz para baixo toda a linha.

Em um cenário de venda a retalho, eventos relacionados ao volume de vendas por item ao longo do tempo podem alimentar em sistemas e histórias de ordem do cliente para garantir preços ideal por item, ou para conduzir os itens que devem sugerir ao usuário antes de fazer check-out de preços. Porque consultas são facilmente criadas, modificadas e compostas, você pode começar com cenários simples e refiná-los ao longo do tempo, gerando cada vez mais valor para os negócios.

Agregados definidos pelo usuário

StreamInsight vem com várias das funções agregadas mais comuns incluindo contar, soma e média. Quando essas funções não são suficientes (ou você precisa agregar mais de uma janela de contagem, como mencionado anteriormente), o StreamInsight suporta funções agregadas definidas pelo usuário.

O processo de criação de um agregado definido pelo usuário envolve duas etapas: escrevendo o método aggregate real e, em seguida, expor o método para LINQ através de um método de extensão.

A primeira etapa envolve herdando de qualquer CepAggregate < TInput, TOutput > se a agregação não é dependente do tempo, ou CepTimeSensitiveAggregate < TInput, TOutput > se ele for. Essas classes abstratas tem um único método para ser implementado chamado GenerateOutput. Figura 4 mostra a implementação do agregado EveryOtherSum, que acrescenta-se todos os outros eventos.

Figura 4 EveryOtherSum agregado

public class EveryOtherSum : 
  CepAggregate<double, double> {

  public override double GenerateOutput(
    IEnumerable<double> payloads) {

    var sum = default(double);
    var include = true;
    foreach (var d in payloads) {
      if (include) sum += d;
      include = !include;
    }
    return sum;
  }
}

A segunda etapa envolve a criação de um método de extensão em CepWindow <TPayload> para que seu agregado pode ser usado em consultas. O CepUserDefinedAggregateAttribute é aplicado para o método de extensão para dizer StreamInsight onde encontrar a implementação do agregado (no caso, a classe criada na primeira etapa). O código para ambas as etapas deste processo está disponível no arquivo EveryOtherSum.cs no aplicativo de exemplo para download.

Mais informações sobre adaptadores

Consultas representam lógica comercial que atua sobre os dados fornecidos pelos adaptadores. O aplicativo de exemplo usa um adaptador de entrada simple que gera dados aleatórios e um adaptador de saída que escreve para o console. Ambos seguem um padrão semelhante, que também é seguido por adaptadores disponíveis no site da CodePlex.

StreamInsight usa um padrão de fábrica para criar adaptadores. Dada uma classe de configuração, a fábrica cria uma instância do adaptador apropriado. No aplicativo de exemplo, as classes de configuração para as placas de entrada e saídas são bastante simples. A configuração do adaptador de saída tem um único campo para conter uma seqüência de caracteres de formato para usar ao gravar a saída. A configuração do adaptador de entrada tem um campo para a hora de dormir entre gerando eventos aleatórios, bem como outro campo chamado CtiFrequency.

O Cti em CtiFrequency representa incremento de tempo atual. StreamInsight usa Cti eventos para ajudar a garantir que os eventos são entregues na ordem correta. Por padrão, o StreamInsight oferece suporte a eventos que chegam fora de ordem. O mecanismo será automaticamente encomendá-los adequadamente quando passá-los por meio das consultas. No entanto, há um limite para este reordenamento.

Suponha que eventos realmente poderiam chegar em qualquer ordem. Como ele jamais seria possível determinar que o evento mais antigo tinha chegado e, portanto, poderia ser empurrado por meio de consulta? Seria, porque o próximo evento pode ter uma hora mais cedo do que os mais antigos que já recebidas. StreamInsight usa eventos Cti para sinalizar o motor que não mais eventos chega mais cedo do que o que já foram recebido. Eventos de CTI cue efetivamente o motor para processar os eventos que chegaram e posteriormente ignoram ou ajustar qualquer com data e hora mais cedo do que o tempo atual.

O adaptador de entrada de amostra gera um fluxo de evento ordenada, para que ele insere automaticamente um evento de Cti após cada evento gerado para manter as coisas em movimento ao longo. Se você já está escrevendo um adaptador de entrada e seu programa não produz nenhuma saída, certifique-se de que seu adaptador é inserir Ctis, porque sem eles o motor vai esperar para sempre.

StreamInsight é fornecido com uma variedade de classes base para adaptadores: digitado, sem tipo, aponte, intervalo e borda. Adaptadores digitados sempre produzem eventos com um tipo de carga bem conhecidos — no caso de exemplo, a classe RandomPayload. Adaptadores não tipados são úteis para fontes de evento que podem gerar vários tipos de eventos ou coisas como arquivos CSV, onde o layout e o conteúdo das linhas não é conhecido antecipadamente.

O adaptador de entrada de amostra tem um tipo de carga bem conhecidos e gera eventos de ponto, para que ele herda de TypedPointInputAdapter <RandomPayload>. A classe base tem dois métodos abstratos que devem ser implementados: Iniciar e continuar. No exemplo, o método Start permite que um timer que é acionado no intervalo especificado pela configuração. O evento do temporizador decorrido executa o método ProduceEvent, que faz o trabalho principal do adaptador. O corpo deste método segue um padrão comum.

Primeiro, o adaptador verifica se o motor parou desde que ele executou, e que ele ainda está em execução. Em seguida, um método na classe base é chamado para criar uma instância de um evento de ponto, sua carga é definida e o evento é enfileirado no fluxo. Na amostra, o método de SetRandomEventPayload significa qualquer lógica de adaptador real — por exemplo, leitura de um arquivo, conversando com um sensor ou consultar um banco de dados.

A fábrica de adaptador de entrada também é simple. Ele implementa uma interface ITypedInputAdapterFactory <RandomPayloadConfig> porque é uma fábrica para adaptadores digitados. O único truque para esta fábrica é que ele também implementa o ITypedDeclareAdvanceTimeProperties <RandomPayloadConfig> interface. Essa interface permite que a fábrica lidar com a inserção da Ctis, conforme explicado anteriormente.

Adaptador de saída do aplicativo de exemplo segue quase exatamente o mesmo padrão como entrada. Existe uma classe de configuração, uma fábrica e o adaptador de saída propriamente dito. A classe do adaptador parece muito como o adaptador de entrada. A principal diferença é que o adaptador remove eventos da fila, em vez de enfileiramento-los. Porque Cti eventos são eventos como os outros, eles chegam ao adaptador de saída, demasiado e são simplesmente ignorados.

Observáveis

Embora o modelo de adaptador é bastante simple, há uma maneira ainda mais fácil para obter eventos dentro e fora do motor. Se seu aplicativo está usando o modelo de implantação incorporado para StreamInsight, você pode usar IEnumerables e IObservables como entradas e saídas para o motor. Dado um IEnumerable ou um IObservable, você pode criar um fluxo de entrada, chamando um dos métodos de extensão fornecido como ToStream, ToPointStream, ToIntervalStream ou ToEdgeStream. Isso cria um fluxo de evento que tem exatamente a mesma aparência como um criado por um adaptador de entrada.

Da mesma forma, tendo em conta uma consulta, os métodos de extensão como ToObservable/Enumerable, ToPointObservable/Enumerable, ToIntervalObservable/Enumerable ou ToEdgeObservableEnumerable encaminhará a saída de consulta para um IObservable ou IEnumerable, respectivamente. Esses padrões são especialmente úteis para a repetição de dados históricos salvos em um banco de dados.

Usando o Entity Framework ou LINQ para SQL, crie uma consulta de banco de dados. Use o método de extensão ToStream para converter os resultados do banco de dados em um fluxo de evento e definir uma consulta StreamInsight sobre ele. Finalmente, use ToEnumerable para rotear os resultados StreamInsight em algo que você pode facilmente foreach sobre e imprimir.

Modelo de implantação e outras ferramentas.

Para usar o suporte observáveis e Enumerable, StreamInsight deve ser incorporado em seu aplicativo. StreamInsight oferece suporte a um modelo autônomo, embora. Ao instalar, você é perguntado se deseja criar um serviço do Windows para hospedar a instância padrão. O serviço, em seguida, pode hospedar StreamInsight, permitindo que vários aplicativos conectar-se à mesma instância e compartilhar adaptadores e consultas.

Se comunicando com um servidor compartilhado em vez de um embedded envolve simplesmente um método estático diferente sobre a classe de servidor. Em vez de criar chamada com o nome de instância, chame conectar-se com um EndpointAddress que aponta para a instância compartilhada. Essa estratégia de implantação é mais útil para cenários corporativos onde vários aplicativos iria querer consumir consultas compartilhadas ou adaptadores.

Em ambos os casos, às vezes é necessário descobrir por que a saída gerada pelo StreamInsight não é o que deveria ser. O produto vem com uma ferramenta chamada o depurador de fluxo de evento para exatamente para essa finalidade. O uso da ferramenta está além do escopo deste artigo, mas em geral permite que você se conectar a instâncias e eventos de rastreamento de entrada por meio de consultas e para a saída.

Um instrumento flexível e reativo

Opções flexíveis de implantação, um modelo de programação familiar e adaptadores facilmente creatable fazem StreamInsight uma boa escolha para uma ampla variedade de cenários. De uma instância centralizada consultando e correlacionando milhares de sensor insere um segundo, para uma instância embedded monitoramento atual e eventos históricos em um único aplicativo, StreamInsight utiliza estruturas de desenvolvedor-friendly como o LINQ para habilitar soluções altamente personalizáveis.

Simples para criar adaptadores e suporte interno para a conversão entre fluxos de evento e IEnumerables e IObservables facilitam a levantar rapidamente soluções e executando, assim o trabalho incremental de criar e refinar consultas que encapsulam conhecimentos específicos de negócios pode começar. Como eles são refinados, estas consultas fornecem mais valor, permitindo que os aplicativos e as organizações a identificar e reagir a cenários interessantes quando elas ocorrem, em vez de após a janela de oportunidade já passou.

Rob Pierry é um consultor principal com Hackea (capturaonline.com), uma empresa de consultoria que oferece experiências de usuário inovadoras apoiada pela tecnologia escalável. Ele pode ser contatado pelo rpierry+msdn@gmail.com.

Graças aos seguintes especialistas técnicos para revisão deste artigo: Ramkumar Krishnan, Douglas Laudenschlager e Roman schindlauer