Fundamentos, Objetivos e Benefícios estratégicos de SOA (parte 2)
Nas postagens anteriores
Começamos a falar sobre SOA aqui.
Discutimos sobre o quanto uma abordagem SOA começou a se perder quando se começou a ser resumida em ter ou não um ESB.
Falaremos agora sobre os Objetivos e Benefícios estratégicos de SOA.
Overview
A palavra estratégico traz consigo para o universo SOA o conceito de a longo prazo. Sendo assim, algumas coisas devem ser aplicadas visando-se um bem maior no futuro.
É como o conceito de qualidade de código e testes. Fora todo o hype da palavra, buscamos isso visando refatorações futuras e facilidade de evolução.
SOA estipula sete Objetivos Estratégicos:
Três deles também são Benefícios Estratégicos alcançados pela aplicação dos quatro Objetivos Estratégicos anteriores.
Aumento de Federação
Busca pela padronização nas características dos serviços utilizados numa solução de Arquitetura Orientada a Serviços.
Confuso? Lembre-se que o Brasil é composto por 27 Unidades Federativas. Elas são completamente diferentes umas das outras e guardam características únicas, mas sob uma dada ótica, guardam características semelhantes que favorecem a sua governança. Forçando um pouco mais a analogia, dá inclusive para agrupá-las e fazer composições.
O difícil não é fazer um webservice SOAP ou REST. O difícil é governar isso depois.
Pode até parecer simplório, mas desse ponto, derivarão outros conceitos adiante como: padronização de contrato de serviços, Contract-First, composições de serviços e modelo canônico.
Outra pergunta pode ter surgido a sua mente agora: Webservices é o mesmo que serviços? Deixaremos a pergunta no ar por enquanto.
Lembre-se
Serviços são a unidade de maior importância em SOA.
Aumento de Interoperabilidade Intrínseca
A interoperabilidade representa a capacidade de um serviço realizar uma interação ou comunicação através da troca de dados em mensagens.
Thomas Erl tem um ligeiro problema com a palavra integração, por mais que para mim e para você possa parecer que interoperabilidade e integração são a mesma coisa.
Na verdade, o que ele está fazendo é definindo um vocabulário necessário para que todos que conversem sobre SOA falem a mesma coisa, e não haja confusões para que a seguinte frase não seja tão repetida: “Ah, mas o que é SOA para você não é SOA para mim”.
Resumindo: interoperabilidade é a capacidade de conseguir se comunicar com outros serviços sem que seja necessário serem feitas transformações de tipos de dados. Mais uma vez, o alcance desse objetivo se dará por palavras que veremos à frente como: padronização de contrato de serviços, Contract-First, composições de serviços e modelo canônico.
Confuso? Se você é desenvolvedor, e trabalha com SOAP ou REST já deve ter enfrentado um problema interessante com relação ao formato de datas.
Em uma API, elas são retornadas no formato dd-mm-yyyy, em outras, no formato dd/mm/yyyy, já em outras, no formato yyyy-mm-dd. Já percebeu a perca de tempo que você tem para manipular essas datas?
Imagine, o mundo maravilhoso que seria, se todos usassem a padronização de datas de um XSD em um padrão SOAP: yyyy-mm-dd
Nesse mundo, a padronização te ajudaria a realizar composições entre serviços e a (adivinhe?) fazer cálculos de datas, e outras coisas nativas em objetos data.
Outro problema bem interessante é você requisitar o saldo de uma dada coisa em uma API, e ser retornado para você: R$ 10,00.
Qual a regra de negócio chega para você em seguida? “Ah, dependendo do valor você tem que fazer um cálculo”.
Lá vai você transformar um texto R$ 10,00 em um número para realizar um cálculo.
Outros exemplos seriam APIs que retornam HTML em parte de sua mensagem de resposta, e (adivinhe?) só funcionam com consumidores que entendem HTML.
O ponto não é se o Frontend deseja utilizar uma máscara no CPF ou na data de nascimento de um usuário, tão pouco se fica melhor formatar um valor monetário para melhor exibi-lo na sua camada de visão. Uma coisa é como o dado deve ser apresentada para um usuário final na camada de visão, outra coisa é como devemos trafegá-lo para evitar transformações
Chegaremos nesses problemas nas postagens seguintes, o importante é saber que se você tem que fazer transformação de dados e integração, você não está alcançando a interoperabilidade.
Porém, uma grande questão é que nem sempre as soluções propostas serão soluções novas, ou seja, a integração acaba sendo necessária em um dado momento para obtenção de SOA, por mais que isso não soe bem para o sr. Erl, mas isso é uma outra questão…
Aumento da Diversidade de Vendedores
A opção de escolha de um dado vendedor deve ser uma escolha estritamente da corporação que utilizará a Arquitetura Orientada a Serviços. Sendo assim, mesmo que a empresa opte por uma solução, isso não deve inviabilizar a adoção de outras tecnologias de outros vendedores no futuro.
A vantagem dessa abordagem se dá em evitar se acoplar a soluções proprietárias, favorecendo a interoperabilidade.
Aumento de Alinhamento entre o Negócio e a TI
Esse objetivo só pode ser alcançado quando há colaboração entre a área de negócio e a área de TI em fases de análise e modelagem do problema.
Com isso, frases como: “O requisito foi mal levantado pelo negócio” ou “A TI não soube expressar a regra de negócio direito” diminuem, pois esses pontos já são levantados de antemão, favorecendo também a evolução do negócio como um todo.
Aumento do ROI
ROI é o acrônimo para Return of Investment (Retorno de Investimento), e representam o valor tangível e a economia proporcionada de uma determinada quantidade de recurso investida comparada ao custo de produção e governança da mesma.
Em SOA, quanto mais reutilizado um serviço, maior o ROI se mostra para uma companhia, por consequência, maior o será o agnosticismo desse serviço para a solução.
Lembre-se:
Serviços Agnósticos são serviços que proporcionam maior ROI, sendo o grande desafio de granularidade em uma solução SOA.
Redução do Peso da TI
A aplicação de SOA conduz a:
- Redução de desperdício e redundância
- Redução do tamanho e custo operacional
- Redução de sobrecarga associada a governança e evolução de uma solução
O ponto é que a busca pelo ROI, junto a Diversidade de Vendedores e demais Objetivos Estratégicos tornam a TI de uma empresa mais eficiente. Todo um conjunto de soluções não será descartado quando surgir uma nova linguagem de programação, por exemplo.
Aumento de Agilidade Organizacional
A Agilidade Organizacional é obtida através da reusabilidade e composição de serviços já expostos, claro que com isso há uma quebra de paradigmas.
Ainda confuso? Vou tentar explicar de outra forma, quando no auge de 2012, no instituto de pesquisa que trabalhei criamos esse vídeo com a ajuda do meu irmão Alexandre Fonseca. Me desculpem pelos erros de inglês e uns de português no início e fim do vídeo =(
Considerações
Bom… vamos terminar essa abordagem por aqui. Nas postagens seguintes, continuaremos falando sobre SOA, mais precisamente sobre os oito Princípios de Design da Orientação a Serviços e as tecnologias e abordagens por trás da Arquitetura Orientada a Serviços.
Gostou das tirinhas? Não deixe de acompanhar em Geek & Poke.
