Artigo Java Magazine 69 - Estratégias de Integração de Aplicações Java EE

Integrar aplicações não é uma tarefa trivial. Protocolos diversos, APIs exóticas, tecnologias e ambientes complexos e cronogramas agressivos são alguns aspectos que desafiam diariamente analistas desenvolvedores Java EE.

Conto aqui uma história que resume estes desafios. Uma equipe necessitava enviar emails de sua aplicação Java. Uma tarefa aparentemente trivial, que muitos desenvolvedores vivem todos os dias. A equipe não possuía experiência com a API JavaMail, mas com a ajuda de um recurso externo a equipe se capacitou e desenvolveu o código necessário para suportar a integração, que neste caso ocorreria com o servidor Microsoft Exchange. Código implementado, testes internos realizados com sucesso e aprovação gerencial. Aparentemente o problema foi resolvido.

A vida real, entretanto, guarda surpresas. Na véspera da semana de implementação, o código foi implantado na empresa do cliente (vamos chamá-la de empresa ACME), mas os casos de uso que requeriam a integração com o Microsoft Exchange não funcionavam. Todos os olhos e atenções (e culpas) foram lançados para o servidor de email da Microsoft. Após a descoberta que o servidor de email do cliente (v2007) estava em uma diferente versão do ambiente interno da desenvolvedora (v2003), modificações no ambiente de desenvolvimento foram realizadas para adequar o servidor. Nenhum resultado positivo foi alcançado. O pânico se instalou!

Mais investigações foram realizadas e a equipe descobriu que o servidor de email de produção não residia na mesma rede do servidor de aplicação do cliente, mas em um distante local remoto (em outra cidade) em um provedor com um acesso controlado por um firewall. O analista de infra-estrutura do cliente não foi questionado o bastante para informar este fato. Para encurtar a história, a equipe descobriu que o envio de emails neste ambiente requeria o uso de certificados e protocolos com garantia de transporte seguro (SMTP sobre SSL). Noites mal-dormidas, um atraso de algumas semanas no cronograma, um cliente relativamente estressado e o desafio foi finalmente vencido.

Que lições podemos aprender com esta história? Enumero algumas abaixo:

• Certificar que as versões dos ambientes a serem integrados sejam exatamente iguais;

• Analisar cuidadosamente a topologia, isto é, a organização física do ambiente de produção do cliente. Diagramas UML de implantação são uma ferramenta útil neste aspecto;

• Analisar os protocolos e requisitos não-funcionais que possam interferir na interoperabilidade;

• Antecipar testes realizados na plataforma real do cliente.

Requisitos Funcionais e Requisitos Não-Funcionais

Requisitos funcionais expressam os desejos dos interessados do projeto na perspectiva da funcionalidade. Exemplos incluem cadastros, relatórios e fluxos de trabalho. Requisitos não-funcionais expressam atributos de qualidade de um sistema tais como desempenho, usabilidade, disponibilidade ou portabilidade.

Requisitos funcionais e não-funcionais importantes para o negócio (prioritários) e complexos formam o conjunto derequisitos arquiteturaisque devem ser foco inicial de qualquer projeto de TI.

Requisitos funcionais e não-funcionais coletados podem responder a perguntas sobre escolhas de estratégias e tecnologias sobre interoperabilidade. Por exemplo, restrições sobre desempenho podem eventualmente influenciar na escolha de uma integração com soquetes ao invés de XML e Web Services.

O leitor mais experiente pode questionar as lições aprendidas neste exemplo. “Estas lições são óbvias”. Mas devemos lembrar que senso comum não é prática comum.

Dica

Seja um “Indiana Jones” de aplicações Java na sua empresa. Faça uma arqueologia de software nas aplicações Java da sua empresa e colete os erros e lições aprendidas. Os erros do passado são uma excelente fonte de aprendizado para projetos futuros.

O objetivo deste artigo é mostrar a você como tornar senso comum em prática comum, isto é, evitar erros comuns de integrações de sistemas em projetos e evitar estresses desnecessários. Vamos abordar estratégias e técnicas para organizar o seu trabalho, organizados da seguinte forma nas seções seguintes deste artigo:

• Estilos, Níveis e Topologias de Integração. Iremos conhecer aqui fundamentos da integração de sistemas;

• Tecnologias para Interoperabilidade Java. Aqui iremos citar as principais tecnologias e padrões Java para a integração de aplicações;

• Padrões de Integração (EIP). Iremos conhecer aqui as melhores práticas de mercado para integrar aplicações;

• Processo para Integrar Aplicações. Vamos abordar aqui as principais tarefas necessárias durante um projeto para garantir uma boa interoperabilidade de suas aplicações Java.

