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

A SOA remove tarefas do desenvolvedor da aplicações que anteriormente reconstruía ou duplicava funções existentes ou tinha que saber como conectar ou fornecer interoperabilidade com funções existentes.

Cada serviço em uma SOA contém o código e os dados necessários para executar uma função de negócios completa e independente (por exemplo, verificar o crédito de um cliente, calcular o pagamento mensal de um empréstimo ou processar uma aplicação de hipoteca). As interfaces de serviço fornecem acoplamento solto. Isso significa que eles podem ser chamados com pouco ou nenhum conhecimento de como o serviço é implementado abaixo, reduzindo as dependências entre as aplicações.

Essa interface é um contrato de serviço entre o provedor do serviço e o consumidor do serviço. As aplicações por trás da interface de serviço podem ser escritas em Java, Microsoft .Net, Cobol ou qualquer outra linguagem de programação, fornecidas como aplicações de software empacotadas por um fornecedor (por exemplo, SAP), aplicações SaaS (por exemplo, Salesforce CRM) ou obtidas como código aberto.

As interfaces de serviço são frequentemente definidas usando a linguagem de definição de serviço da web (WSDL), que é uma estrutura de marcação padrão baseada em XML (linguagem de marcação extensível).

Os serviços são expostos usando protocolos de rede padrão — como Single Object Access Protocol (SOAP)/HTTP ou Restful HTTP (JSON/HTTP) — para enviar solicitações para ler ou alterar dados. A governança de serviços controla o ciclo de vida do desenvolvimento e, no estágio apropriado, os serviços são publicados em um registro , que permite aos desenvolvedores encontrá-los e reutilizá-los com rapidez para montar novas aplicações ou processos de negócios.

Esses serviços podem ser criados do zero, mas geralmente são criados expondo funções de sistemas de registro legados como interfaces de serviço.

Desta forma, a SOA representa um estágio importante na evolução do desenvolvimento e integração de aplicações nas últimas décadas. Antes do surgimento da SOA no final da década de 1990, conectar uma aplicação a dados ou funções hospedados em outro sistema exigia uma integração ponto a ponto complexa - integração que os desenvolvedores tinham que recriar, em parte ou no todo, para cada novo projeto de desenvolvimento. A exposição dessas funções por meio de serviços SOA permitiu que o desenvolvedor simplesmente reutilizasse o recurso existente e se conectasse por meio da arquitetura SOA ESB (veja abaixo).

Embora o SOA e a mais recente arquitetura de microsserviços compartilhem muitas palavras em comum (ou seja, "serviço" e "arquitetura"), elas estão apenas vagamente relacionadas e, de fato, operam em escopos diferentes, como discutido posteriormente neste artigo.

Um ESB, ou barramento de serviços corporativos, é um padrão arquitetônico no qual um componente de software centralizado executa integrações entre aplicações. Ele realiza transformações de modelos de dados, lida com conectividade e mensagens, realiza roteamento, converte protocolos de comunicação e pode gerenciar a composição de várias solicitações.

O ESB pode disponibilizar essas integrações e transformações como uma interface de serviço reutilizável por novas aplicações. O padrão ESB é normalmente implementado usando um tempo de execução de integração e conjunto de ferramentas especialmente projetados que ajudam a garantir a melhor produtividade possível.

É possível implementar uma SOA sem um ESB, mas isso seria equivalente a apenas ter um monte de serviços. Cada proprietário de aplicação precisaria se conectar diretamente a qualquer serviço necessário e realizar as transformações de dados necessárias para atender a cada uma das interfaces de serviço.

Isso dá muito trabalho (mesmo que as interfaces sejam reutilizáveis) e cria um desafio significativo de manutenção no futuro, pois cada conexão é ponto a ponto. Na verdade, os ESBs foram, eventualmente, considerados um elemento tão de facto de qualquer implementação de SOA que os dois termos são às vezes usados como sinônimos, criando confusão.

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

• Maior agilidade nos negócios; maior velocidade de lançamento no mercado: a reutilização é fundamental. A eficiência da montagem de aplicações 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 aplicações muito mais rapidamente em resposta a novas oportunidades de negócios.
  A abordagem de arquitetura orientada a serviços oferece suporte a cenários para integração de aplicativos, integração de dados e automação de estilo de orquestração de serviços de processos de negócios ou fluxos de trabalho. Isso acelera o design e o desenvolvimento de software, permitindo que os desenvolvedores gastem significativamente menos tempo integrando e mais tempo se concentrando em entregar e melhorar suas aplicações.
