Resolvendo o dilema da integração

Publicado em: 2 de agosto de 2007

Por Jim Wilt

Resumo: Pacotes extensíveis baseados em framework. Encontram-se em todos os lugares. De portais ao comércio eletrônico. Do gerenciamento de conteúdo aos sistemas de mensagens. São eficientes? Em muitos casos, sim, perfeitamente. Lembro-me de vários aplicativos bem-sucedidos que construí com base nos frameworks fornecidos por esses produtos. Reforçam a produtividade, aprimoram a qualidade, aumentam a riqueza de características, reduzindo consideravelmente o tempo de colocação no mercado.

Assim sendo, por que as soluções de integração não passam pelos mesmos aprimoramentos? Independentemente de como faço a conexão em uma solução de integração com determinada ferramenta ou framework, o andamento não parece acompanhar o ritmo do meu aplicativo web ou solução de portal. Defino essa situação como o dilema de integração.

Por definição, a integração é, em si e por si, um problema difícil de resolver. Examinaremos os fatores contribuintes, para que possam ser:

• reconhecidos e categorizados

• compreendidos com as suas repercussões resultantes

• analisados de modo proativo.

Conteúdo

Nesta página

Regra 90/10
A para B vs A para C
O limite do desespero no mapeamento
Desempenho é importante
Pense nas ferramentas como um monte de legos
Resultado?
Referências
Sobre o autor

Regra 90/10

Noventa por cento das atividades direcionadas às soluções de integração referem-se, na verdade, à instalação, configuração e ao ajuste do ambiente de infra-estrutura e segurança. Sistemas operacionais, servidores Web, diretórios e configurações de aplicativos, assim como pools de aplicativos, usuários de processos host, SSO, permissões de diretório, segurança, etc. - todos esses aspectos desempenham uma parte da execução e contribuem para a frustração freqüentemente associada à implementação da integração.

Muitos desenvolvedores de aplicativos e pacotes extensíveis não têm de se preocupar com chaves de nome forte (.snk), GAC, certificados, criptografia, hosts em processo vs processos de host isolados e com muitos outros fatores sobre os quais o desenvolvedor de integração deve ter grande especialização e domínio. O benefício está em que a experiência de desenvolvimento da integração ampliará em grande medida a conduta do desenvolvedor na direção de futuras [normais] soluções de aplicativos. Quer dizer, as habilidades de um desenvolvedor se fortalecem ao concluir uma solução de integração.

Os 10% restantes da regra 90/10 ficam para que o desenvolvedor da integração resolva o problema real da integração. Esta é a causa da grande frustração das equipes de desenvolvimento e também da administração pois, em geral, o compromisso de 90% não se aplica, de forma nenhuma, ao problema real da integração em questão. Fica ainda mais ampliado, como veremos nas próximas seções, pois o problema real da integração é, normalmente, mais difícil do que o previsto, exigindo muito mais tempo para a sua solução do que permitem os 10% restantes.

Integrar em frameworks como o Microsoft BizTalk Server é quase igual a ter guias na pista de boliche. As suas interfaces quase sempre impedem a inserção de grandes danos à solução, orientando o usuário pelo projeto com muitos recursos e interfaces de implementação. Em contraste com os desafios de infra-estrutura e segurança, esta ferramenta ajudará, de fato, a controlar a solução. Entretanto, esta experiência de integração positiva constitui apenas 10% do esforço produzido.

Resolvendo a regra 90/10

As equipes de infra-estrutura e operações são suas melhores amigas:

• Mantenha uma relação próxima de trabalho com suas equipes de infra-estrutura e operações desde o início do projeto pois poderão, antecipadamente, identificar questões operacionais e de segurança em potencial.

• Muitas das questões que pressionam um desenvolvedor de integração são corriqueiras para um profissional de infra-estrutura e, assim, essa experiência deve ser usada para apressar a identificação e resolução do problema.

“EM GERAL, A TOLERÂNCIA ZERO REGE O DESENVOLVIMENTO DA INTEGRAÇÃO: REPETE-SE ATÉ FICAR PERFEITO. NORMALMENTE, FUNCIONALIDADE PARCIAL E FASES NÃO SÃO ALTERNATIVAS VIÁVEIS. PORTANTO, A INTEGRAÇÃO PASSA A SER A FONTE DE MUITOS ATRASOS DE PROJETO E ESTOUROS DE ORÇAMENTO".

Faça com que o seu ambiente de desenvolvimento imite o seu ambiente de produção:

• Replique o LDAP/Active Directory e instale aplicativos, servidores e pacotes usando o mesmo modelo de segurança da produção (ou o mais próximo possível)

