Princípios SOA
Nas postagens anteriores
Conversamos sobre Objetivos e Benefícios estratégicos de SOA aqui e aqui, e se você perdeu dá lá uma conferida.
Nessas postagens focamos em responder as seguintes questões:
- Quais os Objetivos e Benefícios estratégicos de SOA?
- Interoperabilidade ou integração?
- Serviços Agnósticos vs. ROI
- SOA vs. TI
- Dentre outras coisa
Desalinhamento do negócio e solução
O desenvolvimento de soluções de software representam o estado atual da concepção tecnológica do negócio de uma empresa. Algo como uma foto de um dado momento de entendimento de como as regras de negócio se relacionam.
Com o passar do tempo, os processos internos e algumas concepções da empresa podem mudar, o que acarreta em pequenos desalinhamentos entre a solução entregue e a concepção atual do negócio.
Frases como: “Ah, quando você chegar no site, é só não clicar mais na opção X porque não estamos mais prestando esse serviço” começam a ser mais comuns, e isso evidencia ainda mais que o software entregue já não mais condiz com o negócio.
O tempo vai passando até o momento que a empresa vê que o software que possui está tão dessincronizado com o negócio, que resolve fazer uma “nova implementação” ou abrir uma licitação para o desenvolvimento de uma nova solução em uma nova linguagem revolucionária que promete resolver todos os problemas.
A escolha de troca de uma solução acarreta em questionamentos quanto ao ROI da solução anterior.
Lembre-se:
ROI não quer dizer gastar menos, quer dizer ganhar mais em retorno com o passar do tempo.
Na verdade, um dos grandes problemas é que as soluções entregues geralmente são o que SOA chama de silos.
Silos em um conceito SOA representam soluções completamente isoladas que realizam muitas rotinas, por exemplo, mas que possuem um baixo poder de se comunicar com outras soluções. São implementações auto contidas e difíceis de serem evoluídas, são soluções não modulares, o que dificulta a substituição de partes da mesma quando da evolução do negócio corporativo.
E antes que você venha perguntar, sim, da mesma forma que você consegue colocar código não Orientado a Objetos em uma linguagem Orientada a Objetos, alguns vendedores conseguem colocar silos em SOA.
Confuso? Vamos tentar uma outra abordagem:
Um eclipse tem muito a nos ensinar sobre as soluções de software propostas de hoje.
Por um momento imagine que a parte alaranjada é a arquitetura tecnológica que propusemos para um determinado negócio de uma empresa, representada pela parte escura.
Nesse caso, a solução tecnológica inicialmente proposta não está circuncidando completamente a área negocial. Mais do que isso, você pode reparar que a solução tecnológica é maior do que a parte negocial, pode ter sido o caso de na especificação termos projetado algo além do que era o necessário para a resolução do problema, mas o ponto é o que ocorre em seguida.
Repare que após alguns alinhamentos e sincronizações, conseguimos expressar o problema negocial da empresa em um dado momento, englobando completamente a área negocial.
O problema é que o negócio continua a evoluir, e, se não evoluirmos tecnologicamente também, daquele ponto para frente, o desalinhamento com a solução proposta fica cada vez mais nítido.
O desalinhamento é tão grande, que algumas empresas preferem trocar completamente a solução em busca de um novo alinhamento, visto que a solução anterior já não corresponde mais ao seu negócio.
Como resolver esse problema em uma abordagem SOA? Dado a correta granularidade de serviços, podemos tentar minimizar os problemas de evolução negocial com a evolução de nossos serviços. Dentre os princípios que veremos a seguir a Autonomia, Abstração e Baixo Acoplamento nos ajudam a criar serviços independentes, capazes de serem compostos em serviços mais específicos, bem como serem alteradas apenas partes que reflitam as alterações negociais e não mais a solução inteira. Isso facilita a manutenção de partes da solução.
Antes de falarmos dos princípios de SOA, vejamos algumas abordagens que influenciaram SOA, e veja que muitas delas você já teve contato.
Como diria um professor meu, você verá nos princípios de SOA que não há muita genialidade no que diz respeito a novos conceitos por Thomas Erl. A grande questão foi a junção de várias coisas que você já ouviu falar em uma arquitetura, essa foi a grande sacada dele. Vamos então aos 8 princípios:
Princípios de Design de Orientação a Serviços
Padronização de Contrato de Serviço
Contratos de Serviço expressam informações de um serviço, tais como parâmetros de entrada, parâmetros de saída. modelo de dados, possibilidade de exceções, etc.
A principal funcionalidade de um Contrato de Serviço é prover previsibilidade de como interagir com o mesmo.
A Padronização de Contrato de Serviço visa o alcance de Aumento de Interoperabilidade e Aumento de Federação, trazendo assim Aumento de Agilidade Organizacional.
É interessante ressaltar que o Contrato de Serviço visa te trazer uma previsibilidade de como um serviço se comportará em uma dada circunstância, porém, não faz parte do Contrato de Serviço, e nem de SOA, expor como isso é feito. Falaremos mais sobre isso em Abstração de Serviço.
Confuso?
Imagine que eu tenha um “Contrato” verbal com você que após o pagamento de uma dada quantia de dinheiro e um celular com defeito, depois de um dado tempo eu te retorno o celular arrumado.
Nesse caso, dinheiro mais celular com defeito são a entrada, e celular sem problemas a saída do processo. Podem também ocorrer exceções nesse processo, como não ser possível arrumar o celular, e eu preciso te notificar sobre isso. Poderíamos até dizer que existe um tempo aceitável para que eu faça isso para você, e eu te informo ele, nesse caso um SLA.
Mas a beleza do Contrato de Serviço e da Abstração de Serviço está no fato que, você só precisa saber que dado aquelas entradas, há uma previsibilidade de saída. E porque isso é bom? Bem, você não precisa saber se eu executo os procedimentos na minha empresa ou se envio para uma filial em São Paulo.
Para você, o importante é que eu te entregue o que você pediu, no prazo que conversamos. Como eu faço isso, é uma preocupação minha. Com isso, eu consigo adequar o meu processo a melhores formas que aumentem o meu lucro ou eficiência, desde que eu não “quebre” o “contrato” com você.
Ainda confuso?
Em TI, eu poderia me beneficiar disso salvando os dados a princípio em um banco MySQL por exemplo, e após perceber que um outro banco seria melhor, eu poderia mudar essa implementação, e desde que eu não Quebrasse o Contrato de Serviço, não haveria impacto para quem usa o serviço.
O problema de Quebra de Contrato será melhor expressado posteriormente, mas use como exemplo a empresa anterior. Digamos que todo ano você faça uma arrume seu celular lá. Um dia, você vai lá realizar os ajustes que sempre fez, e descobre que a empresa não trabalha mais com celulares, e sim com televisões agora, porque eles mudaram de dono e não te avisaram.
O que para você era uma certeza no que diz respeito a previsibilidade passou a não ser mais válido. A funcionalidade pedia que você passasse uma dada estrutura, e de uma hora para outra, mudou…
Baixo Acoplamento de Serviço
Serviços podem ser entendidos como blocos capazes de solucionar um dado problema. Tal qual a Orientação a Objeto prega, deve-se ser buscado a Alta Coesão e o Baixo Acoplamento.
Para SOA só existem duas formas válidas de acoplamento: Acoplamento do Consumidor ao Contrato de Serviço e Acoplamento da Implementação ao Contrato de Serviço.
Os seguintes tipos de acoplamento são vistos com maus olhos para SOA:
- Acoplamento do Contrato à Lógica;
- Acoplamento do Contrato à Tecnologia;
- Acoplamento do Contrato à Implementação;
Quando o consumidor está diretamente acoplado a uma implementação, sem um contrato ou um regulador entre eles, há uma maior dificuldade na evolução da solução proposta.
Isso leva a alguns dos principais desafios de SOA:
- O quanto eu devo decompor um serviço? Qual nível de granularidade?
- O quanto devo me acoplar a uma dada tecnologia ou framework?
Abstração de Serviço
O conceito de Abstração também já é conhecido na área de desenvolvimento.
“Service contracts only contain essential information and information
about services is limited to what is published in service contracts.” ServiceOrientation.com
O consumidor do serviço não precisa saber que você usa o Oracle SOA Suite ou alguma solução da IBM. Esconda o máximo de informação possível, foque-se na solução negocial!
Não proponha uma operação como: salvarNoBancoOracle ou não utilize cabeçalhos que deixem claro a solução que você está usando: x-microsoft-client-id, x-oracle-client-secret no seu contrato de serviço. Isso dificultará sua evolução quando você não mais salvar seus dados na Oracle ou trocar para uma solução WSO2, por exemplo.
Lembre-se:
Quando ocorrer erros, não exponha para seu consumidor dados do banco ou todo o log de que o usuário xyz não tem acesso ou permissão de execução da procedure abc localizada no banco de dados X no endpoint Z.
Pode parecer coisa simples, mas existem implementações que quebram esse paradigma justamente por expor dados que não deveriam.
O que você precisa saber sobre o serviço é o que ele diz que faz, não todos os procedimentos que a implementação executa para fazê-lo.
Reusabilidade de Serviço
Reusabilidade é o princípio básico para o Aumento do ROI, bem como a projeção de Composições de Serviços.
Quanto mais reutilizado uma solução, menor o Peso da TI também.
Assim como os dois primeiros desafios de SOA levantados anteriormente, a reusabilidade gera outro:
- Quão agnóstico deve ser um serviço?
Lembre-se:
Serviços Agnósticos proporcionam maior reusabilidade, porém acarretam na busca de granularidade e decomposição de serviço, o que pode ser um desafio para sua implementação.
Podemos pensar sobre a reusabilidade de modelos nesse caso também.
Quão melhor e mais definidos forem nossas estruturas de objetos trafegadas em requisições e respostas, menores serão as necessidades de transformações, bem como definições de modelos corporativos, a fim de não termos o Usuário do sistema da equipe de marketing, o usuário do sistema da equipe financeira, o usuário do sistema da equipe de operações, dentre outros.
A ideia aqui seria buscar estruturas canônicas ou oficiais, de tal forma que não hajam várias estruturas para a mesma coisa, além de serem estruturas de referência.
Autonomia de Serviço
A autonomia de um serviço não deve impactar na autonomia de outro serviço. Para isso, seu papel e importância devem ser bem definidos de tal forma que o Contexto Funcional de uma operação não seja sobreposto por outra operação ou outro serviço.
Ausência de Estado em Serviço
“Services minimize resource consumption by deferring the management of state information when necessary.” ServiceOrientation.com
Se você é um desenvolvedor e já ouviu falar sobre Stateless sabe a que esse princípio diz respeito.
A grande vantagem de serviços stateless se dá na redução de processamento de memória e facilidade na escalabilidade.
Descoberta de Serviço
Mais importante do que se criar serviços é a capacidade de reutilizá-los.
Nisso está envolvida a Governança de serviços, um dos pontos negligenciados por várias empresas que se propõem a trabalhar segundo essa arquitetura.
Encontrar os serviços que atendem a um dado Contexto Funcional em meio a 9000 serviços é uma tarefa que não deve ser realizada somente por prefixos antes de nomes ou números.
Mais importante que encontrar um serviço que você acha que criou é saber se não existe um serviço semelhante ao que você vai começar a construir agora.
A parte de Descoberta de serviços é algo primordial quando falamos sobre Governança SOA e Inventário de Serviços SOA.
Pior que não encontrar um serviço é escrever parte da lógica de um serviço em outro, o que traz um problema conhecido como Sobreposição de Contexto Funcional.
Nesses casos, fica difícil a reutilização de um serviço, dado que o mesmo acaba possuindo regras e códigos duplicados. Um problema que não é novo no mundo do desenvolvimento, quando as pessoas confundem componentização com Ctrl+C e Ctrl+V.
Composição de Serviço
A Composição de Serviço, como dito anteriormente favorece o Aumento do ROI e Reusabilidade de Serviços.
Serviços podem ser classificados em Consumidores e Provedores, sendo que em uma abordagem SOA você não cria um serviço pensando que ela será só consumido ou será só provedor .
Dado todos os princípios abordados anteriormente, serviços são simplesmente criados, e a circunstância na qual estão contidos que vai determinar o que ele representa naquele momento. Os papeis ocorrem em tempo de execução.
Como consumidores de serviços podemos ter outros serviços, ou até mesmo implementações Frontend Web e mobile, por exemplo.
A pergunta de 1 milhão
Bom, após todo essa explanação, creio que você deva estar se perguntando quão custoso deve ser adotar SOA ou qual a métrica utilizada para descrever se uma solução usa SOA?
Lembre-se:
É importante ressaltar que não existe nenhum plugin que te dará um compliance SOA no seu código!
Qual então deve ser a resposta de Thomas Erl para essa pergunta? Você só terá SOA se aplicar todos os princípios? Se estiver com projetos com mais de 100 serviços?
“Any body of solution logic to which service-orientation has been applied to a meaningful extent is considered service-oriented”. ServiceOrientation.com
Em outras palavras, qualquer parte de solução em que a Orientação a Serviço for aplicada em uma extensão significativa, é Orientada a Serviço. Esse é inclusive um dos motivos pelos quais Thomas Erl orienta a implementação da arquitetura aos poucos em uma corporação. Não é preciso de 10 serviços para convencer alguém sobre as vantagens de SOA, às vezes, apenas um serviço já é o bastante.
Outro detalhe interessante de ressaltar é que assim como qualquer arquitetura, falar que você aplica ela é diferente de ter maturidade na aplicabilidade da mesma. Existem empresas que verificam a sua maturidade de aplicação SOA através de questionários, para saber sobre sua Governança, Inventário de Serviços, Automação, etc.
Considerações
No próximo artigo responderemos as seguintes perguntas:
- Webservices é service?
- A implementação de SOA é em SOAP?
- É possível usar REST em SOA?
- A implementação de SOA é em XML?
Nos vemos lá…
