SOA, ou arquitetura orientada a serviços, define uma maneira de tornar os componentes de software reutilizáveis e interoperáveis por meio de interfaces de serviço. Os serviços usam padrões comuns de interface e um padrão de arquitetura para que serem incorporados rapidamente a novos aplicativos.  Isso remove tarefas do desenvolvedor de aplicativos que anteriormente redesenvolveu ou duplicou funcionalidade existente ou teve que saber como conectar ou fornecer interoperabilidade com funções existentes.

Cada serviço em uma SOA incorpora o código e os dados necessários para executar uma função de negócios completa e confidencial (por exemplo, verificar o crédito de um cliente, calcular um pagamento mensal de um empréstimo ou processar uma proposta de hipoteca). As interfaces de serviços oferecem acoplamento fraco, o que significa que exigem pouco ou nenhum conhecimento técnico sobre como o serviço é implementado, reduzindo as dependências entre os aplicativos. 

Esta interface é um contrato de serviço entre o provedor de serviços e o consumidor do serviço. Os aplicativos por trás da interface de serviço podem ser escritos em Java, Microsoft .Net, Cobol ou qualquer outra linguagem de programação, fornecida como aplicativos de software empacotados por um fornecedor (por exemplo, SAP), aplicativos SaaS (por exemplo, Salesforce CRM) ou obtidos como aplicativos de código aberto.  As interfaces de serviços são normalmente definidas usando Linguagem de Descrição de Serviços da Web (WSDL), que é uma estrutura padrão de marcações baseada em XML (linguagem de marcação extensível).  

Os serviços são expostos usando protocolos de rede padrão, como SOAP (protocolo de acesso a objeto simples)/HTTP ou Restful HTTP (JSON/HTTP), para enviar solicitações de leitura ou de alteração de dados. A governança do serviço controla o ciclo de vida para o desenvolvimento e no momento certo os serviços são publicados em um registro que permite aos desenvolvedores encontrá-los rapidamente e reutilizá-los para criar novos aplicativos ou processos de negócios.

Esses serviços podem ser desenvolvidos partindo da estaca zero, mas geralmente são criados ao expor funções de sistemas legados de registro como interfaces de serviço.

Dessa forma, a SOA representa uma etapa importante na evolução do desenvolvimento e integração de aplicativos ao longo das últimas décadas. Antes da SOA surgir no final da década de 1990, conectar um aplicativo a dados ou a funcionalidades hospedadas em outro sistema exigia integração complexa ponto a ponto, que os desenvolvedores tinham de recriar, de forma parcial ou integral, para cada novo projeto de desenvolvimento. A exposição dessas funções através de serviços de SOA  permite ao desenvolvedor simplesmente reutilizar o recurso existente e conectar-se através da arquitetura da SOA ESB  (veja abaixo).

Note que embora a SOA, e as arquiteturas de microsserviços mais recentes, compartilhem muitas palavras em comum (como "serviço" e " arquitetura"), há pouca relação entre elas e, na verdade, operam em escopos diferentes, conforme será discutido mais adiante neste artigo.

Um ESB, ou barramento de serviço corporativo, é um padrão de arquitetura pelo qual um componente de software centralizado realiza integrações entre aplicativos.  Ele realiza transformações de modelos de dados, administra conectividade/mensagens, realiza roteamento, converte protocolos de comunicação e possivelmente gerencia a composição de várias solicitações. O ESB pode disponibilizar essas integrações e transformações em uma interface de serviços para que novos aplicativos possam reutilizá-las . O padrão ESB é geralmente implementado usando um tempo de execução de integração e um conjunto de ferramentas especialmente projetados que garantem a melhor produtividade possível.

É possível implementar uma SOA sem um ESB, mas isso seria equivalente a ter nada mais que um monte de serviços.  Cada proprietário de aplicativo precisaria se conectar a qualquer serviço necessário e realizar as transformações de dados para atender a todas as interfaces de serviço. Isso exige muito trabalho (mesmo que as interfaces sejam reutilizáveis) e aumenta significativamente os desafios de manutenção futura, pois todas as conexões são ponto a ponto.  Na verdade, os ESBs foram, eventualmente, considerados um elemento essencial de qualquer implementação de SOA , tanto que os dois termos são, por vezes, usados como sinônimos, gerando confusão.

Saiba mais sobre ESBs

Em comparação com as arquiteturas que a precederam, a SOA oferece benefícios significativos para a empresa:

