SubMundo Java

Este post é a parte final do resumo do artigo “Exploring Patterns and Principles of a New Generation of SOA Solutions” da 22a. edição da revista “The Architecture Journal”. O artigo original discute sobre alguns desafios das tradicionais arquiteturas orientadas a serviço e explora alguns padrões e princípios para as novas gerações de arquiteturas orientadas a serviço, SOA.

Abraçando a WEB: Serviços RESTful

Apesar dos Web Services serem desenvolvidos para muitos protocolos o que vemos na grande maioria das implementações é o uso do protocolo HTTP como meio para o transporte de outro protocolo o SOAP. Esse excesso de abstração da camada de transporte impossibilita o uso dos recursos do protocolo HTTP. Por quê não utilizar HTTP somente?

Um dos meios para utilizar o protocolo HTTP para distribuir serviços, Web Services, de maneira amigável seria o uso do REST. Seguindo os princípios do REST podemos ter uma arquitetura SOA altamente escalável. Sem dúvida REST se tornou uma alternativa muito atraente para substituir os Web Services SOAP/WS-*, resolvendo os problemas citados na Parte 1, como interoperabilidade e escalabilidade. Segue algumas características dos serviços RESTful:

• Endereçamento de recursos/serviços através de uma URI
• Interações baseadas somente em HTTP
• Uso de métodos padrões HTTP (GET, POST, PUT, etc)
• Interações sem estado
• Possibilita diferentes formatos de distribuição
• Armazenamento em Cache
• Iteroperabilidade
• Escalabilidade

A simplicidade e o alto nível de interoperabilidade dos serviços em RESTful são alguns dos fatores que podem melhorar a agilidade da próxima geração de soluções SOA.

Interoperabilidade com WS-*

Apesar do notável trabalho acadêmico realizado na família de protocolos WS-* percebemos que ainda não supre as expectativas iniciais. Interoperabilidade e complexidade ainda são desafios importantes que encaramos na adoção dos protocolos WS-*. A melhor prática para melhorar a interoperabilidade dos protocolos WS-* é identificar as características dos consumidores dos serviços e criar endpoints distintos para cada particularidade desses consumidores. Por exemplo, vamos considerar um senário que devemos assegurar um Web Service que irá ser consumido por aplicações .NET, Sun Metro, Oracle Weblogic e Ruby on Rails. Neste senário podemos permitir que três endpoints com diferentes configurações de segurança atendam às diferentes características das aplicações que consomem o Web Service, como mostrado na Figura 6:

Padrão de múltiplos endpoints de serviços

Federação de ESB: Um caminho menos árduo

Vimos na sessão anterior que uma arquitetura com um ESB centralizado é uma das causas fundamentais de falhas na implementação de um sistema SOA. Após inúmeras tentativas de implementação de um ESB centralizado em grandes organizações a indústria está adotando um padrão mais ágil de implementação do ESB. Essencialmente, esse novo padrão visa particionar as funcionalidades em leves ESBs físicos que são agrupados como entidades federativas. Este padrão é comumente conhecido como Federação de ESB e representa uma das emergentes arquiteturas para implementar soluções ESB de alta escalabilidade. Com essa arquitetura podemos ter uma infraestrutura ESB específica para interfaces Business to Business, outra para troca de transações financeiras, como mostrada na Figura 6.

Padrão de Federação de ESB

Governça em SOA: Capitalizando SOA

A limitada adoção do UDDI em sistemas SOA de grande porte tem sido um catalisador do surgimento de um modelo mais leve e mais interoperável de governaça em SOA, levando em conta tecnologias como REST e Web 2.0. Essencialmente, esses modelos foram criados para remover algumas complexidades que são apresentadas pelo modelo UDDI centralizado, substituindo algumas tecnologias por outras amplamente adotadas como HTTP, Atom e JSON.
Uma das formas mais populares de implementar esse novo modelo de governaça SOA é utilizar um repositório de serviços RESTful. Neste modelo a implementação tradicional SOA como serviços, endpoints, operações e mensagens são representadas como recursos que podem ser acessados através de um conjunto de interfaces RESTful.
O maior benefício que traz esse novo modelo é a interoperabilidade ganha utilizando interfaces RESTful, como mostrada na Figura 7, além de ser uma abordagem muito mais leve e flexível.

Repositório RESTful

Bem-vindo a Computação em Núvem

A computação em núvem pode auxiliar em uma arquitetura SOA híbrida, onde alguns componentes de um sistema SOA possam estar em uma outra infraestrutura. Alguns exemplos do uso da computação em núvem em um sistema SOA:

