Introdução

No artigo anterior, nós apresentamos os principais conceitos de Arquitetura Orientada a Serviços (Service-Oriented Architecture – SOA), Arquitetura de Microsserviços (Microservice Architecture – MSA), a relação entre SOA e MSA, e por que faz sentido que a organização desenvolva serviços a partir dos modelos de processos de negócio. Este artigo propõe um método sistemático com essa finalidade.

Método para desenvolvimento de serviços a partir de modelos de processos de negócio

O método abordado neste artigo contempla a seguintes fases apresentadas a seguir: 

• Identificação de serviços (AZEVEDO et al., 2009a, 2009b);
• Análise de serviços (AZEVEDO et al., 2009a, 2009b, 2011, 2013); 
• Projeto (DIIRR et al., 2012);
• Implementação de serviços (DIIRR et al., 2012). 

Fase de Identificação de Serviços

A fase de identificação (AZEVEDO et al., 2009a e 2009b) visa encontrar serviços candidatos a partir de elementos do modelo de processo. Serviços candidatos representam funcionalidades descritas no processo que podem ser implementadas como serviços físicos (MARKS e BELL, 2006), como serviços web ou web services (ALONSO et al., 2014).

Em linhas gerais, a fase de identificação inclui um conjunto de heurísticas que analisam os elementos do modelo de processo, tais como, entrada e saída de dados, regras de negócio, requisitos de negócio, atividades de múltiplas instâncias, fluxos executados em paralelo (and), fluxos exclusivos (xor) etc. para identificar serviços básicos ou compostos. Portanto, esta fase tem como entrada modelos ou partes de modelos de processos, e tem como saída uma lista de serviços candidatos juntamente com diagramas e gráficos apresentando uma caracterização em alto nível dos mesmos.

Ela é dividida em três passos:

• O primeiro passo consiste na seleção dos modelos de processos e as atividades que farão parte da iniciativa para se ter processos apoiados por serviços. 

• No segundo passo, ocorre a identificação e classificação de serviços candidatos. Nesse estágio, aplicamos um conjunto de heurísticas com o objetivo de criar uma lista de serviços candidatos a partir dos processos de negócio. As heurísticas, descritas por AZEVEDO et al. (2009), baseiam-se em padrões de workflow (VAN DER AALST et al., 2013), como os padrões OR e XOR, além dos elementos presentes nos modelos de atividades, como regras de negócio e requisitos de negócio.
  
  Esses serviços candidatos são classificados em lógica ou dados. Os serviços de lógica representam regras de negócio descritas nesses elementos dos processos, que podem ser disponibilizadas como serviços. Já os serviços de dados representam especificamente serviços de acesso a dados (JOSUTTIS, 2007), como consultas, inserções, atualizações e remoções de dados.
  
  A Figura 1 ilustra serviços identificados a partir do elemento cluster de informações ligados à entrada e saída de atividades. Enquanto isso, por exemplo, o Cluster 3 ligado à Atividade 2 está associado a um conjunto de elementos que representa um serviço que lê e escreve dados desta atividade. Em outro exemplo, a partir do padrão XOR, ressaltado em vermelho, temos um serviço candidato que inclui as atividades 3, 4 e 5. 

• O terceiro passo é a consolidação de informações obtidas do processo gerando tabelas (por exemplo, com informações sobre reuso, coesão), gráficos de dependência entre serviços candidatos e gráficos (por exemplo, indicando o percentual dos serviços em relação às heurísticas que os identificaram).

Fase de Análise de Serviços

Esta fase (AZEVEDO et al., 2009a, 2009b, 2011, 2013) também tem três passos e o objetivo é aprofundar no entendimento das características do serviço, sua prioridade de disponibilização e suas dependências. 

O primeiro passo envolve a priorização dos serviços, alcançada por meio da elaboração de uma tabela que lista os candidatos e as informações coletadas na fase de identificação, tais como:

O grau de reuso dos serviços; se foram identificados a partir de atividades de múltiplas instâncias;
Quais sistemas estão envolvidos (possíveis consumidores ou fornecedores da funcionalidade do serviço);
E os papéis organizacionais envolvidos na atividade do serviço.

A cada uma dessas informações atribui-se um peso e a prioridade do serviço é calculada como a soma destes pesos. Exemplo na Tabela 1.

• No segundo passo, define-se a granularidade de serviços candidatos. Cria-se um mapa de dependência entre os serviços candidatos indicando o consumo dos serviços.

• No terceiro passo, analisamos o mapa de dependências criado a fim de agrupar serviços candidatos. Este agrupamento pode ser feito considerando aspectos técnicos ou do negócio, tais como as entidades que os serviços manipulam ou o uso dos serviços pela organização. A Figura 2 ilustra o mapa de dependências e o agrupamento dos serviços candidatos S₃₈ e S₃₇ que foram agrupados em S_I após a análise de suas dependências.

