Há alguns anos o Prof. Thomas Erl, considerado maior ‘papa’ sobre Arquitetura Orientada a Serviços, publicou o livro SOA Principles of Service Design
Aqui vamos dar uma visão rápida sobre cada um deles, e como eles se relacionam com os assuntos dos outros posts 😉
Standardized Service Contract – Contato de Serviço Padronizado
Consiste em, como o nome diz, padronizar os contratos de serviço (WSDL’s e XSD’s em sua maioria). Quando bem implementado, ele proporciona os seguintes benefícios:
- Aumenta a interoperabilidade;
- Diminui o número de transformações;
- Tornar o portfólio de serviços mais consistente, fácil e intuitivo;
Em breve novidades sobre este assunto 😉
Service Loose Coupling – Serviço com Baixo Acoplamento
Três dos oito princípios são mais abstratos e apoiam os demais. Assim como o anterior, ele é alcançado através dos Contratos de Serviço e do Modelo Canônico.
Ele trás os mesmos benefícios do anterior, mas possui uma preocupação mais ampla: a de não acoplar os consumidores do serviço a seus detalhes de implementação nem de seus provedores (como plataforma tecnológica, aplicação, modelo de dados, etc).
- Desta forma, este princípio permite que as aplicações provedoras de serviço e os consumidores evoluam com o mínimo impacto entre eles.
Service Abstraction – Abstração de Serviço
Assim como o anterior, este princípio também é mais abstrato e influencia outros princípios. Ele tem como objetivo ocultar informações desnecessárias aos seus consumidores, como informações sobre plataforma tecnológica, lógica, etc.
Este princípio está intimamente ligado aos dois anteriores e a boas práticas de modelagem de serviço.
Por acaso, me deparei recentemente com uma situação onde um provedor não estava utilizando este princípio, ao exigir que o consumidor lhe enviasse uma informação que deveria ser gerada por ele. Neste caso, o ideal é analisar os parâmetros de entrada e saída e avaliar se faz sentido para um consumidor leigo.
Service Reusability – Capacidade de Reúso de Serviço
Seus objetivos são similares aos objetivos da Arquitetura Orientada a Serviços, sendo um dos principais princípios: possibilitar retorno sobre investimento (ROI) e melhorar a agilidade de TI.
Para isso, além de bem modelado (princípios anteriores) e dos princípios de Visibilidade e Composição, é preciso que os serviços possuam uma granularidade média. Nem muito baixa, que acarretariam em composição nos consumidores com duplicação de código e baixo valor do reúso, nem muito alta, que tornariam os serviços muito específicos a um determinado processo de negócio.
Um ponto de atenção:
O reúso é muito importante, mas não pode ser encarado como único direcionador na hora de levantar ou classificar um serviço. Mesmo conhecendo bem o portifólio de projetos, o reúso pode não ser identificado no momento da identificação de um serviço, porém é comum aparece após semanas de sua identificação.
Service Autonomy – Autonomia de Serviço
Arrisco a dizer que este é o princípio que está mais em destaque hoje em dia! Será que você descobre até o final deste post?
Seus objetivos são:
- Aumento da confiabilidade, previsibilidade e desempenho, especialmente em composições;
- Aumento do controle sob seu ambiente de execução;
Os objetivos acima se referem a autonomia em tempo de execução, que podem ser alcançados através de ambientes dedicados a execução do serviço. Recentemente isso pode ser alcançado de forma muito mais fácil através de containers do Docker.
Além da autonomia em tempo de execução, é importante que o serviço possua autonomia em tempo de design, que se refere à independência que os serviços tem de modo que, possam ser evoluídos sem impactar nos seus consumidores. Esse tipo de autonomia é importante para manter baixo acomplamento (segundo princípio), assim refatorações ou mudanças internas não impliquem em modificações no Contrato de Serviço (primeiro princípio).
Service Statelessness – Independência de Estado de Serviço
Os serviços não devem manter estado em memória (Stateless), desta forma são mais escaláveis e agnósticos de processos de negócio, o que aumenta o reúso.
Com isso, o consumidor deve ser capaz de controlar a paginação de uma lista, pois o serviço não saberá qual a próxima página de determinado consumidor, por exemplo.
Um ponto que pode gerar confusão, é a implementação de processos de negócio, normalmente long running, implementados através das notações BPMN e BPEL. Mas isto é assunto para um post dedicado.
Discoverability – Visibilidade do Serviço
Este princípio é vital para o reúso de serviços, pois não se pode reusar o que não se conhece. Ele é apoiado pelo primeiro princípio e por um repositório de serviços (leia este post para mais detalhes).
O Contrato de Serviço é responsável pelos meta-dados referentes ao serviço, e o repositório por armazenar e possibilitar buscas por palavras chave.
Desta forma é possível descobrir, rapidamente e com baixa taxa de erro, se é necessário desenvolver um serviço candidato ou reutilizar um serviço existente.
Service Composability – Composição de Serviços
Este princípio possui basicamente os mesmos objetivos do reúso, pois uma composição não deixa de ser um reúso de um ou mais serviços. Ele consiste na capacidade de criar um novo serviço a partir do uso de outros dois.
Como os princípios de baixo acomplamento e abstração, este é abstrato, influenciando e complementando outros princípios.
Conforme mencionado no oitavo slide da minha palestra sobre Modelo Canônico, seu uso apoia os três primeiros princípios.
E então, descobriu porquê o princípio Service Autonomy – Autonomia de Serviço está na moda? Se sim, deixe um comentário abaixo, mas sem falar o motivo, para não dar spoiler! Senão fique ligado através do Twitter ou assinando o RSS que a resposta vem no próximo post =P