• ESB na Núvem: Podemos hospedar um ESB na núvem? Claro que podemos! Este tipo de arquitetura possibilita disponibilizar todos os recursos de um ESB através de uma infraestrutura na Núvem.
• Serviços de Segurança na Núvem: Nos últimos anos temos percebido o aumento da adoção de serviços de segurança, assim como o Windows Live ID ou o Facebook Connect, e usar a Núvem para prover serviços de segurança pode facilitar a implementação de mecanismos altamente interoperáveis, disponibilizando serviços de autenticação, identificação e autorização a diversos clientes distintos.
• Serviços de Armazenamento na Núvem: Indiscutivelmente, serviços de armazenamento como Amazon S3 ou o Azure DB são os serviços mais atraentes encontrados na Núvem. Considerar esse mecanismo pode alavancar a flexibilidade e a interoperabilidade da troca de dados de seu sistema SOA, além de eliminar algumas complexidades existentes em se ter uma infraestrutura própria para armazenamento de dados.

Serviços na Núvem

Conclusão

A tradicional arquitetura SOA implica em sérios desafios que tornam impraticável implementações em larga escala. Este artigo post sugeriu uma série de padrões que podem ajudar o desenvolvedor a ter uma implementação mais leve, interoperável e escalável de SOA, possibilitando realmente serviços de negócio com agilidade em senários de larga escala empresarial.

Abstração de Protocolos:

• Considerar primeiro o protocolo padrão, HTTP. Ele é muito leve e pode conversar com outros frameworks.
• Fazer uso do SOAP e WS-* quando houver necessidade de controle de transações ou a necessidade de muita performance no protocolo TCP/IP.

SOAP e WSDL:

• Não fazer uso de SOAP e WSDL até ter certeza que vai precisar de algum recurso que eles oferecem.
• Considerar o uso de REST, JSON e Atom Pub como alternativas mais leves.
• Não cair na armadilha de gerar o WSDL a partir do código, o contrato vem sempre em primeiro.

Governaça

• Fazer uso de um repositório de serviços para ajudar a gerenciar os serviços de sua empresa.
• Considerar o uso de um repositório de serviços RESTful.

Enterprise Service Bus

• Não confundir um ESB com um sistema que processa eventos.
• Considerar o uso de federação de ESBs.

Serviços baseados na Núvem

• Considerar serviços de segurança local, privado ou públic baseados na Núvem, é um dos os serviços mais maduros que existe na Núvem
• Considerar a possibilidade futura de serviços de armazenamento e serviços de ESB na Núvem.

A coisa mais importante que você deve ter em mente quando está contruindo sua aplicação SOA é o mantra “Convenção ao invés de Configuração”. Diminuindo o número de opções ao mínimo e fazendo somente o que são requisitos do negócio, você deve acreditar que é possível contruir uma arquitetura orientada a serviços que seja leve, fácil de manter e evoluir, mesmo em ambientes de larga escala empresarial.

Minha Conclusão

Acho que essa segunda parte extendeu um pouco, portanto, vou deixar minha conclusão para uma terceira parte.

Mesmo assim nessa segunda parte podemos ver as sugestões de Jesus Rodriguez e Don Demsak para solucionar alguns dos problemas encontrados nas implementações tradicionais SOA. Espero que tenham gostado, mas se não gostaram podem deixar suas queixas nos comentários irei acatá-las com certeza. Até a próxima parte…

Este post é um resumo do artigo “Exploring Patterns and Principles of a New Generation of SOA Solutions” da 22a. edição da revista “The Architecture Journal”. O artigo original discute sobre desafios das tradicionais arquiteturas orientadas à serviço e explora alguns padrões e princípios para as novas gerações de arquiteturas orientadas à serviço, SOA.

SOA: Arquitetura sem Restrições

SOA tem sido o cerne dos sistemas distribuídos nos últimos anos, prometendo agilidade na implementação de serviços de negócio através de interfaces de negócio. É muito comum encontrar um conjunto de características semelhantes entre os tradicionais sistemas em SOA, sendo elas:

• A adotação do SOAP e WSDL como padrão para especificar o contrato, ou interface, dos serviços.
• O uso dos protocolos WS-* para pertimir algumas características de missão crítica aos serviços.
• O uso de um ESB central abstraindo diferentes orquestrações de serviço.
• O uso de um servidor de integração para gerenciar complexos processos de negócio, BPM.
• O uso de ferramentas de governança em SOA para gerenciar toda arquitetura de serviços.

Figura 1: O modelo ideal SOA

A arquitetura apresentada na Figura 1 pode ser considerada ideal pra sistemas SOA, mas esta arquitetura não leva em consideração as retrições que os sistemas SOA impõem à arquitetura, como interoperabilidade, performance e escalabilidade. A arquitetura apresentada na Figura 1 leva em consideração abstrair a complexidade de implementação dos sistemas SOA utilizando mais padrões e ferramentas.

Ultimamente se ouve muito o mantra Conveção ou invés de Configuração, que remove opções de configuração, ou parâmetros, que aumentam a complexidade do sistema por convenções previamente adotadas. Utilize as opções de configuração somente quando for realmente necessário.

