Uma visão geral de problemas de interoperabilidade

A maioria dos problemas de interoperabilidade surge não da especificação de serviços da Web base (o que está bem maduro e estável), mas das diversas extensões de serviços da Web WS-*, como WS-Security. À medida que esses padrões evoluem, fornecedores devem escolhe quais especificações de rascunho suportar e desenvolvedores ocasionalmente precisam lidar com problemas de incompatibilidade entre as diferentes especificações.

O padrão WS-Security fornece mecanismos para aplicar autenticação, integridade e confidencialidade a mensagens SOAP. Esses recursos são frequentemente necessários para adoção de serviços da Web e de Services-Oriented Architecture (SOA) dentro da empresa. O middleware da IBM® começou a fornecer suporte para WS-Security no IBM WebSphere® Application Server V5.0.2. Essa implementação de WS-Security era baseada na especificação OASIS rascunho de trabalho 13. O WebSphere Application Server V5.1 e outros middleware IBM baseados nos tempos de execução Java™ 2 Platform, Enterprise Edition (J2EE) 1.3 (como o IBM WebSphere Portal Server V5 e o IBM WebSphere Business Integration Server Foundation V5) também contêm implementações de WS-Security baseadas na especificação rascunho 13. Com o tempo de execução J2EE 1.4 incluído no WebSphere Application Server V6.0, a IBM forneceu uma implementação de WS-Security baseada na especificação WS-Security 1.0. O IBM WebSphere Process Server e outros middleware IBM middleware usando tempos de execução J2EE 1.4 contêm implementações de WS-Security baseadas na especificação versão 1.0.

Infelizmente, devido às mudanças no formato de ligação da especificação de cabeçalho SOAP WS-Security, aplicativos consumidores de serviço da Web e serviços da Web de destino conformes com a especificação rascunho 13 não podem interagir com aplicativos consumidores e serviços de destino conformes com a especificação versão 1.0. Por exemplo, um aplicativo consumidor de serviço da Web J2EE 1.3 em execução no WebSphere Portal Server V5.1 não pode usar WS-Security para se comunicar com um aplicativo provedor de serviços J2EE 1.4 em execução no WebSphere Application Server V6.0. E o problema não está limitado à pilha de software de middleware IBM. Por exemplo, o Microsoft® .NET Web Services Enhancements (WSE) 1.0 também é baseado em uma versão de rascunho da especificação WS-Security e os mesmos problemas de interoperabilidade ocorrem ao tentar se comunicar entre essa pilha e qualquer outra baseada na especificação WS-Security 1.0.

Se confrontado por essa incompatibilidade, você tem algumas opções para contornar o problema. O restante deste artigo descreve essas opções e fornece alguma orientação para escolher uma solução apropriada com base em seus requisitos de negócios e restrições técnicas.

Por questão de simplicidade, vamos supor que o aplicativo consumidor de serviço da Web use a especificação WS-Security rascunho 13 e que o aplicativo provedor de serviços da Web use a especificação WS-Security 1.0. Observação: As soluções alternativas sugeridas aqui também podem ser aplicadas ao cenário reverso, em que o consumidor do serviço da Web usa a especificação WS-Security 1.0 e o provedor de serviços da Web usa a especificação rascunho 13.

Voltar para parte superior

Solução alternativa 1: Atualizar aplicativos consumidores de serviços da Web para J2EE 1.4

A maneira mais fácil de evitar o problema completamente é assegurar que seus aplicativos consumidores de serviços da Web estejam usando a mesma versão da especificação WS-Security que seus aplicativos provedores de serviços da Web. Isso requer atualizar seu aplicativo consumidor de serviço da Web para J2EE 1.4 e, possivelmente, também atualizar seu middleware para uma versão que suporte aplicativos J2EE 1.4.

A atualização de aplicativos consumidores de serviços da Web J2EE 1.3 para J2EE 1.4 é um exercício de desenvolvimento. O IBM Rational® Application Developer fornece um assistente de migração de J2EE que é capaz de migrar projetos de Enterprise JavaBeans (EJB), projetos da Web, projetos de J2EE Connector Architecture (JCA) Connector e serviços da Web do nível de especificação J2EE 1.3 para o nível de especificação J2EE 1.4.

