SOA: princípios de projetos orientados a serviço

Por Raphael Oliveira Neves.

Em 02/05/2017 no site Profissionais de TI.

Muitas empresas e responsáveis de TI buscam constantemente agregar valor nos produtos e serviços entregues de várias maneiras, seja por meio de ciclos de entrega contínuos com pequenos pedaços funcionais de software, pela criação de aplicações infladas e cheias de recursos que muitas vezes sequer serão utilizados, desenvolvendo soluções baseadas na orientação a serviço, entre outras. Fato é que, independente da estratégia de atuação do departamento de TI, agregar valor não é uma tarefa fácil e requer, muitas vezes, grande esforço por parte dos envolvidos no projeto. Com a arquitetura orientada a serviços não seria diferente, pois esta, além de trazer grandes mudanças no paradigma de desenvolvimento de software, influencia diretamente na forma de gerenciar e governar TI na corporação, propondo desafios tecnológicos, operacionais, de infraestrutura, entre outros.

Um dos nomes mais expressivos quando o assunto é arquitetura orientada a serviços, Thomas Erl, define princípios aos quais são interpretados como termômetro na implantação do paradigma orientado a serviços numa corporação, porém, obviamente estes princípios não são – e nem devem ser – a bala de prata para os problemas de alinhamento entre a TI e o negócio. Estes princípios são conhecidos como:

• Padronização do contrato de serviço
• Baixo acoplamento
• Abstração do serviço
• Autonomia do serviço
• Visibilidade do serviço
• Independência do controle de estado do serviço
• Reusabilidade
• Capacidade de composição do serviço

Cada princípio supracitado mantém um relacionamento muito estreito com os demais, influenciando diretamente na forma com que cada um é planejado e implementado. Os princípios de baixo acoplamento, abstração do serviço e capacidade de composição são vistos como marcos reguladores para os demais princípios, tendo assim um papel de extrema importância em produtos oriundos da SOA.

Padronização do contrato de serviço

Manter contratos padronizados é muito importante para a orientação a serviço, pois estes atuam diretamente em cima dos objetivos estratégicos da interoperabilidade intrínseca e comunicação federalizada entre sistemas. Um contrato tem por objetivo principal definir as capacidades e o modelo de dados/expressão funcional de determinado serviço, ou seja, por meio da leitura de um contrato funcional de serviço, o consumidor deve ter clareza daquilo que o serviço se propõe a fazer e como fazer. Com isso, é possível determinar a estrutura de entrada e saída de dados para cada capacidade* no contexto funcional do serviço. Além disto, a padronização do contrato de serviço contribui para outra premissa importante na SOA: evitar a transformação de dados nas mensagens enviadas/recebidas.

É importante ressaltar que o contrato funciona como uma interface funcional do serviço, expondo somente informações necessárias para consumo do mesmo, desprezando qualquer tipo de informação específica de tecnologia, ou seja, o consumidor não precisa se preocupar em como a lógica da solução funciona, em qual linguagem de programação foi escrita, se consome dados de um determinado SGBD, entre outros, mas somente em como consumi-la. Um exemplo simplista seria a consulta de pessoas física e jurídica. O contrato do serviço Pessoa poderia expor a capacidade de “consultar” e o modelo de dados a ser enviado, por exemplo, uma lista de caracteres separados por vírgula. Veja que em momento algum o contrato de serviço definiu se era para enviar um CPF ou CNPJ, a validação da informação enviada e sua lógica de processamento, pois isto é uma especificação tecnológica a qual pode sofrer variações conforme a necessidade do negócio.

*Capacidade é um método ou atividade de serviço para se executar determinado processo da lógica de serviço.

Abstração do serviço

Abstrair um serviço é uma questão muitas vezes complicada, pois este deve ser genérico o bastante para se adaptar ao máximo de composições possíveis, mas ao mesmo tempo não pode ser abstrato demais ao ponto de o consumidor não saber do que se trata o serviço, favorecendo o cenário de redundância de recursos, desperdício financeiro e atraso da TI frente ao negócio. Este princípio prega o ideal de ocultar informações de implementação do serviço, além de estabelecer uma abstração suficiente para que o serviço se torne agnóstico – multipropósito – para a corporação. Coloque nos seus alfarrábios a palavra “agnóstico” e faça dela sua buzzword favorita quando se falar de SOA, pois ela representa a capacidade de adaptação e serventia a diversos propósitos. Serviços com esta habilidade deixam de ser vistos como meros serviços e ganham uma posição importante na corporação, sendo reconhecidos como recursos empresariais e tendo valores estratégicos para o negócio como um todo. O poder de adaptação e a capacidade de utilização em diversos cenários é um grande passo para se obter um bom ROI, aumentar a agilidade operacional da TI e diminuir a redundância de serviços e aplicações descartáveis para a empresa.

