Uma breve introdução aos serviços
Neste artigo, irei apresentar a você uma visão geral e simplificada de como o desenvolvimento orientado a serviços é algo incrível que nos permite alcançar altos níveis de padronização e reuso em nossas aplicações, além de outras vantagens que serão apresentadas no decorrer do texto. Aqui o foco será apenas nos benefícios dessa prática. Vamos começar!

O que é um serviço?
Os serviços são um dos dos componentes da camada de negócio que nos permite abrir nossa aplicação ao mundo externo por meio da exposição de nossas regras de negócio. Segundo alguns autores, podemos definir um serviço simplesmente como uma unidade de funcionalidade exposta por meio de um padrão.
A união dessas unidades em uma aplicação única e coesa caracteriza o termo Aplicação Orientada a Serviços — SOA conforme apresenta a Figura 1.
De uma forma geral, a aplicação apresentada acima é formada por um conjunto de serviços interconectados que colaboram entre si .
Serviços também podem ser imaginados como blocos de software que realizam uma função específica (obter informações de uma venda em um banco de dados por exemplo). Essas funções são executadas por meio de sua invocação através de interfaces, que estabelecem os chamados “contratos”, assunto que será estudado mais a frente no texto. Outro conceito importante e inerente aos serviços é a presença dos termos provedor e consumidor quem fornece e consome o serviço respectivamente; consumidores podem ser uma aplicação ou mesmo outro serviço.
Antes de continuarmos, devemos ter em mente que a abordagem SOA não é uma metodologia, tão pouco uma tecnologia, mas sim um conceito de arquitetura que promove a integração — a integração é um meio para conseguir SOA.
No contexto corporativo, a arquitetura SOA pode ser encarada como um modelo de planejamento e estratégia da área de TI se alinhando diretamente aos objetivos de negócios da organização. Empresas precisam responder de forma rápida e efetiva as tendências do mercado, dessa forma, as aplicações devem possuir flexibilidade suficiente para acompanhar isso. Nesse sentido, uma arquitetura orientada a serviços vem a promover o reuso e a interoperabilidade entre os ativos de software.
A camada de serviços
Os serviços estabelecem uma fronteira entre as camadas de apresentação e a camada negócio. A comunicação entre essas camadas é realizada através de DTOs (Data Transfer Objects). Contudo, em alguns casos podemos não ter a presença de uma camada de apresentação baseada na ideia de uma interface gráfica. Nesse cenário, a fronteira do sistema será a própria camada de serviços que poderá integrar com outros sistemas fazendo o papel de provedor.
Quando a camada de apresentação existe, os serviços definem uma interface entre ela e a camada de negócios que é a responsável pela execução de ações predefinidas baseadas nas informações obtidas na apresentação. A Figura 3 apresenta a localização da camada de serviços na arquitetura .NET:
Características de uma arquitetura de serviços
Aqui irei elencar algumas das principais características que podem ser encontradas em uma arquitetura SOA, são elas:
Encapsulamento: Serviços omitem as regras de negócio e separam responsabilidades. Dessa forma, conseguimos proteger e ao mesmo tempo delimitar de maneira bem definida o conteúdo de nossos componentes de sistema isolando as regras de negócio da interface de usuário por exemplo. Além disso, um serviço não deve ter conhecimento a respeito das características de implementação de outros serviços.