Para usar o assistente de migração de J2EE para migrar um aplicativo J2EE 1.3 para J2EE 1.4, simplesmente clique com o botão direito do mouse no projeto Enterprise Application na visualização Project Explorer de J2EE Perspective, em seguida, selecione Migrate > J2EE Migration Wizard no menu pop-up. Após o assistente ser concluído, é possível configurar as ligações de cliente WS-Security. Essas ligações não são migradas automaticamente pelo assistente e devem ser configuradas manualmente como uma tarefa pós-migração.

Em seguida, é necessário assegurar que o servidor de aplicativos no qual seu aplicativo consumidor de serviços da Web está implementado seja capaz de suportar aplicativos J2EE 1.4. Para aplicativos corporativos, o WebSphere Application Server V6.0 é capaz de executar aplicativos J2EE 1.4. E para portlets, o WebSphere Portal Server V5.1.0.4 é capaz de executar um projeto da Web que foi migrado para J2EE 1.4. Se tiver esta ou versões posteriores, então seus aplicativos consumidores de serviços da Web migrados devem ser executados sem problemas. Caso contrário, pode ser necessário atualizar seu middleware.

Migrar seus aplicativos e (se necessário) seu middleware para J2EE 1.4 é a maneira preferencial de se evitar problema de interoperabilidade de nível de especificação WS-Security. Isso elimina o problema completamente e fornece os benefícios estratégicos de se estar nos níveis de código de middleware mais recentes.

No entanto, dependendo de seus aplicativos e de seu ambiente de middleware, pode ser inconveniente ou difícil migrar seus aplicativos consumidores de serviços da Web para J2EE 1.4. Além do mais, o esforço necessário para implementar essa abordagem aumenta de forma linear com cada aplicativo consumidor de serviços da Web adicional usando a especificação WS-Security rascunho 13 que deve ser migrado.

Voltar para parte superior

Solução alternativa 2: Usar um Web Services Gateway

O Web Services Gateway é um componente de software do IBM WebSphere Application Server Network Deployment, que pode ser configurado como opção após a instalação do produto. IBM WebSphere DataPower SOA Appliances são dispositivos de rede com propósito de criação de fácil implementação. Web Services Gateway e WebSphere DataPower SOA Appliances têm a intenção de ajudar a simplificar e proteger a implementação de serviços da Web na empresa. WebSphere DataPower SOA Appliances também pode ser usado para melhorar o desempenho de aplicativos de serviços da Web.

O Web Services Gateway ou um DataPower appliance pode ser usado para abordar o problema de interoperabilidade de nível de especificação WS-Security. Conforme mostrado na Figura 3, ambas as soluções têm a capacidade de efetuar proxy de um serviço da Web que usa a especificação WS-Security 1.0 e disponibilizar esse serviço a todos os consumidores de serviços da Web que usam a especificação WS-Security rascunho 13.

Observação: No restante deste artigo, essa solução alternativa é referida como a abordagem proxy de middleware .

Uma vantagem da abordagem de proxy de middleware é que nenhuma tarefa de desenvolvimento de aplicativo é necessária. Os aplicativos provedores e consumidores de serviços da Web podem interoperar por meio do proxy de middleware sem mudanças. Por essa razão, o proxy de middleware escala bem quando há muitos consumidores de serviços da Web usando a especificação WS-Security rascunho 13 que precisam ser integrados a um provedor de serviços da Web usando a especificação WS-Security 1.0. Após o proxy de middleware ter sido instalado e configurado com um serviço provedor, ele pode ser usado para integrar qualquer número de consumidores de serviços da Web sem esforço adicional.