Outro ponto importante que este princípio expõe é a ocultação de detalhes funcionais, tecnológicos e de qualidade no contrato de serviço da solução. Se uma capacidade destina-se a consultar uma pessoa, não há o porque expor métodos de validação de dados, consultas em bancos de dado ou SLA do serviço no seu contrato. Afinal, nada disso importa para o consumidor.

Baixo acoplamento do serviço

Ouve-se muito, principalmente quem trabalha com Java, que é necessário desenvolver com baixo acoplamento e alta coesão. Não seria diferente com o desenvolvimento de soluções orientadas a serviço. O acoplamento representa o nível de dependência entre recursos ou serviços. Imagina que uma empresa possui um serviço para consulta de Pessoas, que por sua vez utiliza o modelo de dados recebido para fazer uma consulta no sistema da Receita Federal do Brasil. Se porventura o sistema da RFB ficar inoperante, o serviço da empresa se torna inútil até que o sistema da RFB volte à atividade. Exemplo muito simples, mas que representa bem o conceito de acoplamento. Com base no mesmo exemplo é possível extrair impactos significantes nos valores de entrega, autonomia e confiabilidade do serviço como um todo, além da redução significativa da capacidade de composição de um serviço e valor estratégico para o negócio.

Tratando-se de consumo do serviço, existem duas formas de acoplamento entre o consumidor e o provedor do serviço:

• Consumidor para implementação: quando o consumidor do serviço ignora os termos do contrato e acessa diretamente a funcionalidade de um serviço de forma indiscriminada e despadronizada.
• Consumidor para o contrato: este é o acoplamento ideal para consumo de serviço, pois garante-se que a lógica de solução será acessada se/somente se o contrato de serviço for respeitado.

É comum que projetistas de soluções orientadas a serviço caiam na armadilha de acoplarem o contrato de serviço à implementação da lógica, à funcionalidade ou até mesmo à uma determinada tecnologia. Estes acoplamentos são considerados ruins para o negócio e para a TI, dificultando imensamente o trabalho de governança do serviço, pois todo acoplamento feito no contrato de serviço é proliferado para seus consumidores. O acoplamento ideal para uma solução orientada a serviço é quando a lógica do negócio passa a ser acoplada ao contrato de serviço, pois desta forma o contrato passa a ter uma representação significativa e indicativa da solução proposta pelo serviço.

Autonomia do serviço

Este princípio é fortemente influenciado pelo princípio de baixo acoplamento do serviço, pois quanto mais recursos compartilhados o serviço utilizar, menor será sua autonomia para o negócio. Este princípio prega que cada serviço deve ser responsável pelo seu ambiente em tempo de execução e projeto, no entanto, em composições complexas, à medida com que o serviço aproxima-se do topo da cadeia de composição, o nível de autonomia é automaticamente comprometido. Em contrapartida é possível afirmar que quanto menor for a posição do serviço na composição, maior será sua autonomia.

Visibilidade do serviço

Do que adianta criar um serviço que represente uma lógica de solução se seus candidatos a consumidores não forem capazes de identifica-lo adequadamente? A avaliação deste princípio pode ser um tanto quanto desafiadora para o projetista do serviço, pois este declara que um serviço deve ser de fácil interpretação e descoberta ao mesmo tempo em que o mesmo deve ser genérico o bastante para servir à diversas causas.

Quando um consumidor analisa o registro de serviços num repositório corporativo de serviços, o mesmo encontra os contratos de serviço com uma série de metadados cadastrados. Estes metadados contribuem para a descoberta e a interpretação do serviço. Se o serviço possui metadados e contrato coesos e padronizados os quais permitem a descoberta do serviço em dado ambiente, é possível afirmar que o serviço tem capacidade de descoberta. Após descoberto, se o candidato a consumidor conseguir identificar o objetivo, as capacidades e o modelo funcional necessário para se cumprir com o contrato de serviço, é possível afirmar que o serviço tem capacidade de interpretação.

É fato que existe um conflito de interesses entre a abstração e a descoberta de serviços, mas é necessário o projetista fazer a política da boa vizinhança e equilibrar estes conceitos para que se tenha um resultado positivo. O serviço deve ser sim o mais abstrato possível, mas não ao ponto de perder sua identidade.

Outro relacionamento importante deste princípio é com a padronização do contrato de serviço. Padrão é vida, amigo! Para auxiliar na modelagem do contrato, a capacidade de descoberta do serviço influencia na criação de convenções para nomenclaturas de capacidades, normalização de modelos, entre outros. Estas convenções normalmente se baseiam em convenções de mercado ou até mesmo da própria atmosfera interna corporativa. Alguns exemplos de convenções para declaração de dados são:

• Um serviço de entidade ser nomeado com o mesmo nome da entidade a qual ele representa. Ex: Fatura, Pessoa.
• Nomes de capacidade serem verbos. Ex: consultar, salvar, emitirNotaFiscal.
• O nome da capacidade não pode repetir o nome do serviço.
• Não ter representações específicas que firam o princípio de abstração. Ex: consultarPessoaSQL, registrarFaturaFilaJMS.
• Entre outros.