Fase de Projeto de Serviços

A fase de projeto (DIIRR et al., 2012) tem o objetivo de criar modelos de projeto que serão utilizados na implementação dos serviços. Ela utiliza as informações adquiridas nas fases anteriores para criar modelos que representam: (i) os esquemas dos dados consumidos e gerados ; (ii) operações disponibilizadas ; (iii) fluxos de execução; (iv) dependências entre os dados e os próprios serviços.

Esta fase é dividida em 4 passos: 

• O primeiro passo consiste na confirmação do tipo (dados ou lógica). 

• No segundo passo, é construído um modelo dos dados do domínio. Este modelo pode ser construído utilizando o modelo de classes UML (Unified Modeling Language) ou diagramas entidade-relacionamento. Ele corresponde aos esquemas dos dados consumidos e gerados pelos serviços candidatos. 

• No terceiro passo, as operações realizadas pelos serviços são descritas de forma resumida. 

No quarto passo, os serviços são modelados. Neste momento, um nome técnico é dado para cada serviço e são listadas as operações de cada um deles. Também são indicadas quais entidades do domínio são manipuladas pelo serviço. Diagramas da UML podem ser utilizados também neste passo. O serviço pode ser modelado como uma classe UML com o estereótipo <<interface>> ou <<service>>. Suas operações podem ser modeladas como funções públicas da classe. Os relacionamentos com as entidades manipuladas pelo serviço podem ser modelados como dependências entre as classes.

A Figura 3 apresenta um exemplo de serviço de manipulação de dados de clientes. O serviço tem o estereótipo <<interface>> e tem métodos para criar, atualizar, remover e recuperar cliente. Ele tem uma dependência com a classe do domínio Cliente. Os métodos dos serviços são públicos e os atributos de clientes são privados. Este tipo de modelo indica que dados de clientes só podem ser manipulados pelo serviço HandleClient. Desta forma, os serviços encapsulam o acesso aos dados de domínio. Este conceito está relacionado ao padrão de projeto da Camada de Dados (Data Service Layer ou DSL) que encapsula o acesso aos dados (YIN e YE, 2010). Para o caso de serviços que executam várias operações, pode-se elaborar um diagrama dos passos executados internamente pelo serviço. Diagramas de sequência ou de atividades da UML podem ser utilizados para criar este modelo.

Fase de Implementação de Serviços

A última fase é a de implementação (DIIRR et al., 2012), a qual consiste em criar os códigos referente às implementações dos serviços e às classes que representam os dados a partir do que foi projetado. 

As implementações podem ser feitas em qualquer linguagem de programação que apoie o desenvolvimento de serviços como, por exemplo, Web RESTful (RICHARDSON et al., 2013), Web SOAP (CHUMBLEY et al., 2010) e GraphQL (BUNA, 2021). 

Este artigo não tem o objetivo de detalhar linguagens de programação. Entretanto, como exemplo de implementação, caso deseje desenvolver serviços Web com protocolo SOAP em Java, as entidades de negócio podem ser implementadas como classes Java simples (ou Plain-Old Java Object (POJO)) com métodos get e set para acesso aos atributos privados da classe. Além disso, os serviços podem ser implementados como classes Java empregando JAX-WS.

No caso de serviços RESTful, por exemplo, ao utilizar a linguagem de programação Python, é possível empregar a biblioteca Flask para expor métodos a serem acessados pelos consumidores do serviço. Por outro lado, o GraphQL é uma linguagem criada e disponibilizada como código-fonte aberto pelo Facebook com o objetivo de proporcionar maior flexibilidade e eficiência do que serviços Web SOAP e REST. Todos os serviços são expostos em um único endpoint que responde a consultas escritas em GraphQL.

Exemplos de uso do método e automatizações dos passo-a-passos

Um exemplo fim-a-fim de uso do método é apresentado por Lima et al. (2014). Eles apresentam a execução das heurísticas do método aplicadas em um cenário fictício com tamanho suficiente para permitir o uso efetivo dos métodos e produzir ideias e experiências práticas úteis para Analistas e Desenvolvedores SOA.

Azevedo et al. (2009c) apresentam a automação de passos da fase de identificação considerando modelos de processos de negócio elaborados com a notação EPC (KELLER et al., 1992). O produto final da automatização da consolidação é um relatório que pode ser gerado no formato .XLS (planilha do MS Excel) ou .DOC (documento do MS Word). Entretanto, a formatação foi definida juntamente com os desenvolvedores e arquitetos SOA, visando proporcionar a maior flexibilidade possível para a manipulação do seu conteúdo.