SOAP: A ilusão de uma abstração da camada de transporte

Inicialmente o SOAP foi desenvolvido para abstrair os serviços das diferentes camadas de transporte, ou protocolos. Embora na teoria se mostre uma boa idéia, na prática constatamos que abstrair os serviços da camada de transporte exige um custo significativo de complexidade. Um exemplo da complexidade desta abstração é trafegar SOAP sobre HTTP, que hoje em dia é frequente. Por quê não usar o HTTP somente?

WSDL: Em abundância

O WSDL tem como propósito descrever os características dos serviços e as mensagens trocadas. Conceitualmente, o WSDL representa uma evolução para do antigo IDL. Ao utilizar o WSDL como padrão para especificar os serviços, esse se torna um artefato vital para as aplicações clientes. Essa relação entre o provedor de serviços e o cliente tende a ter um acoplamento alto, sendo que se houver uma alteração no contrato dos serviços o(s) cliente(s) serão afetados. Pensando em uma ambiente pequeno que envolve poucos clientes consumindo alguns serviços não é preocupante, mas em um ambiente empresarial e complexo o alto acoplamento entre o cliente e o provedor de serviços é um problema a se considerar.

Figura 2: Auto acoplamento com WSDL, o grande desafio de sistemas SOA de grande porte

ESB: Ter ESB ou não ter ESB

A integração heterogênea de sistemas, LOB, tem sido uma grande promessa dos sistemas empresarias SOA. Para pôr em prática essa integração entre diferentes sistemas heterogêneos foi determinado um conjunto de padrões que constituem o ESB. Ainda que não exista um padrão industrial que defina o que é um ESB, podemos adotar algumas características comuns entre os ESBs existentes no mercado. Atualmente o ESB é usado como um barramento central de serviços, como mostrado na Figura 3:

Figura 3: ESB centralizado

Pode parecer uma boa estratégia arquitetural utilizar o ESB de forma centralizada, mas na prática esse tipo de arquitetura apresenta sérias limitações nos aspectos de gerenciamento, performance e escalabilidade. Ao inves do ESB se tornar um facilitador ele pode se tornar um gargalo em sistemas SOA.

Protocolos WS-*: O lado negro

Os protocolos WS-* criados para complementar características de segurança, confiabilidade e transacionabilidade ao SOAP/WSDL não receberam muita adoção em ambientes heterogêneos. Um dos motivos da não adoção dos protocolos WS-* está nas centenas de diferentes versões de protocolos WS-* existentes, isso cria desconfiança e descredibilidade na tecnologia. A interoperabilidade é o maior desafio das soluções baseadas em protocolos WS-*, como diferentes ferramentas de Web Services as vezes implementam diferentes protocolos WS-* teremos então diferentes versões dos mesmos protolos e mesmo diferentes aspectos da mesma especificação.

Figura 4: O desafio da interoperabilidade

Governaça em SOA: Ditatura em SOA

Em sistemas SOA de médio e grande porte existe a necessidade de versionar, monitorar e gerenciar os serviços de negócio e esse papel é realizado pelas ferramentas de governaça em SOA. O maior desafio dessas ferramentas de governança é permitir de maneira confiável o gerenciamento de complexos serviços de negócio, por este motivo as tecnologias de governança em SOA tem crescido muito nos últimos tempos. As tecnologias de governaça estão adotando uma arquitetura que virtualiza os serviços de negócio em um ambiente centralizado de governaça. Embora, essa arquitetura possa ser aplicada em sistemas SOA de pequeno porte, ela apresenta sérias limitações em termos de iteroperabilidade, performance e escalabilidade em ambientes de sistemas SOA de grande porte, como mostrado na Figura 5:

Figura 5: Modelo centralizado de governança SOA

Conclusão

Nesta primeira parte do artigo foi explorado as arquiteturas SOA adotadas comumente nos dias de hoje. Na abstração da camada de transporte dos serviços de negócio foi mostrada a adoção do protocolo SOAP utilizando a especificação WSDL para manter um contrato, ou interface, dos serviços de negócio disponíveis que acarreta em uma sobrecarga de protocolos e um aumento muito significativo do acoplamento entre o provedor de serviços de negócio e os clientes cosumidores destes serviços.

Também foi mostrada a arquitetura centralizada do ESB que apresenta limitações em termos de gerenciamento, performance e escalabilidade. As diversas implementações dos protocolos WS-* que são utilizadas de forma não padronizada criando desconfiança e descredibilidade da tecnologia. Como a arquitetura centralizada do ESB foi mostrada a arquitetura que virtualiza os serviços de negócio em um ambiente centralizado de governança SOA que apresenta limitações de interoperabilidade, performance e escalabilidade.

Na segunda parte deste artigo será discutido arquiteturas e tecnologias que visão melhorar alguns aspectos negativos mostrados nessa primeira parte do artigo. Até lá .