• Capacidade de usar funções legadas em novos mercados: uma SOA bem elaborada permite que os desenvolvedores facilmente peguem funções “bloqueadas” em uma plataforma ou ambiente de computação e as estendam para novos ambientes e mercados. Por exemplo, muitas empresas usaram a SOA para expor funções de sistemas financeiros baseados em mainframe para novas aplicações da web. Isso permite que seus clientes atendam a processos e informações anteriormente acessíveis apenas por meio da interação direta com os funcionários ou parceiros de negócios da empresa.
• Colaboração aprimorada entre negócios e TI: em uma SOA, os serviços podem ser definidos em termos de negócios (por exemplo, "gerar cotação de seguro" ou "calcular ROI de equipamentos de capital"). Isso permite 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 pelo uso de serviços ou as implicações comerciais de alterar um processo), que podem levar a um resultado melhor.

Em 2010, as implementações de SOA estavam indo a todo vapor em empresas líderes em praticamente todos os setores. Por exemplo:

a Delaware Electric recorreu à SOA para integrar sistemas que antes não se comunicavam entre si, resultando em eficiências de desenvolvimento que ajudaram a organização a se manter solvente durante um congelamento de cinco anos exigido pelo estado nas tarifas elétricas.

A Cisco adotou a SOA para garantir que sua experiência de pedido de produtos fosse consistente em todos os produtos e canais, expondo processos de pedidos como serviços que as divisões, aquisições e parceiros de negócios da Cisco poderiam incorporar em seus sites. A

A Liberty Blue Cross (IBC), da Filadélfia, implementou uma SOA para garantir que os diversos constituintes que lidam com os dados dos pacientes (agentes de atendimento ao cliente da IBC, consultórios médicos, usuários do site da IBC) estivessem trabalhando com a mesma fonte de dados (uma "fonte única da verdade").

Especialistas preencheram algumas milhares de páginas impressas e digitais comparando a SOA e microsserviços e definindo as sutilezas de seu relacionamento entre si. Para os fins deste artigo, as principais diferenças entre os dois são o acoplamento dos componentes e o escopo de uso:

a SOA é um estilo arquitetônico de integração e um conceito para toda a empresa. Ela permite que as aplicações existentes sejam expostas por meio de interfaces fracamente acopladas, cada uma correspondendo a uma função empresarial que possibilita que as aplicações em uma parte de uma empresa estendida reutilizem funções em outras aplicações.

A arquitetura de microsserviços é um estilo arquitetônico de aplicação e um conceito com escopo de aplicação. Ela permite que os componentes internos de uma única aplicação sejam divididos em pequenas partes que podem ser alteradas, dimensionadas e administradas de forma independente. Ela não define como as aplicações se comunicam entre si. Para isso, voltamos ao escopo empresarial das interfaces de serviço fornecidas pela SOA.

A arquitetura de microsserviços surgiu e ganhou força com o aumento da virtualização, da computação em nuvem, das práticas de desenvolvimento ágil e do DevOps. A maioria das vantagens dos microsserviços nesses contextos surge do desacoplamento dos componentes, o que simplifica e melhora o seguinte:

• Agilidade e produtividade do desenvolvedor: os microsserviços permitem que os desenvolvedores incorporem novas tecnologias a uma parte da aplicação sem afetar o restante da aplicação. Qualquer componente pode ser modificado, testado e implementado de forma independente dos outros, o que acelera os ciclos de iteração.
• Escalabilidade: os microsserviços podem aproveitar ao máximo a escalabilidade da nuvem: qualquer componente pode ser escalado de forma independente dos outros para a resposta mais rápida possível às demandas de carga de trabalho e ao uso mais eficiente dos recursos de computação.
• Resiliência: novamente, graças ao desacoplamento, a falha de um microsserviço não afeta os outros. E cada microsserviço pode atender aos seus próprios requisitos de disponibilidade, sem impor os outros componentes ou toda a aplicação aos maiores requisitos de disponibilidade comuns.

Para um mergulho mais profundo nas diferenças entre SOA e microsserviços, consulte SOA versus microsserviços: qual é a diferença?

Da mesma forma que a arquitetura de microsserviços tem potencial para trazer melhorias em agilidade, escalabilidade e resiliência ao projeto de aplicações, essas mesmas técnicas também podem ser aplicadas à integração.

Isso é importante porque, com o tempo, o padrão de ESB altamente centralizado e sua equipe centralizada associada de especialistas em integração podem se tornar um gargalo. Emprestando princípios de microsserviços , podemos dividir o ESB em uma integração descentralizada e mais refinada. Essa é uma das principais instalações por trás da integração ágil.