Independência do controle de estado do serviço

Por padrão SOA, serviços não devem guardar estado, simples assim! A adesão à arquitetura orientada a serviços por si só gera uma série de desafios e mudanças organizacionais e tecnológicas. Dentre estas mudanças destaca-se o esforço em infraestrutura. Serviços reutilizáveis e composições complexas por si só já aumentam consideravelmente a carga de processamento de infraestrutura e complexidade do projeto, se adicionar uma pitada de armazenamento de estado poderia ser o divisor de águas entre o sucesso e o fracasso a longo prazo. O excesso de dados em memória influenciaria diretamente na escalabilidade e disponibilidade do serviço, ferindo o princípio de autonomia do serviço.

O objetivo desse princípio é garantir o melhor desempenho do serviço por meio do isolamento da responsabilidade de se guardar estado, ou seja, o serviço deve receber a mensagem, fazer o devido tratamento na mesma, e responder de forma esperada a cada requisição. Quem mandou a mensagem, o histórico do que foi feito e o retorno obtido não é problema do serviço!

Existem alguns tipos de estado específicos para serviços, são eles:

• Ativo: indica que o serviço está em atividade, ou seja, sendo usado ou invocado por um consumidor.
• Passivo: indica que o serviço está disponível, mas não está em uso. (standby)

Reusabilidade

Impossível falar de SOA e não associar o conceito de reuso de software. O conceito é tão importante para este tipo de arquitetura que Thomas Erl o definiu como um dos princípios para criação de serviços. O reuso de recursos está associado à necessidade de adaptação do serviço a diferentes tipos de requisições e ambientes, dando corpo ao conceito de composição de serviços. Quando um serviço é construído com o intuito de atender a um propósito único ou a um requisito de negócio central, seu ciclo de vida será drasticamente reduzido, bem como seu valor agregado. Isto se dá pelo fato da construção ser baseada num momento específico do negócio e raramente esta abordagem consegue acompanhar a evolução estratégica da companhia, tornando o software complexo, obsoleto, de difícil manutenção e principalmente com um retorno de investimento extremamente limitado, além de abrir uma grande margem para o descarte do mesmo.

Alguns serviços agnósticos são projetados com uma maturidade abstrata tão grande que os analisando de forma independente podem passar uma falsa impressão de que não há valor agregado no que foi construído, mas esta impressão é facilmente descartada quando a análise é feita com base na habilidade de posicionamento do serviço em diversas composições.

Este princípio permite ao serviço contribuir com todos os objetivos estratégicos da arquitetura orientada a serviços de forma que a construção de recursos duplicados seja mitigada, facilitando o gerenciamento dos recursos de TI e consequentemente aumentando a agilidade da TI em responder a novas necessidades do negócio, aumentando consideravelmente o ROI da corporação, uma vez que o alinhamento estratégico da TI com o negócio se perpetua por meio da adaptação dos serviços.

Composição de serviços

No meu ponto de vista este princípio é como a linha de chegada de uma jornada longa e cheia de desafios. Ele representa a superação das adversidades corporativas, o sucesso da gestão de tecnologia e alinhamento estratégico com o negócio. Transpor desafios como a mudança cultural, organizacional, operacional, tecnológica, financeira, entre outros, diferencia os homens dos meninos. A paciência e dedicação são a alma do negócio, pois a visão imediatista de retorno sobre determinado objetivo ou expectativa é colocada de lado e passa-se a valorizar uma análise e modelagem daquilo que um serviço se propõe a fazer a fim de se fazer bem feito!

Se os princípios listados anteriormente não forem atendidos, certamente a linha de chegada ficará mais distante, pois se o serviço não é padronizado, não é genérico o bastante para atender “n” composições, não consegue se manter operacional de forma independente, dependente de muitos recursos terceiros e é mal projetado ao ponto de não ser descoberto ou interpretado, certamente a composição será uma baita dor de cabeça.

Costumo fazer a analogia deste princípio como a jornada de um praticante de jiu-jitsu. Quando o aluno chega na academia com a faixa branca apaixonado pela arte suave, olha com tamanha admiração para os graduados na faixa preta, que este se torna seu objetivo. Mas é preciso dedicação, aprender com as quedas, com as derrotas, treinar exaustivamente durante anos, analisar seu oponente a fim de elaborar uma estratégia de jogo capaz de transpassar os desafios, para então chegar na faixa preta! Assim se faz com a SOA. Não tive o prazer de conhecer um projetista prodígio que desenhou serviços agnósticos com perfeição no seu primeiro ano, ou empresas que gozaram de seus benefícios em curto prazo.

É necessário tentar, errar, tentar, errar até conseguir o sucesso. Eis o termômetro ao qual falei no início deste artigo. Sempre faça uma análise do serviço em desenvolvimento com base nestes princípios ainda em fase de construção. Se um destes princípios não for atingido, pare, faça uma nova análise e siga em frente, sempre avaliando estes princípios.

AGRADEÇA AO AUTORCOMPARTILHE!