Temos hoje várias soluções interessantes no mercado para tratar assuntos sobre mensageria assíncrona e integração corporativa. Alguns bons exemplos de soluções disponiveis são o Websphere MQ da IBM (antigo MQSeries) e o TIBCO Rendezvous. Soluções como estas possibilitam canais de mensageria através de filas distribuidas que conectam aplicações de diferentes plataformas e linguagens. A grande vantagem disso é poder contar com um leque grande de plataformas suportadas sem perder o poder que as soluções dão sobre entrega de mensagens, tolerância a falhas, alta disponibilidade e performance.
Entretanto, como toda solução paga de um fabricante, existe o problema do custo do produto e a "amarração" de parte do negócio de uma organização com o produto do fornecedor, cenário este que pra muitas empresas de hoje, não agrada em nada, pois a cada dia vemos empresas sendo adquiridas por outras e ouvindo desses fornecedores frases do tipo "Ah, mas agora que esse produto foi comprado, não daremos mais suporte a ele nem continuidade, apenas garantir por mais X anos". Não vamos entrar em detalhes de exemplos de empresas que já fizeram isso para não gerar polêmica, mas todos conhecemos bons exemplos ;-)
Como lidar com integração de plataformas distintas usando mensageria assíncrona?
Se formos pensar apenas no mundo Java, temos o JMS (Java Messaging Service) que resolve com maestria todos os problemas de integração através de mensageria sínrcrona e assíncrona existentes, provendo uma infra-estrutura robusta e ao mesmo tempo amigável para desenvolvedores Java. Entretanto, nem sempre lidamos com entrypoints e endpoints Java, porventura temos que lidar com integrações que envolvem plataformas e linguagens diferentes. E neste caso, como lidamos com isso?
Uma forma interessante, é utilizar um barramento de serviços que tenha conectores para as plataformas em questão, e utilizar os recursos de mensageria e roteamento do mesmo para realizar a integração. Mas será que sempre teremos que usar um ESB para resolver este tipo de cenário? É razoável pensar que um ESB merece um cenário muito mais exigente para que ele se pague como solução de EAI, ou seja, um ESB deve ser usado para quando realmente você tenha integração cujo foco final é sustentação de serviços, afinal de contas, ESB é a sigla de Enterprise Service Bus, correto?
Sendo assim, como resolver esta questão? A um tempo atrás, tinhamos o mesmo problema para cenários de integrações baseadas em Remote Procedure Invocation. Quando identificou-se que várias plataformas deveriam poder trocar informações através de chamadas de objetos remotos, criou-se o então conhecido como protocolo IIOP e então a tecnologia CORBA, que possiilita que várias plataformas e linguagens falassem uma lingua franca sobre objetos remotos. Mas para que o CORBA pudesse render bons frutos, foi necessário criar um padrão de linguagem de objetos (IDL) e um protocolo neutro de plataformas para comunicação. O grupo OMG cuidou muito bem destes assuntos por anos, e a prova disso é que temos hoje várias implementações bacanas deste padrão como o JBoss IIOP e o Borland Visibroker.
Seguindo a mesma linha, temos hoje esforços grandes sendo feitos para criar uma notação/protocolo/linguagem franca para integração assíncrona de plataformas distintas que irá possibilitar que vários fornecedores criem soluções para este padrão e oferecer produtos pagos e abertos para questões como essas aos usuários de integração. A grande vantagem disso é a capacidade de usar a tecnologia sem ficar preso a nenhuma solução de um fornecedor específico. Estes esforços estão sendo feitos para sustentar o padrão AMQP, sigla de Advanced Message Queuing Protocol, iniciativa que visa padronizar a forma como aplicações são integradas via mensageria usando uma abordagem padrão de mercado.
Quem trabalha para que o AMQP seja um padrão de mercado de verdade?
O AMQP é um padrão que vem sendo desenvolvido desde 2004 por empresas de grande porte como JPMorgan, CISCO, IONA Technologies, iMatix Corporation, Microsoft, Novel, Rabbit Technologies, Red Hat entre outras gigantes da indústria. Atualmente, o padrão AMQP está na versão 0.10
Como posso desfrutar desta maravilha da área de EAI?
Mesmo que a especificação não esteja terminada, já temos hoje várias implementações deste padrão no mercado. Uma delas, e foco deste post é o projeto Red Hat Messaging. Este projeto, liderado e maturado pela Red Hat, é uma implementação de alta performance e escalabilidade baseada no AMQP.
A grande vantagem desta implementação é o alinhamento total com a especificação do AMQP uma vez que a Red Hat é uma das empresas por trás do padrão bem como a vantagem de ser mantida pela maior empresa open-source do mundo. Existem planos bem interessantes para o Red Hat Messaging, como por exemplo a integração total com o projeto JBoss Messaging. A idéia desta integração é fazer com que a plataforma de JMS tenha como fundação um motor robusto e escalável baseado no Red Hat Messaging, mas sem perder a compatibilidade com o padrão AMQP. Esta integração por hora ainda está imatura, pois a especificação de AMQP ainda está sendo construída, sendo perigoso portanto, criar uma integração que futuramente possa sofrer problemas com as mudanças da especificação.
Neste meio tempo, você já pode contar com uma implementação do Red Hat Messaging que já está sendo usada em produção por um banco de tókio com um cenário de 100 milhões de mensagens executadas por dia sem perda de pacotes ou desempenho (ver maiores detalhes na documentação do RHM). Outra grande vantagem é o suporte que ele dá pras linguagens Ruby, Java, C++, Python e .NET. Em breve suporte a Perl também será dado.
Para saber mais sobre o Red Hat Messaging e até mesmo experimentar algumas coisas, os links abaixo fornecem um suporte e acesso bem legal:
JBoss Messaging and Red Hat Messaging Integration Roadmap
Boas Integrações ;-)
Entretanto, como toda solução paga de um fabricante, existe o problema do custo do produto e a "amarração" de parte do negócio de uma organização com o produto do fornecedor, cenário este que pra muitas empresas de hoje, não agrada em nada, pois a cada dia vemos empresas sendo adquiridas por outras e ouvindo desses fornecedores frases do tipo "Ah, mas agora que esse produto foi comprado, não daremos mais suporte a ele nem continuidade, apenas garantir por mais X anos". Não vamos entrar em detalhes de exemplos de empresas que já fizeram isso para não gerar polêmica, mas todos conhecemos bons exemplos ;-)
Como lidar com integração de plataformas distintas usando mensageria assíncrona?
Se formos pensar apenas no mundo Java, temos o JMS (Java Messaging Service) que resolve com maestria todos os problemas de integração através de mensageria sínrcrona e assíncrona existentes, provendo uma infra-estrutura robusta e ao mesmo tempo amigável para desenvolvedores Java. Entretanto, nem sempre lidamos com entrypoints e endpoints Java, porventura temos que lidar com integrações que envolvem plataformas e linguagens diferentes. E neste caso, como lidamos com isso?
Uma forma interessante, é utilizar um barramento de serviços que tenha conectores para as plataformas em questão, e utilizar os recursos de mensageria e roteamento do mesmo para realizar a integração. Mas será que sempre teremos que usar um ESB para resolver este tipo de cenário? É razoável pensar que um ESB merece um cenário muito mais exigente para que ele se pague como solução de EAI, ou seja, um ESB deve ser usado para quando realmente você tenha integração cujo foco final é sustentação de serviços, afinal de contas, ESB é a sigla de Enterprise Service Bus, correto?
Sendo assim, como resolver esta questão? A um tempo atrás, tinhamos o mesmo problema para cenários de integrações baseadas em Remote Procedure Invocation. Quando identificou-se que várias plataformas deveriam poder trocar informações através de chamadas de objetos remotos, criou-se o então conhecido como protocolo IIOP e então a tecnologia CORBA, que possiilita que várias plataformas e linguagens falassem uma lingua franca sobre objetos remotos. Mas para que o CORBA pudesse render bons frutos, foi necessário criar um padrão de linguagem de objetos (IDL) e um protocolo neutro de plataformas para comunicação. O grupo OMG cuidou muito bem destes assuntos por anos, e a prova disso é que temos hoje várias implementações bacanas deste padrão como o JBoss IIOP e o Borland Visibroker.
Seguindo a mesma linha, temos hoje esforços grandes sendo feitos para criar uma notação/protocolo/linguagem franca para integração assíncrona de plataformas distintas que irá possibilitar que vários fornecedores criem soluções para este padrão e oferecer produtos pagos e abertos para questões como essas aos usuários de integração. A grande vantagem disso é a capacidade de usar a tecnologia sem ficar preso a nenhuma solução de um fornecedor específico. Estes esforços estão sendo feitos para sustentar o padrão AMQP, sigla de Advanced Message Queuing Protocol, iniciativa que visa padronizar a forma como aplicações são integradas via mensageria usando uma abordagem padrão de mercado.
Quem trabalha para que o AMQP seja um padrão de mercado de verdade?
O AMQP é um padrão que vem sendo desenvolvido desde 2004 por empresas de grande porte como JPMorgan, CISCO, IONA Technologies, iMatix Corporation, Microsoft, Novel, Rabbit Technologies, Red Hat entre outras gigantes da indústria. Atualmente, o padrão AMQP está na versão 0.10
Como posso desfrutar desta maravilha da área de EAI?
Mesmo que a especificação não esteja terminada, já temos hoje várias implementações deste padrão no mercado. Uma delas, e foco deste post é o projeto Red Hat Messaging. Este projeto, liderado e maturado pela Red Hat, é uma implementação de alta performance e escalabilidade baseada no AMQP.
A grande vantagem desta implementação é o alinhamento total com a especificação do AMQP uma vez que a Red Hat é uma das empresas por trás do padrão bem como a vantagem de ser mantida pela maior empresa open-source do mundo. Existem planos bem interessantes para o Red Hat Messaging, como por exemplo a integração total com o projeto JBoss Messaging. A idéia desta integração é fazer com que a plataforma de JMS tenha como fundação um motor robusto e escalável baseado no Red Hat Messaging, mas sem perder a compatibilidade com o padrão AMQP. Esta integração por hora ainda está imatura, pois a especificação de AMQP ainda está sendo construída, sendo perigoso portanto, criar uma integração que futuramente possa sofrer problemas com as mudanças da especificação.
Neste meio tempo, você já pode contar com uma implementação do Red Hat Messaging que já está sendo usada em produção por um banco de tókio com um cenário de 100 milhões de mensagens executadas por dia sem perda de pacotes ou desempenho (ver maiores detalhes na documentação do RHM). Outra grande vantagem é o suporte que ele dá pras linguagens Ruby, Java, C++, Python e .NET. Em breve suporte a Perl também será dado.
Para saber mais sobre o Red Hat Messaging e até mesmo experimentar algumas coisas, os links abaixo fornecem um suporte e acesso bem legal:
JBoss Messaging and Red Hat Messaging Integration Roadmap
Boas Integrações ;-)
0 comentários:
Postar um comentário