SOA (Arquitetura Orientada a Serviços)

menu icon

SOA (Arquitetura Orientada a Serviços)

Conheça a SOA (arquitetura orientada a serviços), um estágio importante na evolução do desenvolvimento e integração de aplicativos.

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

SOA, ou arquitetura orientada a serviços, define uma maneira de tornar os componentes de software reutilizáveis por meio de interfaces de serviço. Essas interfaces utilizam padrões de comunicação comuns de tal modo que eles podem ser rapidamente incorporados a novos aplicativos sem a necessidade de realizar uma integração sempre.

Cada serviço em uma SOA incorpora o código e as integrações de dados necessários para executar uma função de negócios completa e discreta (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ço fornecem acoplamento fraco, ou seja, elas podem ser solicitadas com pouco ou nenhum conhecimento sobre como a integração está sendo implementada nos bastidores. Os serviços são expostos usando protocolos de rede padrão, como SOAP (protocolo simples de acesso a objetos) /HTTP ou JSON/HTTP, para enviar solicitações para ler ou alterar dados. Os serviços são publicados de forma a possibilitar que os desenvolvedores os encontrem rapidamente e os reutilizem para montar novos aplicativos.

Esses serviços podem ser desenvolvidos a partir do zero, mas por vezes são criados ao expor funções de sistemas legados de registro como interfaces de serviço.

Dessa forma, a SOA representa um estágio importante na evolução do desenvolvimento e integração de aplicativos ao longo das últimas décadas. Antes de a SOA surgir no final da década de 1990, conectar um aplicativo a dados ou a funcionalidades residentes em outro sistema exigia integração ponto a ponto complexa-integração que os desenvolvedores tinham de recriar, em parte ou inteira, para cada novo projeto de desenvolvimento. Expor essas funções através da SOA elimina a necessidade de recriar a integração profunda toda vez.

Observe que, embora a SOA e a mais recente arquitetura de microsserviços compartilham muitas palavras em comum, elas estão apenas vagamente relacionadas e, de fato, operam em diferentes escopos, como discutido mais adiante neste artigo.

O que é um ESB?

Um ESB, ou barramento de serviços corporativos, é um padrão pelo qual um componente centralizado executa a integração aos sistemas back-end e, em seguida, disponibiliza aquelas integrações como interfaces de serviço. Ele realiza a tradução de modelos de dados, conectividade profunda, roteamento e potencialmente composição de diversas solicitações e disponibiliza estes como uma única interface de serviço para reutilização por novos aplicativos. O padrão ESB é tipicamente implementado usando um tempo de execução e conjunto de ferramentas especialmente projetados que são bem adequados às capacidades acima, garantindo a melhor produtividade possível.

Em teoria, é possível implementar uma SOA sem um ESB, mas os proprietários de aplicativos teriam que encontrar sua própria maneira única de expor as interfaces de serviço, o que é muito trabalho (mesmo se as interfaces sejam eventualmente reutilizáveis) e cria um desafio de manutenção significativo no futuro. Na verdade, os ESBs foram, eventualmente, considerados um elemento de facto de qualquer implementação de SOA, tanto que os dois termos são, por vezes, usados de maneira sinônima, gerando confusão.

Saiba mais sobre ESBs lendo "Introdução ao ESB (barramento de serviços corporativos)".

Benefícios da SOA

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

  • Maior agilidade dos negócios, tempo de comercialização mais rápido: A eficiência de montar aplicativos a partir de interfaces de serviço reutilizáveis, em vez de reescrever e reintegrar a cada novo projeto de desenvolvimento, possibilita que os desenvolvedores desenvolvam aplicativos muito mais rapidamente em resposta às novas oportunidades de negócios.
  • Capacidade de potencializar a funcionalidade legada em novos mercados: Uma SOA bem elaborada possibilita 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 equipamento de capital ROI'). 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.

Exemplos de SOA

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

  • A Delaware Electric procurou 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 garantir 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 constituintes 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').

SOA vs. microsserviços

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

  • SOA é um conceito corporativo. Ela possibilita que os aplicativos existentes sejam expostos em interfaces vagamente acopladas, cada uma correspondendo a uma função de negócio, que possibilita que aplicativos em uma parte de uma empresa estendida reusem a funcionalidade em outros aplicativos.
  • A arquitetura de microsserviços é um conceito com escopo definido pelo 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 fôlego com o aumento da virtualização , computação em cloud, práticas de desenvolvimento Agile e DevOps. A maior parte das vantagens dos microsserviços nestes contextos surgem a partir do desacoplamento completo 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 a 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 um conhecimento mais profundo sobre as diferenças entre a SOA e os microsserviços, veja "SOA vs. Microsserviços: Qual é a diferença?"

Da mesma forma que a arquitetura de microsserviços tem o potencial de trazer melhorias na agilidade, escalabilidade e resistê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. Emprestando dos princípios de microsserviços, é possível potencialmente dividir o ESB em integrações descentralizadas com mais baixa granularidade. Esta é uma das principais premissas por trás da integração ágil.

SOA e IBM Cloud

À medida que sua empresa migra sua infraestrutura de TI em direção a uma abordagem de cloud híbrida , há uma alta probabilidade de você estar transformando uma variedade de cargas de trabalho, incluindo aquelas com base na SOA, em modelos de implementação em nuvem mais leves e flexíveis. A IBM é uma das pioneiras da SOA e as ofertas e serviços da IBM Cloud podem potencializar e estender seus investimentos em SOA existentes para a cloud.

Dê o próximo passo:

A SOA proporciona a capacidade de tornar os serviços consumíveis em diferentes canais não importa onde o aplicativo principal ou o banco de dados residirem, o que ajuda a sua organização a capitalizar os investimentos à medida que ela moderniza os aplicativos na jornada rumo à cloud.

Comece a usar hoje mesmo com uma conta IBM Cloud.