• Maior agilidade de negócios; menor time to market: a reutilização é essencial.  A eficiência de montagem de aplicativos a partir de serviços reutilizáveis, ou seja, blocos de construção, em vez de reescrever e reintegrar a cada novo projeto de desenvolvimento, permite que os desenvolvedores criem aplicativos mais rápido em resposta a novas oportunidades de negócios. A abordagem de arquitetura orientada a serviços suporta cenários de integração de aplicativos, integração de dados e automação de estilo de serviço ou orquestração de processos de negócios ou fluxos de trabalho.  Isso acelera o design e o desenvolvimento de software permitindo que os desenvolvedores gastem um tempo significativamente menor com integração e muito mais tempo focando em criar e  aprimorar seus aplicativos. 
  
  
• Capacidade de potencializar a  funcionalidade legada  em novos mercados:  uma  SOA  bem elaborada permite que os desenvolvedores facilmente peguem uma funcionalidade  'bloqueada' em uma plataforma ou ambiente de computação e a estendam a novos ambientes e mercados. Por exemplo, muitas empresas utilizaram a SOA para expor funcionalidades de sistemas financeiros com base em mainframe para a web, permitindo que seus clientes tivessem acesso por conta própria a processos e informações anteriormente acessíveis apenas através da interação direta com os funcionários ou parceiros de negócios da empresa.
  
  
• Melhor colaboração entre negócios e TI: em uma  SOA, os serviços podem ser definidos em termos de negócio (por exemplo, 'gerar cotação de seguro' ou 'calcular ROI de equipamento de capital'). Isso possibilita que os analistas de negócios trabalhem de forma mais eficaz com os desenvolvedores em insights importantes, como o escopo de um  processo de negócios  definido por um serviço ou as implicações aos negócios devido à mudança de um processo, que pode levar a um melhor resultado.

Até 2010, implementações de  SOA  estavam a todo vapor em empresas líderes em praticamente todos os mercados. Por exemplo:

• A Delaware Electric escolheu a  SOA  para integrar sistemas que anteriormente não conversavam entre si, resultando em eficiências de desenvolvimento que ajudaram a organização a permanecer solvente durante um congelamento de cinco anos das tarifas elétricas ordenado pelo estado.
  
  
• A Cisco adotou a  SOA  para assegurar que sua experiência de pedido de produtos fosse consistente em todos os produtos e canais ao expor processos de pedido como serviços que as divisões, aquisições e parceiros de negócios da Cisco poderiam incorporar em seus  websites.
  
  
• A Independence Blue Cross (IBC) da Filadélfia implementou uma  SOA  para garantir que os diferentes cidadãos que lidam com dados de pacientes, agentes de atendimento ao cliente da IBC, escritórios médicos, usuários do website da IBC, estivessem trabalhando com a mesma fonte de dados (uma 'versão  única da verdade').

Especialistas escreveram milhares de páginas  impressas e digitais comparando a SOA e os microsserviços e definindo as sutilezas de sua relação entre eles. Para efeitos deste artigo, as principais diferenças entre os dois são o acoplamento de componentes e o escopo de uso:

• SOA é um estilo de  arquitetura de integração e um conceito corporativo. Ela possibilita que os aplicativos existentes sejam expostos em interfaces fracamente acopladas, cada uma correspondendo a uma  função de negócios, que possibilita que aplicativos em uma parte de uma empresa estendida  reusem  a funcionalidade  em outros aplicativos.
  
  
• A arquitetura de  microsserviços  é um estilo de arquitetura de aplicativos  e um conceito de  escopo de aplicativo. Ela possibilita que os núcleos de um único aplicativo sejam divididos em pequenos pedaços que podem ser alterados, escalonados e administrados de maneira independente. Ela não define como os aplicativos conversam entre si, por isso estamos de volta ao escopo corporativo das  interfaces de serviço  fornecidas pela  SOA.

A arquitetura  de microsserviços  surgiu e ganhou popularidade com a virtualização, a  cloud computing, as práticas de desenvolvimento Agile e o  DevOps. A maior parte das vantagens dos  microsserviços  nestes contextos surgem a partir do desacoplamento dos componentes, o que simplifica e melhora o seguinte:

• Agilidade e produtividade do desenvolvedor: Os microsserviços  permitem que desenvolvedores incorporem novas tecnologias a uma parte do aplicativo sem recuperar o restante do aplicativo. Qualquer componente pode ser modificado, testado e implementado independentemente dos demais, o que acelera os ciclos de iteração.
  
  
• Escalabilidade: Os microsserviços  podem tirar o máximo proveito da escalabilidade da cloud . Qualquer componente pode ser escalonado independentemente dos outros para fornecer uma resposta mais rápida possível às demandas de carga de trabalho e o uso mais eficiente dos recursos de computação.
  
  
• Resiliência: novamente, graças ao desacoplamento, a falha de um  microsserviço  não impacta os demais. E cada  microsserviço  pode desempenhar conforme os seus próprios requisitos de disponibilidade sem comprometer os outros componentes ou todo o aplicativo aos maiores requisitos comuns de disponibilidade.

Para obter mais informações sobre as diferenças entre a SOA e  os microsserviços, consulte "SOA vs. Microsserviços: Qual é a diferença?"

Da mesma forma que a  arquitetura de  microsserviços  tem o potencial de trazer melhorias em agilidade,  escalabilidade e resiliência ao design de aplicativos, essas mesmas técnicas também podem ser aplicadas à integração. Isso é importante porque, com o tempo, o padrão  ESB  fortemente centralizado e sua equipe centralizada associada de especialistas em integração podem se tornar um gargalo. A partir dos princípios de  microsserviços , é possível dividir o  ESB  em integrações descentralizadas com mais baixa granularidade. Esta é uma das principais premissas por trás da  integração ágil.