Padronização e Reuso: Serviços são concebidos para serem reutilizáveis por meio da disponibilização de interfaces de consumo. As interfaces são como a “porta de entrada e saída” de nossa aplicação através da qual disponibilizamos o consumo das regras de negócio ou realizamos o consumo de outras regras de negócio provenientes de outras aplicações.
A Figura 5 apresenta uma aplicação na qual serviços podem ser consumidos por usuários através de uma camada de apresentação ou por sistemas externos. Além disso, essa mesma aplicação pode também estar consumindo serviços de outros sistemas em sua camada de dados. Dessa forma, podemos ter uma aplicação que pode tanto prover como consumir serviços de outras aplicações.
Além do reuso, essa ideia nos permite obter o desacoplamento por meio da separação de responsabilidades.
Como exemplo de padronização, vamos citar o serviço de cálculo de distância entre dois pontos na superfície da Terra fornecido pelo Google Maps. Para fazer isso, devemos fornecer a localização do ponto de origem e do ponto de destino (coordenadas) à plataforma do Google que por sua vez irá realizar todo o processamento e nos devolver a distância estimada entre os dois pontos.
O mais interessante nesse contexto é que tudo é feito de forma que o solicitante não precisa acessar o banco de dados do Google ou ter conhecimento algum sobre o código de cálculo utilizado na operação. A ideia é simples: está tudo pronto, apenas use! :D
Agora vamos mergulhar em um cenário em que as coisas se tornam um pouco mais caóticas... Imagine se nossa aplicação precisasse acessar o banco de dados do Google diretamente para obter as coordenadas de cada ponto e implementar o seu próprio código de cálculo? O que poderia ocorrer!? A resposta é simples: o caos estaria estabelecido! Para ilustrar os efeitos catastróficos disso, digamos que uma aplicação A opte pela utilização da fórmula de Haversine enquanto uma aplicação B aplica simplesmente o teorema de Pitágoras para efetuar o cálculo da distância entre os pontos fornecidos. Como se sabe, o teorema de Pitágoras tende a apresentar erros gritantes a medida que a distância entre os pontos aumenta já que não leva em consideração a curvatura da terra.

Como conclusão, temos que essa situação poderia ser evitada somente com a adoção de algo padronizado e confiável como o Maps do Google, Here Maps (Nokia), Waze, entre outros. É claro que, alguns softwares podem necessitar realizar seus próprios cálculos de distância devido alguma peculiaridade inerente ao seu propósito ou funcionamento.
Independência de plataforma: Serviços tem o seu design baseado no suporte à múltiplas plataformas e protocolos. Assim podemos ter serviços desenvolvidos em plataformas mobile ou IoT suportando protocolos como SOAP ou REST.
Interoperabilidade: Serviços expõem as informações de forma consistente por meio de contratos. Isso melhora os fatores relacionados a interoperabilidade e a operação já que temos um protocolo padronizado para acessar os seus recursos, ou seja, um acesso baseado em contratos bem definidos. Para isso ficar claro, vamos tomar a ideia apresentada na Figura 8 e nos ater ao processo de comunicação entre os dois serviços da figura para abordar a questão da interoperabilidade.
Quando definimos um serviço uma das primeiras coisas (se não a primeira) que definimos é o tipo de contrato por meio do qual iremos expor nossas informações. Esse contrato é o protocolo utilizado durante a troca de mensagens. Na Figura acima, para que a comunicação ocorresse, seria necessário especificarmos um tipo de contrato de comunicação entre o provedor e o consumidor, por exemplo, HTTP ou MQTT. O padrão de contratos é um item que influencia diretamente na reusabilidade de um serviço já que define a forma com que os mesmos devem “conversar” entre si.
Flexibilidade: Uma abordagem SOA fornece-nos a possibilidade de escrever os componentes em nossa arquitetura usando qualquer linguagem ou plataforma que acharmos mais conveniente. Poderíamos por exemplo, escrever componentes que lidam com interface de usuário em JavaScript ou Ruby enquanto que componentes em que a performance é algo crítico, poderiam ser escritos em C ou Java.

Características mandatórias de um serviço
As três características mandatórias para um serviço são:
Concorrência: Não faz sentido desenvolver um serviço que não suporte concorrência em relação a sua invocação pelos consumidores. Um serviço deve estar apto a lidar com múltiplas conexões e re-chamadas.
Robustez: serviços devem ser capazes de isolar erros a fim de evitar que isso provoque a sua indisponibilidade. Erros não podem se alastrar ou causar impactos maiores no serviço. E por fim, serviços não devem necessitar que nenhuma configuração do cliente seja necessária para que seu comportamento seja alterado.
Segurança: Um serviço e seu cliente precisam utilizar comunicação segura e deve haver alguma forma dos clientes autenticar o serviço. Clientes podem prover credenciais nas mensagens para que o serviço autorize a requisição. Um exemplo para isso seria a utilização de web tokens como parte de processo de autenticação.
Características opcionais de um serviço
Interoperabilidade: O serviço deve ser projetado para que muitos clientes, independentemente da tecnologia, possam realizar requisições — um cenário de múltiplos contratos (Figura 8).
Disponibilidade: O serviço deve sempre permitir que clientes o consumam por meio de requisições. Caso o serviço possua períodos de indisponibilidade, os clientes devem tratar tal situação, o que consequentemente irá aumentar o grau de acoplamento.
Desempenho: O cliente não deve ter que esperar um tempo muito longo para que o serviço inicie o processamento da requisição. Caso o tempo de resposta seja elevado, o cliente deverá ser notificado de que a sua requisição está sendo processada.
Entre todas essas características opcionais e obrigatórias que foram citadas, ressalto a importância da ideia do fraco acoplamento que deve haver entre os serviços que na prática significa minimizar o impacto das modificações e das falhas no ambiente do sistema como um todo.
Categorias de Serviço
O padrão SOA define alguns tipos básicos de serviços para realização de atividades específicas. A Figura 11 apresenta um exemplo mais próximo da realidade no qual temos várias aplicações compostas por vários serviços que comunicam entre si.
Obs.: Espero que a partir desse ponto fique claro para você a intenção da foto de capa deste artigo :)