• Nunca desenvolva nem execute suas soluções como um administrador

• Sempre que for preciso modificar o ambiente durante o desenvolvimento, analise a mudança com sua equipe de infra-estrutura/operações e registre a modificação na documentação de implantação.

O melhor ponto de partida para a solução de problemas de infra-estrutura de integração é a segurança, na forma de permissões e possibilidades de acesso.

A para B vs A para C

Em geral, as soluções de integração envolvem vários cenários de sistemas. É preciso entender os dois principais tipos de problemas de integração, como são solucionados e as respectivas complexidades relativas.

Problemas A para B: uma casa, dois sistemas

As características do problema A para B surgem quando um sistema B deseja comunicar-se com um sistema A. Em geral, estão na mesma infra-estrutura, mas não limitados por ela (podem alcançar redes WAN, VAN e a Internet).

Figura 1: Problema A para B: dois sistemas, uma casa

Por exemplo, o sistema B poderia ser um sistema distribuído acessando informações armazenadas no sistema A, um sistema legado (Figura 1). O mapeamento direto das informações de A para B exige conhecimento detalhado dos dois sistemas, A e B, mas como o conhecimento do domínio dos dois sistemas estará, em geral, disponível internamente, haverá menos suposições sobre quais campos e elementos de dados de A referem-se a B.

Problemas A para C: várias casas, vários sistemas

Um problema A para C descreve cenários nos quais o parceiro comercial A deseja comunicar-se com o parceiro de negócios C, mas ambos, às vezes, precisam de um formato B intermediário externo, comum ou padronizado do setor. Em geral, as casas estão em infra-estruturas separadas. (Vide Figura 2.)

Figura 2: Problema A para C: dois sistemas, duas casas

Um exemplo desta situação corriqueira ocorre quando parceiros de negócios usam um formato comum do setor ANSI X.12 , HIPAA ou XCBL para a sua comunicação, algumas vezes por meio de uma VPN. Muitas vezes, um esquema intermediário é de 10 a 100 vezes maior do que o esquema interno usado pelo sistema A ou C. Esses esquemas intermediários podem ser de 12 MB, resultando em questões de desempenho e estabilidade quando introduzidos em ferramentas pacotes de framework de integração - especialmente frustrantes quando a carga da mensagem é, em média, apenas 20K (Figura 3).

Além dessas questões mais mecânicas, os dois parceiros de negócios talvez tenham algum trabalho de adivinhação para decidir onde, no formato B intermediário, devem colocar suas respectivas informações. Acoplado ao fato de que um formato intermediário quase sempre contém redundâncias aumentadas, provocando invariavelmente mais confusão no posicionamento adequado das informações, essas imprecisões podem levá-lo a pôr em dúvida o valor desta forma de integração (por certo existe o valor, mas às vezes, pode suscitar dúvida).

Esses fatores tendem a fazer com que os problemas A para C sejam significativamente mais difíceis de solucionar, exigindo comunicação muito maior entre os parceiros de negócios para resolver diferenças de interpretação com o formato B intermediário.

Resolvendo os problemas A para B e A para C

• Documente claramente suas expectativas relativas ao formato B intermediário, citando vários exemplos.

• Reduza o tamanho do formato B intermediário, trabalhando com seus parceiros de negócios para acertarem um subconjunto de esquema que inclua apenas aqueles componentes utilizados por todos os parceiros de negócios.

• Duplique ou triplique as projeções de teste com o parceiro de negócios para compensar os equívocos do formato B intermediário.

O limite do desespero no mapeamento

Muitas soluções de integração chegam a uma forma de deformação de escopo, jamais planejada, mas que aumenta a frustração devido ao estouro no gerenciamento das horas e do orçamento. Essa situação é conhecida como o limite do desespero no mapeamento.

Depois de resolvidas todas as questões dos ambientes operacional, de segurança e infra-estrutura a ponto de os dados reais serem transferidos do ponto A para o ponto B (ou C), a interpretação de centenas a milhares de campos de um esquema para o próximo torna-se o principal ponto de enfoque. Muitas vezes, os dados exigidos em um ponto não estão prontamente disponíveis em outro ou, ainda, o significado pretendido de um campo é usado para algo inteiramente diferente. Em geral, os segredos mais desagradáveis vêm à tona durante a fase de mapeamento.

Figura 3: Os cenários A para C quase sempre envolvem um formato B intermediário aumentado

Os seguintes exemplos ilustram como esse processo deve ocorrer:

Uso inadequado de campos em repositórios de dados

O parceiro de negócios A deve fornecer dados de identidade ao esquema B no formato apresentado na Tabela 1.