Outra vantagem para essa abordagem é obter todos os benefícios de usar o Web Services Gateway ou o DataPower appliance. Esses componentes podem simplificar implementação e gerenciamento de serviços da Web na empresa e, ao fazerem isso, melhoram o retorno sobre investimento para seus aplicativos de serviços da Web e infraestrutura. Além do mais, se você optar por usar um DataPower appliance, os recursos do dispositivo podem até mesmo melhorar o desempenho de seus aplicativos de serviços da Web. Para obter informações adicionais sobre os benefícios do Web Services Gateway e do WebSphere DataPower SOA Appliances, consulte os links na seção Recursos no final deste artigo.

Uma desvantagem da abordagem de proxy de middleware é que apresenta um conjunto de operações e tarefas de administração não triviais. Você deve instalar, configurar e gerenciar o componente de proxy de middleware como qualquer outro componente de infraestrutura crítico. Se tiver comprado o WebSphere Application Server Network Deployment Edition, então você já possui o componente Web Services Gateway e nenhuma compra adicional é necessária. Por outro lado, se optar por usar um DataPower appliance, pode haver custos associados à aquisição desse dispositivo de rede.

Outra desvantagem é que essa abordagem pode quebrar o modelo de confiança entre o consumidor de serviços da Web e o provedor de serviços da Web. Isso porque, dependendo da segurança que está sendo aplicada, o proxy de middleware pode precisar verificar e decriptografar a mensagem SOAP recebida enviada do consumidor ao proxy e, em seguida, reaplicar segurança na mensagem SOAP de saída que é enviada do proxy para o provedor. Isso pode ter sérias implicações para sua arquitetura de segurança.

Voltar para parte superior

Solução alternativa 3: Usar um proxy EJB

Se estiver procurando uma alternativa leve de baixo custo para a abordagem de proxy de middleware, usar um proxy EJB pode ser adequado. Nesta abordagem, um novo aplicativo EJB J2EE 1.4 é desenvolvido e implementado a camada de middleware de front-end, que também hospeda o aplicativo consumidor de serviços da Web. Esta abordagem requer que a camada de middleware de front-end contenha o WebSphere Application Server V6.0 ou posterior ou outro servidor de aplicativos J2EE capaz de suportar aplicativos J2EE 1.4.

A Figura 4 mostra como a abordagem de proxy EJB é usada para permitir que um aplicativo de portal J2EE 1.3 se comunique com um provedor de serviços da Web J2EE 1.4. O aplicativo de portal se comunica com o proxy EJB usando a interface Remote Method Invocation (RMI) do EJB e o EJB passa a solicitação para o provedor de serviços da Web usando a especificação WS-Security 1.0.

O esforço necessário para implementar a abordagem de proxy EJB é principalmente trabalho de desenvolvimento de aplicativo, apesar de esta solução alternativa apresentar outro aplicativo que deve ser implementado, protegido e gerenciado pela equipe de operações.

A abordagem de proxy EJB é mais adequada para situações de ambiente de simulação, teste ou prova de conceito, em que a atualização de aplicativos consumidores de serviços da Web para J2EE 1.4 não é uma opção e em que o custo de configurar um proxy de middleware é proibitivo. Uma desvantagem dessa abordagem é que não escala bem quando há muitos consumidores de serviços da Web usando a especificação WS-Security rascunho 13 que precisam ser integrados a um provedor de serviços da Web que usa a especificação WS-Security versão 1.0. Neste caso, cada aplicativo consumidor de serviços da Web deve ser integrado separadamente ao proxy EJB, o que pode tornar o esforço de desenvolvimento necessário grande.

Voltar para parte superior

Solução alternativa 4: Incluir um novo terminal de provedor

Nesta última abordagem, você inclui um terminal de serviços da Web J2EE 1.3 no aplicativo provedor J2EE 1.4. Dependendo de como seu aplicativo provedor de serviços da Web J2EE 1.4 é implementado, pode ser um exercício simples incluir um projeto da Web adicional com base na especificação Java Servlet 2.2 (J2EE 1.3) e empacotar o mesmo com o aplicativo provedor. Seu aplicativo provedor conterá então dois terminais de serviços da Web, conforme mostrado na Figura 5.