Estilos, Níveis e Topologias de Integração

“Se você se conhece, mas não o inimigo, para cada vitória sofrerá uma derrota”, Sun Tzu, A Arte da Guerra.

Como conhecer o inimigo? Primeiramente devemos compreender que interoperabilidade é um mecanismo arquitetural, ou seja, uma preocupação importante de um projeto e que, portanto, requer a atenção técnica ainda no começo do projeto. Devemos investigar as interoperabilidades requeridas no nosso projeto através do estilo, nível e topologia associados, pois para cada um haverá uma abordagem técnica diferenciada e tecnologias distintas em Java.

Dica

Colete os requisitos arquiteturais diretamente com representantes do seu cliente em reuniões conjuntas com o analista de requisitos. Normalmente analistas de requisitos têm dificuldade de capturar e expressar informações técnicas, o que implica em informações truncadas e novas descobertas indesejadas no final do projeto.

A interoperabilidade de aplicações pode se apresentar em quatro estilos, conforme Gregor Hohpe [1].

1. O primeiro estilo é a transferência de arquivos, onde duas aplicações compartilham as informações através de um arquivo texto ou binário. O protocolo FTP é um exemplo popular de tecnologia que suporta este estilo;

2. O segundo estilo, talvez o mais popular, é através de dados compartilhados em bancos de dados;

3. O próximo estilo é através de procedimentos remotos (RPC), onde um programa cliente invoca uma funcionalidade em outra máquina. As tecnologias de WebServices são exemplos normalmente associados a RPC;

4. O último estilo é através de passagem de mensagens. Programas com suporte a filas de mensagens, como a especificação Java JMS, são exemplo deste estilo.

Pare um minuto e responda: Qual o estilo requerido no exemplo citado de interoperabilidade com o Microsoft Exchange? (Resposta no final deste artigo).

Além dos estilos, podemos classificar a interoperabilidade em níveis, listados a seguir:

1. Nível de dados. Como integrar fontes de dados relacionais ou em outros formatos e como reduzir a sua redundância? A integração em nível de dados foca na movimentação de dados entre aplicações com o objetivo de compartilhar o mesmo dado entre aplicações diferentes;

2. Nível de Interfaces de Aplicação (API). Como integrar APIs de aplicação em outras tecnologias que não sejam Java? A integração via APIs passa pela chamada de funções através de protocolos síncronos (RPC) ou assíncronos (mensagens);

3. Nível de Processos de Negócio. Domínio do mundo BPM/SOA, a integração em nível de processos de negócio foca no desenvolvimento de componentes de alto nível que irão fornecer interfaces de alto nível que podem ser considerados serviços;

4. Nível de Apresentação. Popularmente conhecidos como mash-ups, integram aplicações através de um conjunto de vários portlets (janelas visuais independentes) que residem em um determinado portal. A Figura 1 mostra um exemplo de integração neste nível.

Figura 1. Mash-up do Internet Google. Diferentes aplicações foram integradas aqui em nível de camada de apresentação. Podemos ver no exemplo acima blogs de diferentes autores, o Google Talk e mesmo uma aplicação de previsão de tempo.

Um novo teste: Qual o nível associado ao exemplo citado de interoperabilidade com o Microsoft Exchange? (Resposta no final deste artigo).

Finalmente, devemos considerar também a questão da topologia da aplicação. Dois modelos clássicos existem:

1. Comunicação Ponto a Ponto. A integração ponto a ponto é também chamada de integração oportunista e ocorre diretamente entre dois sistemas que queiram conversar. Quando conectamos uma TV diretamente a um DVD, usamos intuitivamente esta topologia de integração;

2. Comunicação Hub and Spoke. Topologia popularizada pelos ESB (um tipo particular de Hub and Spoke), esta topologia usa um mediador central para comunicar cada aplicação (Spoke) que deseje conversar. Nenhuma aplicação conversa diretamente com outra aplicação. Isto pode parecer confuso e complexo, mas considere (na sua sala de TV dos sonhos) como você poderia integrar adequadamente uma televisão digital, um computador, um sistema de som 7.1, um DVD, um vídeo-cassete (para as fitas de formatura da sua família), um projetor e um vídeo-game de última geração. É claro neste exemplo que usar um aparelho central para gerir todas as conexões é mais vantajoso. O Home-Theater é um hub na sua sala de TV dos sonhos e pode ligar todos os fios dos aparelhos (Figura 2).

Figura 2. A topologia de comunicação ponto a ponto liga duas aplicações diretamente. A topologia Hub and Spoke usa um barramento central (Hub) para ligar múltiplos clientes.