Brandão et al. (2014) apresentam a automação da fase de identificação para processos modelados com a notação BPMN (DECKER et al., 2010), considerando inclusive as heurísticas para tratar controle de fluxo AND, XOR e OR que não haviam sido implementadas por Azevedo et al. (2009c). 

Conclusão

Este artigo apresentou um método para a construção de serviços alinhados ao negócio, tendo como ponto de partida o uso dos elementos dos modelos de processos da organização. Conclui-se que o método segue uma abordagem top-down. Em outras palavras, ele tem como entrada modelos de processos de negócio, os quais apresentam uma descrição do negócio em alto nível. A partir desses modelos, o método conduz à geração de um conjunto de artefatos que auxiliam na implementação de serviços web executando em determinada plataforma.

O método contempla as fases de identificação, análise, projeto e implementação do ciclo de vida de desenvolvimento de serviços. Ele propõe um conjunto de heurísticas para analisar elementos dos modelos de processos e gerar artefatos de implementação. A Figura 4 apresenta um exemplo resumido de aplicação do método, onde em:

(a) são ressaltados elementos do modelo utilizados para identificar o serviço candidato;

(b) apresenta informações obtidas do modelo que descrevem o serviço candidato;

(c) apresenta a priorização do serviço em relação a características de reuso, se o serviço faz parte de uma atividade de múltiplas instâncias, quantos sistemas o consomem e os papéis envolvidos no seu uso;

(d) Apresenta o projeto das operações do serviço e a entidade do negócio que ele consome. A partir dessas informações, o código é gerado, por exemplo, em Java, para a implementação do serviço.

Referências Bibliográficas:

ALONSO, G., et al. Web Services: Concepts, Architectures, Applications. Springer, 2004.

AZEVEDO, L. G., et al. A Business Aware Service Identification and Analysis Approach. In: IADIS International Conference Information Systems, pp. 196-203, 2011.

AZEVEDO, L. G., et al. A Method for Bridging the Gap between Business Process Models and Services. iSys: Revista Brasileira de Sistemas de Informação, v. 6, p. 62-98, 2013.

AZEVEDO, L. G., et al. A Method for Service Identification from Business Process Models in a SOA Approach.  In: 10^th Enterprise, Business-Process and Information Systems Modeling (BPMDS 2009). Springer, 2009a, pp. 99–112.

AZEVEDO, L. G., et al. Identificação de Serviços a partir da Modelagem de Processos de Negócio. In: V Simpósio Brasileiro de Sistemas de Informação, 2009, Brasília. 2009b.

AZEVEDO, L. G., et al. Identificação Automática de Serviços Candidatos a partir de Modelos de Processos de Negócio. In: Conferência IADIS Ibero-Americana WWW/Internet 2009, v. 1. p. 139-146, 2009c.

BRANDÃO, B. C. P., et al. Identificação Automática de Serviços a Partir de Processos de Negócio em BPMN. In: I Escola Regional de Sistemas de Informação – RJ (ERSI-RJ 2014), Niterói, RJ, Brasil, 2014.

BUNA, S. GraphQL in action. Manning Publications Co., 2021.

CHUMBLEY, et al. Web Services Basic Profile Version 2.0. Web Service Interoperability Organization (WS-I), 2010.

DECKER, G., et al. The Business Process Modeling Notation. Modern Business Process Automation, pp. 347-368, 2010.

DIIRR, T., et al. Practical Approach for Service Design and Implementation. In: IADIS Information Systems, v. 1. p. 197-204, Berlim, 2012.

JOSUTTIS, N. M. SOA in Practice: The Art of Distributed System Design. O’Reilly, Sebastopol, 2007. http://www.soa-in-practice.com ou clique aqui para acessar em português.

Referências Bibliográficas:

KELLER,  G., et al.,   Semantische Prozeßmodellierung  auf  der  Grundlage  “Ereignisgesteuerter  Prozeßketten (EPK)”.  Institute für Wirtschaftsinformatik, 1992.

LIMA, L., et al. Aplicação de Métodos baseado em Processos de Negócio para Desenvolvimento de Serviços. In: I Escola Regional de Sistemas de Informação – RJ (ERSI-RJ 2014), Niterói, RJ, Brasil, 2014.

MARKS, E.A., BELL, M.: Service-Oriented Architecture: A Planning and Implementation Guide for Business and Technology. John Wiley & Sons Inc., Chichester, 2006.

RICHARDSON, L., et al. RESTful Web APIs: Services for a Changing World. O’Reilly Media, Inc., 2013.

VAN DER AALST, W.M.P., Workflow patterns. Distributed and Parallel Databases. 14, 5–51, 2003.

YIN, R., YE, X., An Efficient Data Service Layer. Proceedings of the 2010 International Conference on Parallel and Distributed Computing, Applications and Technologies, pp. 249-254, 2010. doi: 10.1109/PDCAT.2010.44.