Login / Registre-se Account

Aplicações nativas em nuvem

O que é arquitetura orientada a serviços (SOA)?

Jump to section

Arquitetura orientada a serviços (SOA) é um tipo de design de software que torna os componentes reutilizáveis usando interfaces de serviços com uma linguagem de comunicação comum em uma rede. 

Um serviço é uma unidade ou conjunto de funcionalidades de software independente, que foi desenvolvido para concluir uma tarefa específica, como recuperar determinadas informações ou executar uma operação. Ele contém as integrações de dados e o código necessários para executar uma função de negócios completa. Esses serviços podem ser acessados remotamente e é possível interagir com eles e atualizá-los de maneira independente.

Em outras palavras, a SOA integra os componentes de software que foram implantados e são mantidos separadamente, permitindo que eles se comuniquem e trabalhem juntos para formar aplicações de software que funcionam em sistemas diferentes.

Como funciona a arquitetura orientada a serviços?

Antes do surgimento da SOA, no final da década de 1990, a conexão de uma aplicação a serviços em um outro sistema era um processo complexo que envolvia uma intrincada integração point-to-point (P2P), incluindo conectividade, roteamento, modelos de tradução de dados etc. E em cada projeto novo, os desenvolvedores precisavam recriar essa integração. Esse modelo era conhecido como "monolítico" porque o código da aplicação inteira era incorporado a uma implantação. Se apenas um aspecto da aplicação não funcionasse corretamente, era necessário colocar tudo offline temporariamente para fazer as devidas correções e depois implantar a aplicação de novo como uma nova versão. 

Ao expor serviços usando protocolos de rede padrão, como SOAP, JSON, ActiveMQ ou Apache Thrift, para enviar solicitações ou acessar dados, a SOA facilita a vida dos desenvolvedores, pois eles não precisam fazer a integração do zero. Em vez disso, eles podem usar padrões chamados enterprise service buses (ESBs), que realizam a integração entre um componente central e sistemas de back-end e depois os tornam acessíveis como interfaces de serviços. Isso também ajuda os desenvolvedores a reutilizarem funções existentes, em vez de recriá-las.

No estilo de arquitetura orientada a serviços, a comunicação entre os serviços é realizada por um sistema de "baixo acoplamento". Essa é uma maneira de interconectar componentes, também chamados de "elementos", em um sistema ou rede para que transmitam informações ou coordenem processos empresariais e reduzam as dependências entre eles. Efetivamente, isso cria um novo app.  

Vantagens em comparação com a abordagem monolítica

  • Menor time to market e maior flexibilidade: a reutilização de serviços faz com que seja mais fácil e rápido montar aplicações. Os desenvolvedores não precisam sempre começar do zero, como no caso das aplicações monolíticas. 
  • Uso de infraestrutura legada em novos mercados: com a SOA, é mais fácil para os desenvolvedores escalar ou ampliar o uso de uma funcionalidade para plataformas ou ambientes novos. 
  • Redução de custos resultante da maior agilidade e eficiência no desenvolvimento.
  • Fácil manutenção: como todos os serviços são autossuficientes e independentes, é possível modificá-los e atualizá-los conforme a necessidade, sem afetar os outros serviços. 
  • Escalabilidade: como a SOA permite executar serviços usando vários serviços, plataformas e linguagens de programação diferentes, há uma grande melhoria na escalabilidade. Além disso, a SOA usa um protocolo de comunicação padronizado, o que permite às empresas reduzir a interação entre clientes e serviços. Com a redução no nível de interação, é possível escalar aplicações com menos urgência e aborrecimentos. 
  • Maior confiabilidade: por ser mais fácil fazer o debug de serviços menores do que um grande código, a SOA permite criar aplicações mais confiáveis.
  • Maior disponibilidade: os recursos da SOA estão disponíveis para todos.

Funções da SOA

A base de uma arquitetura orientada a serviço é constituída de três funções. 

Provedor de serviços

Um provedor de serviços cria serviços web e os oferece para um registro de serviços. Ele é responsável pelos termos de uso desse serviço.

Broker ou registro de serviços

Um broker de serviços ou registro de serviços é responsável por oferecer informações solicitadas sobre o serviço. O broker pode ser público ou privado. 

Solicitante ou cliente de serviços

Um solicitante de serviços encontra um serviço no broker ou no registro de serviços. Então, conecta-se ao provedor de serviços para recebê-lo.

Arquiteturas orientadas a serviços x microsserviços

O novo conceito de serviços introduzido pela SOA agora é um aspecto central da cloud computing e da virtualização modernas, sendo aplicado a elementos como o middleware e os microsserviços

Devido às similaridades entre ambos, muitas vezes as pessoas acham que SOA e arquitetura de microsserviços são a mesma coisa. A principal característica que os diferencia é o escopo: a SOA é uma abordagem de arquitetura adotada pela empresa como um todo, enquanto os microsserviços são uma estratégia de implementação da equipe de desenvolvimento para cada aplicação. 

A comunicação entre os componentes também é diferente. A SOA usa ESB, enquanto os microsserviços comunicam-se uns com os outros de maneira stateless, por meio de APIs independentes de linguagem. Devido a esse aspecto das APIs nos microsserviços, as equipes de desenvolvimento também podem escolher as ferramentas com que preferem trabalhar. Assim, os microsserviços são mais tolerantes e flexíveis.

Às vezes, a SOA também é confundida com software como serviço. SaaS é uma forma de cloud computing que fornece aos usuários uma aplicação em nuvem com a infraestrutura de TI e plataformas subjacentes a ela. Serviços web na SOA podem ser oferecidos por provedores como aplicações SaaS. Geralmente, um provedor de serviços de nuvem, como a AWS, o Azure ou o IBM Cloud, gerencia o ambiente de nuvem que hospeda a aplicação SaaS. 

Os usuários interagem com o software por meio de um navegador da web no computador ou em dispositivos mobile. Eles também podem usar APIs, como REST ou SOAP, para conectar o software a outras funções.

Red Hat e microsserviços

Devido aos avanços na tecnologia de containers, os microsserviços se tornaram a base das aplicações nativas em nuvem (microsserviços com baixo acoplamento que são implantados em containers Linux e conectados usando APIs ou uma rede em malha para roteamento de mensagens). 

Cada elemento implementa uma funcionalidade empresarial e é desenvolvido de forma independente por equipes de DevOps pequenas que usam fluxos de trabalho como integração e implantação contínuas (CI/CD). Isso significa desenvolvimento acelerado de software, implantação automática e atualizações regulares sem as restrições dos ciclos de desenvolvimento monolíticos.  

Com um portfólio de soluções open source, que inclui o Red Hat® Enterprise Linux® e o Red OpenShift, a Red Hat forma parcerias com empresas que desejam migrar aos poucos a infraestrutura e o desenvolvimento de aplicações para o ambiente rápido e adaptável da cloud computing e ainda aproveitar ao máximo os investimentos em TI já realizados. 

Aprenda mais sobre os microsserviços e a Red Hat