Artigos Java SOA na prática - Artigo Java Magazine 62
De que se trata o artigo:

O artigo aborda princípios básicos de SOA e de um barramento corporativo bem como exemplos de uma ferramenta especializada.

Para que serve:

Fornecer o caminho a quem quer iniciar os estudos em SOA e abordar o assunto de forma prática e direta, algo raro na literatura técnica hoje em dia.

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

SOA é um tema muito atual e várias empresas já estão migrando suas aplicações para suportar seus conceitos e tecnologias. Um ESB é o coração de uma arquitetura orientada a serviços e mostramos no artigo quais são os componentes básicos para a criação de serviços corporativos com transformações (XQuery e XPath), além de conceitos de abstração (proxy e business service) através de exemplos práticos.

SOA na prática:

O artigo mostra como criar serviços corporativos de maneira prática e simplificada apresentando uma ferramenta poderosa, o Aqualogic Service Bus ou simplesmente ALSB. Através do uso de XQuery e XPath, transformações e conceitos de roteamentos são apresentados. Também são apresentados exemplos de consumo de um serviço da internet, disponibilizando esse serviço através de um proxy service, exemplificando como aplicar abstração em uma arquitetura SOA.

Cada vez mais tem se falado sobre SOA e seus benefícios, suas estratégias e diversas recomendações para sua empresa ou seu negócio se tornar SOA-enabled. O que temos visto, porém, é que não são tão comuns artigos técnicos, relacionados à implementação prática do que realmente suporta os princípios que SOA tanto prega: alinhamento das áreas de negócio com TI, reuso, desacoplamento, roteamento de mensagens e governança.

Através da exposição de serviços, a composição de novos serviços e novas aplicações se torna o resultado natural da combinação dos já expostos, dando a agilidade que as áreas de negócio tanto precisam para ousar mais e se destacar no mercado.

Veremos nesse artigo um pouco sobre como expor e orquestrar esses serviços de forma padronizada através de uma ferramenta que implementa o padrão arquitetural conhecido como Enterprise Service Bus (ESB, ou barramento corporativo de serviços).

SOA

Esse artigo focará fortemente na prática, porém uma introdução sobre o conceito de arquitetura orientada a serviços será necessária para justificarmos a necessidade de um barramento de serviços.

SOA é um novo paradigma com foco em prover um maior reuso e eficiência na criação ou manutenção de funcionalidades e aplicações de uma empresa. Em uma arquitetura orientada a serviços, as funcionalidades que antes estariam contidas dentro de programas e sistemas de forma isolada, devem agora ser expostas na forma de serviços através de interfaces bem definidas, utilizando tecnologias interoperáveis e padrões abertos. A combinação de tudo isso possibilitará um alto grau de reuso e permitirá que novas funcionalidades sejam compostas rapidamente a partir do que já está exposto na forma de serviço.

Atualmente, a grande maioria das empresas está com demandas para TI com prazos cada vez menores, buscando a redução de custo e ganho de diferenciais junto aos clientes. Neste contexto, SOA e suas combinações surgem como uma das melhores soluções para unir as melhores práticas arquiteturais em um padrão com potencial para prover de maneira consistente o que as empresas atualmente precisam: maior alinhamento de TI com o negócio e maior investimento em inovação graças à economia gerada pelo reuso de sistemas e serviços.

O que é um barramento de serviços?

Um ESB não é um produto, mas sim um padrão arquitetural. Sua função é atuar como um intermediário entre a implementação de um serviço e a forma como ele é exposto para que seja consumido. Através disso, o barramento deve ser robusto e possuir recursos para facilitar a exposição e composição de serviços, roteamento de mensagens, transformação e enriquecimento de dados, segurança, entre vários outros aspectos, sempre focando em padrões abertos e interoperáveis, como XML, XSD, web services, etc.

Várias das idéias, funcionalidades e padrões implementados pelos ESBs disponíveis no mercado são uma evolução do que ferramentas de EAI e MOM já vêm apresentando há anos. Para mais informações sobre EAI, veja “EAI na Prática” na Edição 59. A grande diferença agora está na capacidade de expor as qualidades e facilidades de uma solução EAI através de padrões abertos. Thomas Erl em seu livro Service-Oriented Architecture - A Field Guide to Integrating XML and Web Services faz a seguinte comparação entre um barramento de serviços e ferramentas de EAI: “Um barramento de serviços é uma saída renovada do estigma proprietário geralmente associado a produtos de EAI tradicionais. Alguns fornecedores reconheceram uma oportunidade de combinar o melhor dos dois mundos, enquanto libera os clientes das dependências com fornecedores”.

EAI: Princípios de arquitetura para Integração de Aplicações Corporativas que permitem a integração entre sistemas heterogêneos em uma corporação.
MOM: Padrão arquitetural baseado na troca de mensagens, muito comum em arquiteturas de integração entre sistemas.

Um erro muito comum com relação a um ESB é dizer que ele “implementa” SOA ou que o fato de utilizar um ESB em sua arquitetura já a transforma em uma arquitetura orientada a serviços. Na verdade, um ESB é responsável por boa parte das funcionalidades que SOA prega, mas não todas. Instalar um barramento de serviços e acreditar que você automaticamente estará aderente a SOA é bobagem, entretanto, tentar implantar SOA sem um barramento de serviços é praticamente impossível.

Analisaremos nesse artigo um produto comercial que é o BEA AquaLogic Service Bus, também chamado de ALSB. Começaremos a detalhar a arquitetura do ALSB na próxima seção. O leitor interessado em acompanhar a prática pode baixar uma versão completa do ALSB, com licença de avaliação. Existem também opções open source como o JBoss ESB, ver artigo na Edição 59.

A arquitetura do AquaLogic Service Bus

O ALSB é a implementação de um barramento de serviços com foco nos requisitos necessários para a implantação de SOA em uma empresa: descoberta e intermediação de serviços, roteamento e transformação de mensagens, utilização de protocolos comuns e governança de serviços.

As características funcionais do ALSB podem ser classificadas nas seguintes camadas:

  • Camada de transporte: conecta e expõe serviços utilizando protocolos de mensageria padrão, além de permitir o uso ou construção de protocolos customizados, criados para finalidades específicas. É possível também utilizar facilmente formatos binários ou posicionais que não sejam XML, além da criação de protocolos customizados através de um SDK fornecido com o ALSB. Dentre os protocolos suportados pela ferramenta, podemos destacar:
    1. HTTP/HTTPS;
    2. JMS (inclusive MQ/JMS e JMS/XA);
    3. FTP/SFTP;
    4. E-mail (SMTP, POP, IMAP);
    5. EJB/RMI;
    6. Arquivos;
  • Camada de segurança: Permite configuração da segurança nos serviços expostos pelo ALSB, abstraindo as complexidades inerentes ao uso de segurança em aplicações distribuídas. É possível utilizar os conceitos de segurança para estabelecer regras de roteamento, acesso aos serviços existentes, protocolos de transporte, confidencialidade e integridade dos dados e mensagens. Suporta os padrões: SSL, WS-Policy/WS-Security, SAML e X509. Para aplicarmos os principais padrões de segurança para web services (WS-Policy/Security e SAML), a configuração é feita através de políticas de segurança que podem ser acopladas a qualquer serviço já desenvolvido;
  • Camada de composição: Interface baseada em metadados para a composição e orquestração de serviços, sincronização com registros UDDI para importação de serviços existentes e busca baseada em taxonomias, transformações, roteamento e invocação de serviços e código Java, além de prover uma interface chamada “ ...
    Quer ler esse conteúdo completo? Tenha acesso completo