Mais um desafio: Qual a topologia associada ao exemplo citado de interoperabilidade com o Microsoft Exchange? (Resposta no final deste artigo).

Dica: Colete os requisitos arquiteturais de interoperabilidade na sua aplicação. Para cada requisito arquitetural, defina o estilo, nível e topologia associada.

Tecnologias de Interoperabilidade Java

“Um chefe deve empregar táticas variadas de acordo com os tipos de terreno”, Sun Tzu.

A plataforma Java foi desenhada e evoluída nos últimos anos com um grande suporte para interoperabilidade. Considere como exemplo simples a especificação JDBC. Projetada de forma elegante para suportar a portabilidade de sistemas operacionais e bancos de dados, ela é um exemplo que suporta a integração do estilo (ver Tabela 1) banco de dados compartilhados, em nível (ver Tabela 2) de dados.

Diversas outras tecnologias foram projetadas para suportar outros estilos e níveis. Apresentamos alguns exemplos nas Tabelas 1, 2 e 3, sem nos ater aos detalhes da API, que podem ser encontrados em artigos anteriores da revista Java Magazine.

Tabela 1. Tecnologias Java para suportar estilos de interoperabilidade.

Tabela 2. Tecnologias Java para suportar níveis de interoperabilidade.

Tabela 3. Tecnologias Java para suportar topologias de interoperabilidade.

As Tabelas 1, 2 e 3 mostram que é fundamental escolher adequadamente a tática (tecnologia) conforme o tipo de terreno (estilo, nível ou topologia).

Dica: Não use as tecnologias Java no primeiro combate a um problema de interoperabilidade. A tecnologia é secundária e deve ser considerada apenas após a correta coleta e desenvolvimento dos requisitos arquiteturais e definição dos estilos, níveis e topologia.

Padrões de Integração de Aplicações (EIP)

“Um soberano iluminado estuda deliberadamente a situação e um bom general lida cuidadosamente com ela. Se não é vantajoso, nunca envie suas tropas; se não lhe rende ganhos, nunca utilize seus homens; se não é uma situação perigosa, nunca lute uma batalha precipitada.”, Sun Tzu.

Conhecemos o inimigo. Conhecemos as ferramentas. Entretanto, a grande chave na interoperabilidade de aplicações é saber como aplicar as tecnologias Java a nosso favor. Neste aspecto, introduzimos o conceito de um padrão de integração de aplicações.

Um padrão EIP é uma solução provada aplicável ao contexto de integração de aplicações corporativas.

O livro Enterprise Integration Patterns [1] apresenta 65 padrões de integração de sistemas. Cada padrão resolve um problema particular no contexto de integração de aplicações corporativas e pode ser usado junto com outros padrões EIP para solucionar um problema do mundo real.

Consideremos, para ilustrar o conceito, um problema similar ao citado no começo deste artigo. Poderíamos formalizar os requisitos arquiteturais da seguinte forma:

R1. A aplicação ACME deve interoperar com o servidor Microsoft Exchange 2007 através de protocolos SMTP para envio de emails.

R2. O transporte para interoperabilidade com o servidor de emails deve garantir confidencialidade e integridade das informações enviadas através do uso do protocolo SMTP sobre SSL.

Ao lermos o livro EAI Patterns, capturamos alguns padrões candidatos para o problema acima. Estes padrões são documentados na Tabela 4.

Tabela 4. Padrões EAI usados para resolver a interoperabilidade com o Microsoft Exchange.

O primeiro padrão da Tabela 4 nos diz que a solução provavelmente será resolvida com um mecanismo assíncrono. Dadas as restrições de protocolos no requisito R1, vemos que a especificação Java nos sugere a especificação JavaMail.

O segundo e terceiro padrões nos diz que teremos um canal para o envio e recebimento de informações e este canal deve se conectar a um sistema de email como o Microsoft Exchange. Ao examinarmos a classe Transport, da API do JavaMail, veremos que ela possui esta função. Naturalmente, um Message Endpoint requer uma implementação da especificação JavaMail. Assumamos neste exemplo que usamos o JBoss AS para esta solução.

O quarto padrão nos diz que devemos enviar um documento textual. Ao observamos novamente a classe Transport, notamos que ela possui um método send() que espera como argumento um objeto do tipo Message, que modela um Document Message.

O quinto padrão endereça os requisitos de segurança. Um enriquecedor de conteúdo permite adicionar à mensagem original informações adicionais. No nosso caso, estas informações adicionais serão de segurança, que nos permite que a mensagem seja entregue em servidores que operem sobre protocolo SSL. Ao examinarmos a hierarquia da classe Transport, vemos a classe SMTPSSLTransport. Esta classe fornece a funcionalidade de envio de emails sobre canal seguro (confidencialidade e integridade).