Entity Service — Os serviços de entidade incluem entidades de consumidores como uma ordem de compra, nota fiscal de uma compra, histórico de vendas, etc. Esses componentes permitem a realização de operações CRUD (criar, ler, atualizar ou remover entidades) e lidam diretamente com as regras de negócio.
Task Service — Os serviços de tarefa adicionam lógica de negócio a outros serviços e devido seu foco ser em entidades de negócio, eles contém pouca lógica focada em reusabilidade. Eles fornecem operações a mais de uma entidade, como a ordem de compra do cliente, a criação do número do pedido de compra, a validação dos detalhes de um cliente, etc. Dessa forma, sua principal característica é precisar acessar várias entidades de negócio.
Utility Service — Os serviços utilitários são usados para construir serviços de maior nível e prover outras capacidades que não são relacionadas a transferência de mensagens. Os serviços utilitários proveem funções reutilizáveis como por exemplo, registro de eventos, notificação e criação de um número único para outros domínios funcionais. Esses serviços são compostos por outros pequenos serviços que são usados como blocos de construção no sistema SOA.
Proxy Service — Os serviços de proxy atuam como conexão entre os membros da arquitetura SOA e subsistemas de conflito.
Process Service — É um tipo de serviço de proxy que atua como intérprete entre membros SOA criando e organizando os serviços de aplicação para implementar os processos de negócios.
Business Services — São conhecidos como serviços de controlador, que fornecem funções de negócio para a conclusão do processo de negócio sendo serviços flexíveis que alteram as necessidades de negócios. Desenvolvem aplicativos de negócio que automatizam o processo comercial, como gerenciar o atendimento ao cliente, enviar o produto ao cliente, etc.
Conclusão
Essa foi uma discussão breve e superficial de um assunto vasto e complexo que é a arquitetura orientada a serviços. Apesar disso, pudemos notar que a adoção dessa metodologia nos permite estabelecer um alto nível de desacoplamento, reusabilidade, padronização e segurança em nossas aplicações. Em meio a todos esses termos, creio que a reusabilidade é o que merece maior destaque e carinho. A partir do momento que a reusabilidade entra em cena, nós estamos aptos a construir rapidamente outras soluções que irão reutilizar um monte de serviços já estabelecidos enquanto provê serviços adicionais requisitados pela empresa.
Pensando em termo de serviços, você efetivamente irá pensar em como fazer com que o seu negócio se torne auto-sustentável. Eles acabam definindo de forma clara as operações e protocolos disponíveis, bem como, se tornam um ponto central de realização de validação e autenticação para o consumo de nossas regras de negócio. Por meio de sua flexibilidade, uma arquitetura SOA proporciona maior agilidade nos fluxos de trabalho, reutilização aprimorada e uma maior vida útil aos aplicativos — que fim das contas é traduzido em competitividade e redução de custos.
Referências
NITIN, Kumar — Enterprise Benefits on Service Oriented Architecture — SOA. Disponível em: https://dzone.com/articles/enterprise-benefits-service
SOA — Service Categories. Disponível em: https://www.tutorialspoint.com/soa/soa_service_categories.htm
ESPOSITO, Dino e SALTARELLO, Andrea. Microsoft .NET — Architecting Applications for the Enterprise — Microsoft Press 2014.