Bastante simples, mas o parceiro de negócios A usa o campo 'inicial do meio', criativamente, para indicar 'anos de serviço' onde 0-9 representa o número de anos e A representa 10 ou mais anos. Quando uma inicial do meio é usada por uma identidade, o parceiro de negócios A simplesmente a considera como parte do nome.

Tabela 1: Formato de dados da identidade

A Tabela 2 representa como os dados podem ser armazenados pelo parceiro de negócios A.

Já não é mais tão simples, não é?

• O parceiro de negócios A deve analisar o campo Nome para determinar se existe uma inicial do meio.

• O algoritmo que faz a análise deve distinguir entre um nome de duas palavras, Tory Ann, e uma verdadeira inicial do meio, Maria A.

• A análise incorreta poderia resultar em confusão entre Mary A. Anderson com 2 anos de serviço e Mary Anderson com 10 ou mais anos de serviço.

• A má escolha do campo para indicar anos de serviço (provavelmente feita anos antes de qualquer intenção em compartilhar estes dados) apenas dobrou ou até triplicou o tempo de mapeamento do esquema do parceiro de negócios A para o B.

Mapeamento no mundo real

O mapeamento, quando demonstrado por fornecedores de software de integração, normalmente é semelhante à Figura 4.

O mapeamento do mundo real é um problema muito diferente e envolve:

• Centenas ou milhares de campos

• Diferenças de hierarquia nos formatos de dados que podem exigir algoritmos de looping complicados para posicionar os dados de forma adequada.

• Grandes fluxos de dados que exigem loops complicados para decompor as mensagens

• Ferramentas de integração exageradas, que algumas vezes levam os desenvolvedores a procurar uma solução gráfica para um problema muito complicado para essa ferramenta.

• Extração de dados de várias fontes internas (às vezes, de modo assíncrono)

Tabela 2: Tabela de dados armazenada pelo parceiro de negócios A

• Fabricar ou calcular informações que simplesmente não existem em nenhum dos repositórios de dados internos

• Interrupções de outros membros da equipe trabalhando em outras partes da solução quando um mapeamento é desdobrado

Os mapas do mundo real se parecem mais com a Figura 5. Inovações significativas nas ferramentas dos mapas do mundo real, como o novo XSLT Mapper do BizTalk, foram demonstradas e estão disponíveis para suavizar esta tarefa entediante mas, na maioria das vezes, o desafio é maior do que qualquer ferramenta teria condições de realizar (vide Referências).

Iterações sem fim

Nos desenvolvimentos de aplicativos normais, as iterações são uma boa coisa. Freqüentemente é possível determinar quantas iterações serão possíveis ou decidir uma tolerância de forma/função aceitável que permitirá a continuação. Em geral, aceita-se a funcionalidade parcial e fases podem ser utilizadas para introduzir a funcionalidade faltante, em data posterior.

Todavia, para o desenvolvimento da integração geralmente não há nenhuma tolerância: repete-se até ficar perfeito. Normalmente, funcionalidade parcial e fases não são alternativas viáveis. Portanto, a integração passa a ser a fonte de muitos atrasos de projeto e estouros de orçamento.

Figura 4: Demo de mapeamento de software de integração

Como sair do limite do desespero no mapeamento

• Não faça pressuposições sobre a dificuldade de mapeamento; sempre pesquise as fontes detalhadamente para identificar quais são aqueles desagradáveis segredinhos.

• Estabeleça um contrato de teste/depuração com os parceiros de negócios especificando a freqüência dos testes e emita um método de medição de desvio com vias apropriadas para escalar o problema. Especialmente ao trabalhar com parceiros de negócios externos, é imperativo definir e estabelecer contratos de testes com vias de escalação adequadas para que, se for preciso interromper os procedimentos de testes (quase certo), todos os envolvidos sejam informados, o quanto antes, para que possam comunicar de modo adequado os possíveis atrasos de entrega da solução.

• Utilize as melhores práticas de Desenvolvimento dirigido a teste para estar em condições de executar testes detalhados e defender o seu lado da integração, reduzindo/evitando o tempo de inatividade dos outros membros da equipe

• Para mapas complicados, pense em usar scripts e código em paradigmas de IU sofisticados (mais fáceis de ler e depurar)

• Decomponha as mensagens antes do mapeamento

• Use código gerenciado no lugar de mapas, quando necessário (por exemplo, para melhor desempenho e hierarquias complicadas). Isso é feito por meio de classes serializadas.

Figura 5: Mapeamento de dados do mundo real

• Entender e respeitar ramificações de desempenho relativas ao mapeamento (por exemplo, como os mapas são scripts XSLT, nunca chame código gerenciado a partir de um mapa).