O último padrão está fora do escopo Java, mas ele indica que alguém deve configurar o servidor Exchange para não aceitar mensagens SMTP, mas somente mensagens SMTP sobre SSL. O padrão Consumidor Seletivo representa este mecanismo.

Se conectarmos os padrões EIP teremos o desenho da nossa solução apresentado na Figura 3.

Figura 3. Esquema da solução de integração com o MS Exchange Server

O trecho de código abaixo mostra estas peças conectadas.

Listagem 1. Fragmento de Código para Envio de Email.

… Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider()); Properties props = new Properties(); props.put("mail.smtp.host", SMTP_HOST_NAME); // Servidor de email props.put("mail.smtp.auth", "true"); // Requer autenticacao props.put("mail.debug", "true"); props.put("mail.smtp.port", SMTP_PORT); // Porto do servidor de email props.put("mail.smtp.socketFactory.port", SMTP_PORT); props.put("mail.smtp.socketFactory.class", // Enriquecedor da mensagem com SSL "javax.net.ssl.SSLSocketFactory" ); props.put("mail.smtp.socketFactory.fallback", "false"); Session session = Session.getDefaultInstance(props, new javax.mail.Authenticator() { protected PasswordAuthentication getPasswordAuthentication() { return new PasswordAuthentication("username", "password"); } }); Message message = new MimeMessage(session); InternetAddress addressFrom = new InternetAddress(from); message.setFrom(addressFrom); message.setSubject(“OLÁ EIP”); message.setText(“Padrões EIP organizam e comunicam as soluções Java!”); Transport.send(message); ...

Este fragmento de código pode ser entendido como a realização do esquemático da Figura 3.

Para um problema simples, naturalmente, podemos até ir intuitivamente para uma tecnologia ou um código, mas isso é como começar a correr uma maratona sem preparação física adequada. Os padrões representam esta preparação física. Eles permitem que você pense nos aspectos da solução sem se ater aos detalhes da tecnologia. Ao escolheremos uma tecnologia Java determinada, ela será a conseqüência dos padrões, que naturalmente devem suportar os requisitos arquiteturais especificados.

Para problemas complexos de integração do mundo real, entretanto, devemos conhecer e aplicar os padrões EIP. Outra excelente fonte de padrões é o livro POSA [2], que contém mais de uma centena de padrões arquiteturais, entre eles diversos padrões EIP.

Como exemplo de padrões EIP usados para modelar aplicações com integração complexa, dita aplicações EAI, poderíamos citar os padrões descritos na Tabela 5.

Tabela 5. Padrões EAI tipicamente usados em aplicações BPM/SOA/ESB.

Um Processo para Interoperar Aplicativos

“Se um general sabe o lugar e a hora de uma batalha, ele pode conduzir as suas tropas para até mil milhas, mesmo para uma batalha decisiva. Se ele não sabe nem o lugar nem a hora de uma batalha, então o seu lado esquerdo não pode ajudar a sua direita e a ala direita não pode salvar a esquerda; a tropa da frente não pode auxiliar a tropa da retaguarda, nem a tropa da retaguarda pode ajudar a tropa da frente.”, Sun Tzu.

Conhecer um processo para solucionar problemas técnicos é fundamental. Saber a hora e o lugar das ações é fundamental, especialmente nos mecanismos arquiteturais de interoperabilidade.

Podemos resumir o processo de aplicação das estratégias e padrões EIP da seguinte forma:

1. Colete os requisitos arquiteturais de interoperabilidade. Uma boa fonte para isso são atores secundários em diagramas de casos de uso. Eles normalmente revelam sistemas e aplicações que devem ser integrados. Especifique detalhadamente estes requisitos para que não existam dúvidas sobre as versões de servidores, topologias e protocolos exatos a serem utilizados;

2. Desenvolva soluções independentes de tecnologia para cada requisito arquitetural de interoperabilidade. Para isso, identifique os estilos, níveis e topologias de cada requisito arquitetural de interoperabilidade. Expresse então a sua solução através dos padrões EIP encontrados em [1] e [2];

3. Estude os exemplos (mais complexos e além do escopo deste artigo) disponíveis em [1];

4. Para cada solução independente de tecnologia, escolha as tecnologias Java mais adequadas para resolver o seu problema. Use as Tabelas 1, 2 e 3 como ponto de partida e então estude as especificações de cada tecnologia apresentada e produtos Java que suportem estas especificações;

