De que se trata o artigo:

O artigo apresenta técnicas e práticas provadas de integração de aplicações Java com outras aplicações, sistemas e bancos de dados. Projetos de integração apresentam muitas complexidades técnicas e muitas possibilidades técnicas em Java tais como JMS, JCA, JDBC, RMI, HTTP e SOAP. O artigo mostra como escolher estas tecnologias e como utilizá-las adequadamente através de padrões de integração de aplicações (EIP).


Para que serve:

O artigo é útil para que desenvolvedores possam conhecer os riscos associados à integração de sistemas Java com outros sistemas e aplicar as melhores práticas de mercado e padrões de integração para mitigar e eliminar estes riscos. Projetos com riscos técnicos reduzidos possuem maior garantia de sucesso, maior qualidade, estabilidade e manutenções mais simples e facilitadas.


Em que situação o tema é útil:

Em projetos de TI que requerem integrações de todo tipo, como bancos de dados relacionais, bases de dados em outros formatos, sistemas de filas de mensagens, aplicações legadas em plataformas baixas e altas ou aplicativos como CRM (Customer Relationship Management) e ERP (Enteprise Resource Planning).

Estratégias de Integração de Aplicações Java EE:

Integrar aplicações Java com outros sistemas não é uma tarefa trivial. Para reduzir riscos e manter projetos sob controle, devemos usar práticas provadas de integração de sistemas.

As melhores práticas de integração são denominadas padrões EAI (EAI Patterns) e foram popularizadas por Gregor Hohpe através do seu livro Enterprise Integration Patterns. Estas práticas permitem que um arquiteto ou desenvolvedor escolha as estratégias mais eficientes de integração de sistemas Java com outros sistemas e produza soluções mais perenes e econômicas.

Estas práticas de integração também são fundamentais para empresas que estejam buscando iniciativas SOA e BPM, pois permitem gerir adequadamente a criação e evolução de serviços (ativos) em repositórios de serviços (ESB).

Um processo simples para que você possa aprender a integrar sistemas em projetos envolve os seguintes passos: (1) Coletar os requisitos arquiteturais de interoperabilidade; (2) Desenvolver soluções independentes de tecnologia para cada requisito arquitetural coletado; (3) Estudar os exemplos disponibilizados na referência [1]; (4) Estudar as tecnologias Java mais adequadas para cada requisito (ex: WebServices ou RMI); (5) Implementar os cenários com as tecnologias Java escolhidas; (6) Testar as soluções em ambiente de homologação.

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.

Estilo de Interoperabilidade

APIs/Tecnologias Java

Transferência de Arquivos

Streams I/O; Soquetes

Bancos de Dados Compartilhados

JDBC

Procedimentos Remotos (RPC)

Servlets, JCA, Web Services/SOAP

Passagem de Mensagens

JMS, Web Services/SOAP

Tabela 1. Tecnologias Java para suportar estilos de interoperabilidade.

Níveis de Interoperabilidade

APIs/Tecnologias Java

Nível de Dados

JDBC

Nível de Interface de Aplicação

Servlets, EJB/RMI, JCA, Web Services/SOAP, JavaMail

Nível de Processos de Negócio

JBI (Java Business Integration), OpenSOA SCA

Nível de Apresentação

Portlets

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

Topologias de Interoperabilidade

APIs/Tecnologias Java

Ponto a ponto

Servlets, WebServices/SOAP, EJB/RMI

Hub and Spoke

JBI, OpenSOA SCA

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.

Padrão EAI

Pergunta endereçada

Messaging

Como eu posso integrar múltiplas aplicações de forma que elas possam trocar informações?

Message Channel

Como uma aplicação se comunica com outra através de mensagens?

Message Endpoint

Como uma aplicação se conecta a um canal de mensagens para enviar e receber mensagens?

Document Message

Como mensagens podem ser usadas para transferir dados entre aplicações?

Content Enricher

Como mensagens podem ser enviadas para outro sistema se o originador não tem todas as informações necessárias?

Selective Consumer

Como um consumidor de mensagens (ex: Microsoft Exchange) pode selecionar que tipos de mensagens ele deseja receber.

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.

Padrão EAI

Comentários

Message Broker

Captura a essência das soluções ESB de mercado. Note que o termo ESB, em sua definição original, é um padrão ou estilo arquitetural e não uma tecnologia ou especificação.

Produtos como o JBoss ESB ou Apache ServiceMix podem ser vistos como produtos que implementam o padrão EIP Message Broker.

Process Manager

Captura a essência das soluções BPMS de mercado. O padrão Process Manager permite que uma integração com múltiplas fontes de dados e aplicações possam ser integradas através de um fluxo de trabalho arbitrário.

Produtos como o JBoss BPM ou IBM WebSphere Process Server são exemplos deste padrão.

A linguagem BPEL (Business Process Execution Language) é um exemplo de linguagem usada para descrever os fluxos do padrão Process Manager.

Normalizer

Padrão usado para implementar a interoperabilidade com múltiplos protocolos em aplicações ESB.

Um produto como o JBoss ESB, por exemplo, suporta FTP, HTTP, SMTP, HTTPS e diversos outros formatos para interoperar aplicações.

No interior da sua solução, vemos que o padrão Normalizer foi usado para suportar isso.

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.