mar
10
2011

Integrar é preciso, na nuvem também…

Artigo publicado por Luis Comments

Em meio à barulheira promovida por diferentes fornecedores de soluções para computação em nuvem, as várias especificações muitas vezes perdem o sentido ou têm seu real significado maquiado. É importante dialogar de forma diferente com cada fornecedor. Principalmente quando se trata da integração de sistemas SaaS (Software as a Service) e aplicativos baseados na nuvem.

Uma das características principais da computação em nuvem é a forma de integração, que permite a aplicação de várias técnicas. O fato de a maioria dos aplicativos para computação em nuvem se apresentar na forma de serviços disponibilizados na internet imprime a tendência de seguir uma arquitetura voltada a serviços (SOA), mesmo que não adote todos os protocolos correspondentes.

De posse do ferramental apropriado e com estratégias de desenvolvimento bem pensadas, é possível integrar aplicativos com base na aplicação de diferentes técnicas. Bem posicionadas, é possível ainda rodar diferentes serviços na nuvem ao mesmo tempo.

O primeiro passo para a integração é entender as limitações de cada serviço e as camadas que estão em jogo. São elas as camada de: integração on-screen, também conhecida por Mashups, que consiste em uma integração feita a toque de caixa e um tanto “suja”, que reúne o conteúdo de diferentes URLs em vários iframes consolidados em uma única interface; integração dos layers de apresentação, quando a renderização se dá quase inteiramente no browser, podendo ser necessário instalar uma camada de aplicação no servidor; integração no ambiente lógico, mais complexa, em que a riqueza e a simplicidade oferecidas pelas APIs, responsáveis por receber chamadas de entrada e de saída ou, dedicadas a diálogos mais simples com XML e JSON, servem para diferenciar um aplicativo de computação em nuvem dos outros; e a integração de dados, que acessa diretamente a base de dados dos aplicativos na nuvem.

Compreender a diferença entre as camadas é entender também que um dos caminhos para a integração pode ser o uso da plataforma de computação em nuvem como mecanismo de integração. O que consiste no uso de linguagens de programação nativas para realizar as chamadas entre ambientes de cloud computing distintos.

Apesar da simplicidade da ideia, sua conversão, na prática, pode ser muito complexa. E esse tipo de integração só funciona em casos de conexões ponto a ponto simples.

Ao optar por esse modelo, é provável que tenham de ser confeccionados snippets com os códigos de integração em ambas as interfaces. Possivelmente, esses snippets tenham de ser escritos em linguagens distintas. Dependendo da diversidade de linguagens e plataformas adotadas pelo fornecedor ¬RESTFul ou SOAP, XML com JSON, ou object tree com tabelas DBMS ¬ menos prazerosa será a tarefa de integrar os aplicativos.

Ainda assim, por experiência própria, a integração direta é uma opção bastante elegível para situações que demandem por direitos de leitura apenas. Se o objetivo for realizar uma integração robusta com todas as funcionalidades em seu lugar, lidar com o recebimento de mensagens e garantia de entrega serão pontos bastante complicados. Isso, sem mencionar os eventuais momentos de indisponibilidade para realizar manutenções no sistema.

Conector ponto a ponto

Essa categoria de integração de aplicativos está disponível em duas versões:
local, com base em servidores próprios ou baseados em nuvem. A última pode ser encontrada nos serviços de alguns fornecedores, a um custo bastante razoável.

Soluções prontas oferecem formas de sincronização em mão dupla para um número limitado de campos. Em determinados casos, não há qualquer opção de configuração ¬ o que é comum, pois inclusive os conectores mais flexíveis permitem alterações apenas no mapeamento de campos. Adicionar campos personalizados e mapear objetos personalizados ou, ainda, dispor de códigos internos para promover a passagem de dados por meio de canais são opções que não se encontram nas tabelas.

Tais conectores podem ser a solução ideal para conectar, por exemplo, os serviços da Salesforce.com ao QuickBoost. Eles oferecem simplesmente uma conexão ponto a ponto, o que pode não corresponder à demanda em vários casos. Possivelmente, tentar realizar a integração entre uma terceira ou quarta nuvem, usando esses conectores, resultará em erro ¬ principalmente se estiverem tentando acessar o mesmo objeto.

Cabe avaliar a documentação e os serviços disponíveis ao escolher um ¬ saiba que a variedade é imensa. Vale muito a pena visitar fóruns para averiguar as questões relativas a cada um e ter uma perspectiva prática.

Conector de nuvens

Nessa modalidade, pode ser necessário usar um conector para integrar ambientes de nuvens sem foco em um aplicativo específico, com base em padrões aplicados na indústria e que possam ser interpretados por outra nuvem. O exemplo mais prático de tal dinâmica pode ser encontrado em plataformas ODBC e JDBC ¬ ainda assim, existem conectores de baixo nível, capacitados a dialogar com bibliotecas padrão.

As vantagens de tal aproximação consistem em flexibilidade. Os desenvolvedores têm acesso a um número arbitrário de tabelas remotas, de objetos e de métodos. Vale comentar que os preços desses conectores podem ser bastante razoáveis.

Ainda assim, não são nada mais que conectores ponto a ponto, ou seja, não são soluções elegíveis para conectar várias nuvens. Além disso, não oferecem muito em serviços de alto nível ou no contexto de objetos e de aplicativos.

Servidor de integração

Essa última categoria consiste em usar um servidor de integração que pode ser um serviço em nuvem (hospedado). Lançar mão desse tipo de integrador requer o uso de conectores (burros) nas interfaces. Nessa modalidade, os conectores são apenas interfaces sem qualquer inteligência, que fica armazenada nos hubs. Como a integração com servidores possibilita a execução de serviços de alto nível (gestão de mensagens, tradução, logs e administração), podem representar uma carga de trabalho maior ao departamento de TI. Roteamento inteligente, fluxos de trabalho e transações compensatórias podem ser desenvolvidas sem interferir em outras instâncias de serviços na nuvem.

Servidores de integração, locais ou remotos, representam a maneira mais flexível e adptável para dar conta da tarefa. Sem limitação por parte da arquitetura ou de sistemas integráveis e permitem o diálogo, inclusive, de sistemas de hardware e de outros consagrados. Na maioria dos casos, um servidor de integração traz os melhores resultados em desempenho. Em contrapartida, tal técnica requer que toda a programação seja feita in-house (na própria organização). Existirão códigos e outros modelos prontos, se der sorte, haverá também documentação para guiar esse trabalho.

Fonte: Originalmente publicado por DAVID TABER, CEO DA SALESLOGISTIX em 09 de março de 2011 – 08h00