5. Prove a sua solução. Talvez a dica mais valiosa, a sua solução deve ser provada com um código real e que possa capturar um cenário de utilização do seu sistema;

6. Teste a sua solução em ambiente idêntico ao de produção. Envolva o usuário e faça testes reais e significativos, pois este é o passo mais complexo. Aplicações não testadas adiam riscos e podem levar a problemas graves no fim do projeto. Em cenários mais complexos onde você não tem acesso ao aplicativo sendo interoperado, considere o uso de ferramentas como o jMOCK ou EasyMock. Recomendo, neste particular, o excelente artigo Mocks Aren’t Stubs, de Martin Fowler, e o artigo “Testando com Mocks de forma fácil”, Edição 62;

7. Garanta que você realizou os passos 1-5 no começo do projeto. Requisitos de interoperabilidade são complexos e devem ser endereçados no INÍCIO do projeto. Se você usa um processo derivado do UP (Unified Process), os itens 1-5 para todos os requisitos arquiteturais devem estar finalizados até o 3/10 temporal do seu projeto. Se você usa processos ágeis, enderece estes requisitos nos primeiros sprints/iterações.

Diagramas de Casos de Uso

Diagramas de casos de uso são visualizações de negócio usadas por analistas de requisitos para o auxílio na coleta e entendimento de requisitos. Estes diagramas possuem atualmente grande popularidade na comunidade de analistas e podem ser ferramentas poderosas para a coleta de interoperabilidades. No nosso exemplo, poderíamos representar a interoperabilidade do envio do e-mail com o seguinte diagrama.

Note que neste diagrama o Microsoft Exchange suporta a operação de envio de email e por isso é chamado deAtor Secundário.

Processo Unificado (UP)

O UP (Unified Process) é um processo para desenvolvimento de software baseado no conceito de um projeto centrado em arquiteturas de software. Em termos simples isso significa reduzir os riscos técnicos do projeto nas suas fases iniciais através do ataque aos requisitos mais prioritários e complexos através de provas de conceito que busquem mitigar e eliminar estes riscos.

O UP possui diversas variantes como por exemplo o popular IBM Rational Unified Process, o Enterprise Unified Process de Scott Ambler ou o processo ágil OpenUP.

Conclusões

Este artigo apresentou, de forma introdutória, princípios que devem nortear aplicações que requerem integrações de sistemas. Coloco abaixo um guia de estudo para os mais interessados no assunto.

1. Certifique-se de conhecer os fundamentos de integração de sistemas. Estilos, topologias e especificações são fundamentais e livros como [1] e [2] são fontes fundamentais;

2. Estude antecipadamente as ferramentas e APIs Java para suportar os estilos e topologias acima;

3. Nunca acredite em tecnologias que não foram provadas no seu projeto. Negocie tempo do seu gerente de projeto para provar conceitos e realizar testes de integração. Se você não realizar esta negociação no começo do projeto, espere estresses, noites mal dormidas e problemas na entrega do seu código;

4. Lembre-se que o mundo não é centrado em Java. Você precisará conhecer peças e protocolos além da linguagem Java para se tornar um bom arquiteto de integrações;

5. Teste o seu código de integração. Já observei diversos problemas em projetos devido a processos de testes de integração falhos e que aconteceram literalmente na entrega do projeto.

O leitor curioso deve ter notado o uso de ícones diferenciados para representar padrões EIP. Estes ícones estão disponíveis gratuitamente em formato Visio no próprio portal de Gregor Hohpe (EAI Patterns).

Para o leitor ainda mais curioso que busca aqui as respostas para as perguntas feitas ao longo do artigo, o problema tem como solução: o estilo Passagem de Mensagens, integração em Nível de Aplicação e topologia Ponto a Ponto.

Boas integrações!

Links

martinfowler.com/articles/mocksArentStubs.html
Descreve o conceito de Mocks e que ele pode ser usado para simular aplicações externas no contexto de projetos de integração de aplicações.

eaipatterns.com/
Site central dos padrões EIP e que resume muito material interessante sobre integração de aplicações.

eaipatterns.com/downloads.html
Recursos sobre EIP e em particular o stencil (plugin) Microsoft Visio para desenhar EIP.

epf.eclipse.org/wikis/openup/
Open UP. Processo de desenvolvimento gratuito baseado nos conceitos do UP.

Livros

[1] Enterprise Integration Patterns, Gregor Hohpe, Addison Wesley, 2003

[2] Pattern Oriented Software Architecture – vol 05, Buschmann e al., Wiley and sons, 2007

[3] A Arte da Guerra – Sun Tzu, Século IV A.C.