Como falado nos dois últimos posts, Princípios de Design de Serviço e Granularidade de Serviços, foi mencionado que: O reúso é muito importante, mas não pode ser encarado como único direcionador na hora de levantar ou classificar um serviço. Já foi falado como a granularidade afeta a modelagem e o reúso, mas o que tudo isso tem a ver com a Classificação de Serviços?
Este é o segundo post que suporta o tema Como o Reuso pode Atrapalhar uma iniciativa SOA!
Classificação de Serviços
Ao analisar o catálogo de serviço de uma empresa, é possível observar características em comum entre alguns deles. No livro SOA Principles of Service Design foram propostas três classificações (no livro elas são chamadas de Service Models, mas são mais comumente referenciadas como classificações):
- Utility Services
- Entity Services
- Task Services
A Classificação de Serviços está relacionada ao SOA Pattern Service Layers, onde é proposto a separação do catálogo em camadas, de acordo com o Service Model, termo pelo qual se refere à Classificação de Serviços. Conforme a imagem do pattern abaixo, os Utility Services possuem Granularidade de Capacidade Fina, enquanto os Task Services possuem Granularidade de Capacidade Grossa:
Utility Services
Esta classificação é uma das mais visíveis, pois normalmente existem em menor número e são muito mais técnicas que as demais. É comum encontrar esta classificação com o nome de Technical Service ou Serviço Técnico.
Exemplos mais comuns são serviços de log, notificação (envio de e-mail, SMS, mobile push), tratamento centralizado de erros, entre outros. Por sua natureza mais técnica, estas operações possuem alto potencial de reúso.
Esta classificação está relacionada com o pattern Utility Abstraction.
Entity Services
A segunda classificação mais comum é relacioandas às entidades. Tradicionalmente são definidos como data-centric, possuindo características de CRUD (Create, Read, Update e Delete), mas não deve ser limitar a operações de criação, leitura, atualização e exclusão.
Normalmente são agnosticos a processos de negócio (process-agnostic), ou seja, possuem características mais genéricas, não sendo específicos de um processo de negócio. Por exemplo, o serviço de Análise de Crédito não é específico ao Processo de Financiamento, pois pode ser usado no Cadastro de um Prospect, de um Cliente e na Revisão de Limite de Crédito.
Conforme exemplificado acima, possuem um bom potencial de reúso.
Esta classificação está relacionada com o pattern Entity Abstraction.
Task Services
Esta classificação está relacionada a Processos de Negócio reduzindo dessa forma seu potencial de reúso. Normalmente é implementado através de uma composição ou orquestração de serviços.
Um ponto de confusão é quando modelar uma operação em um Entity Service ou em um Task Service. O exemplo abaixo exemplifica essa diferença:
Considerando que a operação NotaFiscal.emitir possui seu escopo funcional restrito ao processamento de uma nota fiscal, ela pode até precisar envolver outras entidades, porém continuará sendo considerada uma Entity Service.
Ela se tornaria um Task Service se seu escopo funcional fosse específico do processo de negócio pai (non-agnostic process ou process-specific), não fazendo sentido ser reutilizado em outro processo de negócio. Por exemplo um Processo de Consolidação de Faturamento, onde vários pedidos, notas fiscais, histórico de vendas tem que ser consultados e calculados. Esta lógica não se encaixa no contexto funcional de nenhuma entidade de negócios.
Esta classificação está relacionada com o pattern Process Abstraction.
Serviço de Integração
Mas como classificar aquela integração ponto-a-ponto, onde todos os envolvidos juram de pé junto que não pode ser representada do ponto de vista de negócio, ou seja, ser modelada em um Serviço propriamente dito?
É apenas uma replicação dos dados de cliente do sistema A para o Sistema B – Equipe de desenvolvimento
Nos casos onde um web service não pode ser considerado um Serviço, surge a necessidade da classificação Serviço de Integração. Logo eles são integrações que não se enquadram nos Princípios de Design de Serviço.
Desta forma, um Serviço de Integração deve possuir baixo potencial de reúso.
Conclusão
Acho importante conhecer o tema para estabelecer um vocabulário comum, mas não me preocupo muito com isso na hora de modelar operações e agrupa-las em serviços. Considero a coesão mais importante!
Por este motivo, prefiro analisar as operações e não serviços, pois as características descritas acima são intimamente ligadas as operações. Os serviços nada mais são que uma coleção de capacidades (operações).
O que me motivou a escrever este post foi a confusão entre capacidade de reúso, dos Task Services, com Serviços de Integração. Quando isso ocorre, os Processos de Negócio acabam sendo tratado como débito técnico, o que dificularia em muito sua evolução.
Já passaram por algum caso parecido? Qual sua opinição sobre a Classificação de Serviços?
Update: quase quatro anos depois, resolvi fazer um vídeo comentando este post. Então, agora que você já leu, vai lá ver o que eu falei sobre este assunto!