Esta abordagem escala bem quando há muitos aplicativos consumidores de serviços da Web. Após o aplicativo provedor de serviços da Web ser modificado para que forneça um terminal de serviços da Web compatível com J2EE 1.3, um número qualquer de aplicativos consumidores de serviços da Web pode usar esse ovo terminal. E diferentemente da abordagem de proxy EJB ou da abordagem de proxy de middleware, esta abordagem não tem nenhum impacto no desempenho.

Como com a abordagem de proxy EJB, esta solução alternativa é principalmente um exercício de desenvolvimento de aplicativo e apresenta outro terminal de serviços da Web que deve ser gerenciado e protegido.

Esta abordagem é mais bem usada quando as classes de implementação de serviço da Web são componentes JavaBeans ou componentes EJB simples. Se a lógica de implementação de serviço da Web estiver contida em um servlet, em um componente Service Component Architecture (SCA) ou em um módulo de mediação Enterprise Service Bus (ESB), então, provavelmente, será difícil criar o projeto da Web Java Servlet 2.2 (J2EE 1.3) e empacotá-lo com o aplicativo provedor de serviços da Web.

Voltar para parte superior

Resumo

A Tabela 4 descreve os benefícios e as desvantagens relativos das três soluções alternativas descritas neste artigo para ajudá-lo a determinar a melhor abordagem de solução alternativa para sua situação.

Fique ligado nos artigos subsequentes desta série, que fornecerão detalhes e exemplos que mostram como implementar as soluções alternativas de proxy de middleware e proxy EJB.

Agradecimentos

Gostaria de agradecer as seguintes pessoas por seus comentários e contribuições para este artigo:

• Hyen Chung, arquiteto e desenvolvedor líder de segurança de serviços da Web na plataforma WebSphere
• Billy Lo, senior IT architect, IBM Global Business Services

Recursos

Aprender

• Saiba sobre Web Services Security specification (developerWorks, março 2004), incluindo uma visão geral de WS-Security, links para a especificação atual e tópicos relacionados.
  
  
• Saiba sobre IBM WebSphere DataPower SOA Appliances.
  
  
• IBM Redbooks: "WebSphere Version 6 Web Services Handbook Development and Deployment" descreve os conceitos de serviços da Web a partir de várias perspectivas. Apresenta os principais blocos de construção dos quais serviços da Web dependem. Aqui, padrões bem definidos e novos conceitos são apresentados e discutidos.
  
  
• A zona SOA e Serviços da Web no IBM developerWorks hospeda centenas de artigos informativos e tutoriais introdutórios, intermediários e avançados sobre como desenvolver aplicativos de serviços da Web.
  
  
• O Web site do IBM SOA oferece uma visão geral de SOA e como a IBM pode ajudá-lo a chegar lá.
  
  
• Visite a área Architecture do developerWorks para obter os recursos necessários para aprimorar suas qualificações na área de arquitetura.
  
  
• Fique por dentro dos eventos técnicos e webcasts do developerWorks.
  
  
• Procure livros sobre estes e outros tópicos técnicos na Safari bookstore.
  
  
• Obtenha um feed RSS para esta série. (Descubra mais sobre RSS.)
  
  

Obter produtos e tecnologias

• Inove em seu próximo projeto de desenvolvimento com o software de avaliação da IBM, disponível para download ou em DVD.
  
  

Discutir

• Participar do fórum de discussão.
  
  
• Confira os blogs do developerWorks e participe da comunidade do developerWorks.
  
  

Sobre o autor

David Leigh é Senior Software Engineer na organização Scenario Analysis Lab do IBM Software Group, localizada no Research Triangle Park, Carolina do Norte. Suas áreas de conhecimento incluem o IBM WebSphere Process Choreographer, segurança de aplicativo e servidor, alta disponibilidade, monitoramento, IBM AIX® e Linux®.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Uma visão geral de problemas de interoperabilidade
• Solução alternativa 1: Atualizar aplicativos consumidores de serviços da Web para J2EE 1.4
• Solução alternativa 2: Usar um Web Services Gateway
• Solução alternativa 3: Usar um proxy EJB
• Solução alternativa 4: Incluir um novo terminal de provedor
• Resumo
• Agradecimentos
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais