Arquitetura de Serviços (SOA ou MSA) a partir de Modelos de Processos de Negócio

Arquitetura Orientada a Serviços (SOA – Service-Oriented Architecture)

A Arquitetura Orientada a Serviços (SOA – Service-Oriented Architecture) é um paradigma que visa facilitar a realização e manutenção de processos de negócio em ambientes distribuídos, controlados por diferentes proprietários (Josuttis, 2007). Neste contexto, as funcionalidades de negócio são disponibilizadas como serviços compartilhados e reutilizáveis em uma rede de TI (Marks e Bell, 2006).

Serviços, definidos como pedaços de software com interfaces expostas e invocados por mensagens (Marks e Bell, 2006), devem estar diretamente relacionados ao negócio e podem compor um ou mais processos organizacionais. Eles variam desde funcionalidades simples, como armazenamento e recuperação de dados de funcionários, até processos complexos, como o tratamento de pedidos de clientes.

Os princípios de serviços em uma Arquitetura Orientada a Serviços são (Erl, 2005):

Serviços devem estar alinhados ao negócio
Serviços não devem armazenar estado (stateless)
Serviços devem possibilitar composição
Serviços devem ser operacionalmente independentes (autocontidos)
Serviços devem manter consistência de informações
Serviços devem ter contratos bem definidos, com pré e pós-condições claras
Serviços devem prover capacidades para serem localizados
Serviços devem possibilitar reuso
Serviços devem ser interoperáveis

A implementação primária de serviços ocorre por meio de Web services (Erl, 2005), utilizando tecnologias como:

WS-* ou “Big” Web services ou Web services SOAP que empregam os padrões WS-* fortemente baseados em XML e utilizam o protocolo SOAP (Alonso et al., 2004)(Chumbley et al., 2010);
Web services RESTful que seguem as restrições REST (Fielding e Taylor, 2002) (Richardson et al., 2013) e utilizam o protocolo HTTP;
GraphQL criado pelo Facebook em 2012 e que tornou-se de código fonte aberto em 2015 (Buna, 2021). As tecnologias mais utilizadas atualmente são RESTful e GraphQL para construção de serviços em uma Arquitetura Orientada a Serviços (SOA) ou microsserviços em uma Arquitetura de Microsserviços.

Arquitetura de Microsserviços

A Arquitetura de Microsserviços representa uma abordagem para desenvolver uma única aplicação composta por pequenos serviços independentes, cada um executando em seu próprio processo (geralmente, em um contêiner) e se comunicando através de um mecanismo leve, como o HTTP (Newman, 2015; Fowler e Lewis, 2014).

Existem sete princípios de microsserviços (Zimmermann, 2017; Villaça et al., 2018) baseados nos trabalhos de Newman (2015) e Fowler e Lewis (2014):

Interfaces com granularidade fina: serviços são unidades com responsabilidades específicas e independentes encapsulando tanto lógica de processamento quanto dados;
Uso de práticas de desenvolvimento orientado ao negócio como DDD (Domain-Driven Development) (Evans, 2004);
Utilização dos princípios de computação em nuvem: distribuição, elasticidade e baixo acoplamento;
Implantação contínua descentralizada: automação e autonomia de implantação, o que requer maturidade para construir e testar os serviços;
Uso de conteinerização: utilização de metodologias de empacotamento de código em contêineres através de processos de implantação contínua (por exemplo, Docker (Merkel, 2014));
DevOps (Development and Operation) (Hütterman, 2012): utilizar abordagens ágeis e automatizadas para gestão de configuração, desempenho e monitoramento;
Múltiplos paradigmas: coexistência de diferentes tecnologias escolhidas de acordo com a necessidade de cada microsserviço da arquitetura como, por exemplo, linguagens de programação e mecanismos de armazenamento de dados mais adequados aos requisitos dos serviços.

Microsserviços x SOA

A Arquitetura de Microsserviços surgiu empiricamente a partir de padrões arquiteturais utilizados no mundo real. A literatura diverge em relação a Arquitetura de Microsserviços ser um novo estilo arquitetural (Richards, 2016) ou uma abordagem de SOA (Zimmermann, 2017). Segundo Zimmermann, Microsserviços é uma forma de implementação e implantação de serviços em SOA empregando práticas do estado da arte de engenharia de software.

As diferenças não estão relacionadas ao estilo arquitetural, mas sim na realização da arquitetura. Logo, não há diferenças quanto a restrições e intenções de projeto, princípios de independência de plataforma e padrões. As diferenças existem então nos paradigmas e tecnologias de desenvolvimento e implantação.

Por que construir serviços a partir de modelos de processos de negócio?

Modelos de processos de negócio representam várias informações necessárias para o desenvolvimento de serviços, tais como:

Como (How): as atividades dos modelos de processos representam como os processos da empresa devem ser executados;
Por que (Why): os modelos descrevem o porquê de o processo ser necessário, apresentando seus objetivos, fatores externos e regras de negócio que o permeiam;
O que (What): os modelos apresentam o que é manipulado, por exemplo, de onde os dados são lidos e armazenados indicando produtos, dados externos e sistemas;
Quando (When): nos modelos temos quando as coisas acontecem, ou seja, os eventos que são disparados durante a execução do processo;
Onde (Where): no modelo temos a localização de onde o processo é executado;
Quem (Who): o processo modela quem executa, participa ou deve ser informado durante a execução de suas atividades

Isto permite ter duas visões distintas:

(i) do negócio para serviços;

(ii) dos serviços para o negócio.

Em outras palavras, tendo estas ligações, a partir dos elementos dos modelos de processos, consegue-se saber quais são os elementos dos serviços associados.

Portanto, com estas ligações obtêm-se rastreabilidade, ou seja, consegue-se saber os serviços afetados quando ocorrem mudanças nos processos e os processos que podem ser impactados por manutenções realizadas nos serviços que os apoiam. Esta visão a partir dos processos e a partir dos serviços é apresentada na Figura 1:

Figura 1 – Rastreabilidade entre elementos dos modelos de processos e artefatos dos serviços. — Figura 1 – Rastreabilidade entre elementos dos modelos de processos e artefatos dos serviços.

Conclusão

Este artigo apresentou os conceitos de Arquitetura Orientada a Serviços (Service-Oriented Architecture – SOA) e Arquitetura de Microsserviços (Microservice Architecture – MSA), a relação entre estes conceitos, e o porquê faz sentido criar uma Arquitetura de Serviços a partir de modelos de processo de negócio.

Esta abordagem para construção da arquitetura é top-down, ou seja, ela tem como entrada modelos de processos de negócio, os quais apresentam uma descrição dos processos do negócio em alto nível, e segue até a geração de um conjunto de artefatos que auxiliam na implementação de serviços físicos, isto é, serviços web executando em determinada plataforma. Um exemplo ilustrativo é apresentado na Figura 1.

Através do uso desta abordagem, vários benefícios são alcançados, tais como:

Alinhamento entre o negócio e a TI (Tecnologia de Informação)
Rastreabilidade entre processos e os artefatos dos serviços (contratos, esquemas de dados, código dos serviços, políticas de uso e segurança etc)
Agilidade em encontrar pontos de mudança e manutenção
Flexibilidade e foco na identificação de onde atuar para mais rapidamente evoluir nos serviços da organização

No entanto, para efetividade desta abordagem, é necessário um método sistemático que defina como executar a análise dos processos de negócio até se chegar ao serviço físico (Azevedo et al., 2009a, 2009b), detalhado no próximo post! Continue sua leitura para mais insights.

Referências Bibliográficas

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

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.

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

CHUMBLEY, R., DURANT, J., PILZ, G., RUTT, T. Web Services Basic Profile Version 2.0. Web Service Interoperability Organization (WS-I), 2010.

EVANS, E. Domain-driven design: tackling complexity in the heart of software. Addison-Wesley Professional, 2004.

FIELDING, R. T., TAYLOR, R. N. Principled design of the modern web architecture. ACM Transactions on Internet Technology (TOIT), 2(2):115–150, 2002.

ERL, T. “Service-Oriented Architecture: Concepts, Technology, and Design”. Prentice Hall Englewood Cliffs, 2005.

FOWLER, M., LEWIS, J. Microservices. ThoughtWorks, 2014.

HÜTTERMANN, M. DevOps for Developers. Apress, 2012.

JOSUTTIS, N. M. SOA in Practice: The Art of Distributed System Design. O’Reilly, Sebastopol, 2007.

Referências Bibliográficas

KELLER, G., SCHEER, A.-W., NÜTTGENS, M. Semantische Prozeßmodellierung auf der Grundlage. Ereignisgesteuerter Prozeßketten (EPK). Institute für Wirtschaftsinformatik, 1992.

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

MERKEL, D. Docker: Lightweight Linux Containers for Consistent Development and Deployment. Linux Journal, vol. 239, n. 2, 2014.

NEWMAN, S. Building microservices. O’Reilly Media, Inc., 2015.

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

RICHARDS, M. Microservices vs. service-oriented architecture, O’Reilly Media, Inc., 2016. Disponível aqui.

VILLAÇA, L. H. N., AZEVEDO, L. G., BAIÃO, F. A., Query Strategies on Polyglot Persistence in Microservices. In: Proceedings of the 33^rd ACM Symposium on Applied Computing, pp. 1725-1732, 2018.

ZIMMERMANN, O. Microservices tenets. Computer Science-Research and Development, 32(3-4):301–310, 2017.