Desempenho é importante

O desempenho sempre é importante, especialmente quando dizem que não faz diferença.

Solucionar o problema de desempenho é importante (BizTalk)

• Minimize as idas e vindas da caixa de mensagens

• Minimize a dependência das orquestrações (que podem fazer com que a sua solução fique uma ordem de grandeza mais lenta)

• Desenvolvimento dirigido a desempenho significa acompanhar as medições durante todas as fases de desenvolvimento para identificar gargalos, assim que possível.

• Utilize diretrizes para ajuste de desempenho - algumas excelentes diretrizes do BizTalk já foram publicadas (vide Referências)

• Processos prontos não são adequados para a sua solução. Existem muitos lugares onde otimizar o desempenho e, assim, é importante conhecer todos os componentes da solução, ajustando-os adequadamente para obter uma operação ideal

• Classes serializadas e código gerenciado podem ser mais rápidos do que mensagens e mapas; assim, pense em usá-los para componentes de desempenho crítico na solução

Pense nas ferramentas como um monte de legos

Depois que uma equipe adota um conjunto de ferramentas ou pacote para ajudar na implementação de suas soluções de integração, um erro comum é utilizar todas as ferramentas do conjunto em todas as soluções de integração.

Em muitos casos, nem todas as ferramentas precisam ser usadas. Na verdade, usar todas as ferramentas pode afetar negativamente o desempenho da solução no seu todo.

A melhor coisa é pensar no conjunto de ferramentas como um monte de legos. Os legos têm muitos tamanhos e cores, mas não é preciso usar todos os tamanhos e cores em todas as suas criações. Algumas vezes, talvez você só queira usar os legos verdes e brancos e em, outras, apenas os azuis e vermelhos. Tudo depende do resultado desejado.

Trate suas ferramentas de integração da mesma forma. Nem todas as soluções precisam de uma orquestração. O uso de uma orquestração implica pagar o preço do desempenho. Mapas podem ser utilizados nas portas assim como nas orquestrações. Algumas vezes, é bom experimentar implementando vários protótipos de soluções, usando várias combinações das ferramentas do conjunto, para entender as diferenças do desempenho, da manutenção e da implantação.

Conheça suas ferramentas e use apenas as necessárias (BizTalk)

• Faça melhor uso da porta com base no modelo publicação/assinatura; como não há orquestração, este modelo é muitas vezes desconsiderado.

• As orquestrações são mais eficientes para workflow; embora tragam em si alguma sobrecarga, as orquestrações têm uma grande finalidade e são muito efetivas quando usadas para workflow.

• Mapear nas portas e não apenas nas orquestrações: esta é outra capacidade muito negligenciada.

• Os pipelines podem ser rápidos e eficazes; pense em um componente de pipeline personalizado em uma orquestração: minimiza as idas e vindas na caixa de mensagens e elimina a sobrecarga da orquestração.

• Às vezes, classes serializadas e código gerenciado podem ser alternativas eficazes para mensagens e mapas.

Resultado?

Considere as ferramentas de integração como uma Ferrari (com transmissão manual) em sua garagem. Se só souber dirigir carros hidramáticos, essa Ferrari será o veículo mais lento e mais frustrante que você já conheceu. Todavia, se aprender a dirigir com transmissão manual, a Ferrari demonstrará ser um carro de corrida de alto desempenho, primorosamente ajustada, como ela de fato é.

Sem dúvida, as ferramentas certas, atreladas às habilidades e práticas corretas, poderão resolver o dilema da integração.

Referências

Eddie Churchill, “BizTalk’s sexy new XSLT Mapper” https://channel9.msdn.com/Showpost.aspx?postid=126990

BizTalk guidelines https://msdn.microsoft.com/library/default.asp?url=/library/en-us/ bts_2004wp/html/87f447a2-09ce-4a30-9f94-584684310051.asp

Sobre o autor

A experiência e as habilidades de Jim Wilt na resolução de problemas são aplicadas para ajudar os clientes a arquitetar as melhores soluções possíveis para terem êxito em suas necessidades relativas a projeto, colaboração, integração de dados de sistemas e BI. Ele é Microsoft Certified Architect – Solutions e recebeu vários prêmios do setor, inclusive o 1993 Industry Week Technology of the Year Award e o Burroughs Achievement Award for Excellence. Além disso, também foi reconhecido como Microsoft Most Valuable Professional - Visual Developer - Solutions Architect, membro do Microsoft MCA Board of Directors, do Central Michigan University College of Science and Technology Alumni Advisory Board e é um Central Michigan University Distinguished Alumni.