O recente post de Jason Bloomberg - Serviços são Substantivos ou Verbos? - discute se serviços devem representar verbos ou substantivos.
É possível projetar Serviços de qualquer forma, como entidade de Serviços, que previsivelmente representa entidades de negócio, ou como Tarefa Serviços, que representam ações específicas que implementam algum passo em um processo, em outras palavras, verbos. Qual proposta é melhor?
Jason usa um exemplo de um serviço "aprovação de uma apólice de seguro pendente" para explicar a diferença entre tipos de serviço "substantivo" e "verbo".
...seguindo a abordagem OO, podemos ter um objeto de apólice de seguros com várias operações, incluindo uma que aprova a apólice, como o pseudo código ilustra:myPolicy = new Policy (); ... successOrFailure = myPolicy.approve ();
... certamente é possível criar um serviço de Apólice como uma entidade de serviço que tenha uma operação de aprovação que trabalhe mais ou menos como o exemplo acima, com uma diferença fundamental: porque serviços são fundamentalmente estéticos, você não os instancia. Aqui, então, temos um pseudo código que representa como uma entidade Serviço irá atacar a mesma funcionalidade:request para criar nova apólice, especificando a operação de criação da apólice --> Policy Service --> resposta com o número da apólice 12345
request para aprovar a apólice 12345, especificando a aprovação da operação apólice --> Policy Service --> resposta com sucesso ou falha
Embora esta seja uma abordagem típica para projetar serviços, bem alinhados com as práticas OO, Jason aponta que há:
...outro caminho para oferecer a mesma funcionalidade como uma Entidade de Serviço acima onde os serviços são representados tanto como verbos como substantivos, que nós chamamos de Task Services. Aqui vai um pseudo código para esta situação:request para criar nova apólice --> createNewPolicy Service --> resposta com o número da apólice 12345
request para aprovar a apólice 12345 -- > approvePolicy Service --> resposta com sucesso ou falha
Neste exemplo, a Task Service não tem nenhuma operação, mas a funcionalidade de cada serviço é entendida a partir do contexto do Serviço. Por fim, o que deveria fazer um serviço approvePolicy senão aprovar apólices?
Na opinião de Jason:
Ambos serviços - Entity Service e Task Service - ajudam os arquitetos a conectar os pontos entre a capacidade do legado e os requerimentos dos processos flexíveis... Entity Services... diretamente abstrata a capacidade subjacente do legado... as Task Services, [representam] abstrações de operações individuais pertencentes às Entity Services. Os... Process Services... são tipicamente composições das Task Services. Em outras palavras, os Process Services são interfaces para SOBAs, e quando estes SOBAs são composições de Task Services bem projetodos, eles irão exibir processos de isomorfismo.
Jason completa seu post afirmando:
Como é usual neste caso, arquitetos têm diversas opções à sua disposição, e saber qual opção é a adequada depende, muitas vezes, do problema do negócio, um exemplo do princípio "ferramenta certa para o trabalho. Se o problema do negócio é centrado no processo, diz, a necessidade de racionalizar e otimizar o processo de emissão da apólice, então, implementando SOBAs como uma composição das Task Services irá facilitar a flexibilização do processo. Em outros casos, o problema do negócio é mais centrado na informação que no processo, por exemplo, colocando a informação consolidada do cliente na tela de um representande de um call center. Em tais casos, o foco do arquiteto pode estar em um serviço de entidade, porque o atendente está negociando com um cliente em particular e deve estar habilitado para interagir com este cliente de uma maneira flexível.
Embora Jason tenta apresentar (várias vezes) as diferenças entre SOA e OO neste post, é um testamento de quanto nossas experiencias OO impactam em nosso entendimento SOA. Vamos começar pelas definições. De acordo com o Wikipedia:
- Substantivo: uma parte do discurso flexionadas para o caso, significando uma entidade concreta ou abstrata.
- Verbo: uma parte do discurso sem inflexão caso, mas flexionado por pessoa tensa, e número, significando uma atividade ou processo, realizado ou sofrido.
Seguindo a explicação de Jason que "Serviçoos são fundamentalmente estéticos", eles não podem representar uma entidade. Neste exemplo, um serviço de Apólice não é um serviço de entidade, porém, uma coleção de métodos suportando uma operação (verbos) em qualquer apólice. Isto é similar a uma sessão bean (J2EE) estética, que dificilmente pode ser chamado por um substantivo. Então, no final das contas, Servico nunca é um substantivo, um verbo ou uma coleção de verbos e a diferença entre o que Jason chama de serviços de Tarefa e Entidade é a quantidade de métodos que estão expondo.