Kevin Hackman, da TIBCO, deu uma entrevista ao Artima falando sobre as vantagens do HTTP e como estas mesmas vantagens (que no caso seria o fato dele não manter estado) complica o desenvolvimento de aplicações na web. Ele comenta também que eles desenvolveram uma nova ferramenta para o desenvolvimento de aplicações web totalmente baseada em eventos e que não se prende a API de servlets e ao modelo de uma thread por conexão socket, mas sim a um modelo mais parecido com o cliente servidor clássico, onde o cliente tem uma conexão “persistente” com o servidor e fica trocando mensagens com ele.
A ideia parece até ser interessante, do ponto de vista de se manter estado de alguma forma, mas a implementação como um “serviço de mensagens” parece meio forçada, já que em Java o que não falta são provedores de middleware de troca de mensagens (é só ver quantos containers com suporte a JMS existem) e todos os exemplos que ele cita parecem ser bons candidatos a o uso de esquemas com JMS.
Seria isso apenas mais uma renivenção da roda, só que agora por fora do padrão já definido do JMS ou eles realmente tem uma boa idéia?
Posso estar errado mas me parece um pouco diferente da interpretação da Artima.
Observem na figura, que à esquerda há uma caixinha de nome Data feed
Vou tentar descrever com palavras o que está na figura para um determinado exemplo simplório e fora da realidade:
Uma aplicação de bolsa que acessou um servidor web e um servidor de aplicação para carregar uma aplicação Java com servlet normal como a gente conhece. O cliente vai receber só as cotações que lhe interessam.
O servlet devolve ao cliente uma página com uma tabela de cotações on line, mas passando pelo servidor de eventos onde pega as cotações atuais.
A caixa Data Feed recebe cotações on line da Reuters, por exemplo. Estas cotações são tratadas como eventos pelo servidor de eventos, que nesta figura é chamado de TIBCO Ajax Message Service. Os eventos (cotações) entram pelo Data adapter, são filtradas de acordo com os critérios dos clientes e os eventos (cotações) filtrados, são enviados usando AJAX, para a página do cliente
Os filtros nas cotações são aplicados on line. É como se fosse uma consulta SQL aplicada na memória. Exemplo: o cliente pode querer ser alertado sobre as cotações do GUJ que se fastem da média dos últimos minutos ou horas. Os eventos vão chegando aos montes porque a toda hora são negociadas ações do GUJ. No instante em que a consulta especificada pelo cliente se realiza, estes evento serão enviados ao cliente via AJAX.
Não é reinvenção da roda nem mais um outro serviço de mensagens. Este tipo de arquitetura pode eventualmente usar JMS. Aliás, todos os servidores de eventos tem adapters de para JMS, tanto para input de eventos como para output.
Esta é a idéia que eu entendi. Dá para fazer isto com qualquer outro servidor de eventos que faça CEP, isto é, processamento de eventos complexos (eventos que dependem de outros). Há vários no mercado. Na minha máquina tem 3 (Coral8, Esper e BEA), sendo que o gigantão da BEA me obriga a usar o JRockit real time.
Dúvidas? É só perguntar porque esta é a minha praia.
[quote=Luca]Esta é a idéia que eu entendi. Dá para fazer isto com qualquer outro servidor de eventos que faça CEP, isto é, processamento de eventos complexos (eventos que dependem de outros). Há vários no mercado. Na minha máquina tem 3 (Coral8, Esper e BEA), sendo que o gigantão da BEA me obriga a usar o JRockit real time.
[/quote]
Opa Luca,
Não entendi essa parte de eventos que dependem de outros e como ela se encaixa nessa solução. Tipo, a implementação real desse troço é um cliente que fica fazendo requisições AJAX de tempos e tempos pro servidor pra poder “receber” o push-back, o evento que depende de outro é essa requisição que o cliente e que vai retornar os dados do primeiro evento lá do leitor de ações?
[quote=Maurício Linhares]
Não entendi essa parte de eventos que dependem de outros e como ela se encaixa nessa solução. Tipo, a implementação real desse troço é um cliente que fica fazendo requisições AJAX de tempos e tempos pro servidor pra poder “receber” o push-back, o evento que depende de outro é essa requisição que o cliente e que vai retornar os dados do primeiro evento lá do leitor de ações?[/quote]
A chave para entender esta figura é a caixa Data Feed. É ela que recebe os milhares de eventos por minuto.
[quote=um pouco de teoria sobre eventos]
Um evento é um registro de algo que aconteceu. Ele pode se relacionar com outros. Tem 3 aspectos: Forma (é um objeto), Significância (qual atividade aconteceu) e relatividade (tempo, causa e agregação).
Uma ordem de compra pode ser um objeto (anêmico) com os seguintes campos (nome, ID do cliente, ID da ordem, descriçao da ordem, hora, causa caso exista). No caso das cotações da bolsa pode conter menos informações. Os eventos chegam como objetos ou como texto CSV via mensagens JMS ou outros meios. [/quote]
O servidor de eventos recebe os eventos do data feed via o respectivo adapter. Trata, isto é, filtra de acordo com as cláusulas definidas pelo cliente ou já existentes no servidor.
Imagine os milhares de eventos que chegam ao servidor como se fosse uma base de dados na memória em que o tempo todo se faz um tipo de consulta muito parecido com SQL. O resultado desta consulta é o que passa no filtro e vai para a tela do cliente via AJAX.
O modelo é semelhante ao que faz o GMail. Ele recebe os emails, seleciona os seus e envia para você usando AJAX.
Melhorou o entendimento de onde entra o servidor que trata os eventos e que tem um adapter que faz o push dos dados para o cliente?
Assim, a idéia é interessante, mas não parece nada de novo (na verdade parece um bocado com o sistema que eu estou mexendo aqui :P) pra eles estarem fazendo esse estardalhaço todo.
O novo é mostrar mais um lugar onde pode ser usado o engine de CEP deles. A diferença da arquitetura deles para a sua é que na deles devem chegar muito mais mensagens por segundo.
Mais uma explicação sobre o texto da TIBCO:
Para quem não sabe, Dashboard é uma aplicação com telas de monitoramento cheias de gráficos. No caso de aplicações de bolsa, as cotações em tempo real podem ir alterando os gráficos na tela do cliente.
Um outro exemplo de como usar este treco seria em uma aplicação fabril de monitoramento de máquinas de injeção de plástico onde se poderia estabeler limites máximos e mínimos de peças injetadas por máquina.
A tela do gerente de produção seria um dashboard com palitinhos coloridos, um para cada máquina e com as cores mostrando como estão produzindo dentro da faixa de tolerância. Na tela podem aparecer outros gráficos relativos à produção e dados adicionais de outros sensores tais como temperatura ambiente, espurios na rede elétrica ou sei lá o que mais.
Antigamente este ambiente precisava de um sistema operacional real time como o QNX. Hoje se pode simular o real time usando um engine de CEP.
Se alguém pensar em telemetria de fórmula 1, também seria outro caso de uso.
Pelo que entendi o WebServer envia o HTML, e depois no TIBCO envia o modelo de dados, que pode ser para alimentar o próprio site em HTML usando Ajax, ou Applets, ActiveX, Flash, etc…
Seria como enviar um HTML limpinho, sem nada de dados dinâmicos, e estes dados viriam através de outro servidor que seria o responsável de enviar apenas dados… podendo ser em formato XML certo?
