A arquitetura orientada a serviços (SOA) surgiu no início deste século como uma evolução da computação distribuída. Antes de SOA, os serviços eram entendidos como o resultado final do processo de desenvolvimento de aplicativos. Em SOA, o próprio aplicativo é composto de serviços. Os serviços podem ser fornecidos individualmente ou combinados como componentes em um serviço composto maior.
Os serviços interagem pela rede usando um protocolo como REST ou SOAP (Simple Object Access Protocol). Os serviços são fracamente acoplados, o que significa que a interface do serviço é independente da implementação subjacente. Desenvolvedores ou integradores de sistema podem compor um ou mais serviços em um aplicativo sem necessariamente saber como cada serviço é implementado.
Este artigo é uma visão geral do Java SOA e as principais características de um arquitetura orientada a serviços implementada usando serviços da web baseados em SOAP. Também compararei brevemente SOA e microsserviços e discutirei a diferença entre RESTful e serviços da web baseados em SOAP em Java.
Por que arquitetura orientada a serviços?
SOA aborda três desafios empresariais comuns :
- Responda rapidamente às mudanças nos negócios.
- Aproveite os investimentos existentes em infraestrutura.
- Ofereça suporte a novos canais de interação com clientes, parceiros e fornecedores.
A infraestrutura corporativa é heterogênea entre sistemas operacionais, aplicativos, software de sistema e infraestrutura de aplicativos. Como resultado, muitos sistemas corporativos são compostos de aplicativos complexos e inconsistentes que fornecem uma variedade de serviços interdependentes. Os aplicativos existentes que executam os processos de negócios atuais são essenciais, portanto, começar do zero ou modificá-los é uma proposta delicada. Mas as empresas devem ser capazes de modificar e expandir a infraestrutura técnica para atender às demandas de negócios.
Como em comparação com um archi monolítico Por outro lado, a natureza fracamente acoplada de SOA torna relativamente fácil conectar novos serviços ou atualizar serviços existentes para novos requisitos de negócios. Ele também oferece a opção de tornar os serviços consumíveis em diferentes canais e expor aplicativos legados como serviços, protegendo, assim, os investimentos em infraestrutura.
Por serem fracamente acoplados, os componentes SOA podem ser alterados com impacto mínimo em outros componentes . Os componentes também podem ser adicionados à arquitetura de maneira padronizada e podem ser dimensionados para lidar com a carga.
Como exemplo, considere como uma empresa pode usar um conjunto de aplicativos existentes para criar um novo, aplicação composta da cadeia de suprimentos. Embora os aplicativos existentes sejam heterogêneos e distribuídos em vários sistemas, sua funcionalidade é exposta e acessada usando interfaces padrão.
Figura 1. Aplicativo de cadeia de suprimentos em uma arquitetura orientada a serviços
Características principais de SOA
SOA pode ser tão simples quanto um único componente consumindo serviços fornecidos por outro componente ou tão sofisticado quanto uma variedade de componentes interagindo por meio de um barramento de serviço corporativo, como o ESB da MuleSoft. Não importa a escala, a chave para uma implementação de SOA bem-sucedida é para usar o mínimo de complexidade possível para atingir seus objetivos. Sua primeira e última pergunta sempre deve ser: Este design atende aos nossos requisitos de negócios?
Independentemente da escala ou complexidade, o padrão de uma arquitetura orientada a serviços é mais ou menos o mesmo:
- Os provedores de serviços expõem os terminais e descrevem o ações disponíveis em cada ponto de extremidade.
- Os consumidores de serviço emitem solicitações e consomem respostas.
- Os provedores de serviços geram mensagens para lidar com solicitações.
Implementação de serviço- arquitetura orientada
Para implementar SOA, você começa com a arquitetura de serviço básica e, em seguida, fornece a infraestrutura, ou seja, protocolos e outras ferramentas que permitem a comunicação e a interoperabilidade. A Figura 2 mostra um diagrama de uma arquitetura de serviço típica.
Figura 2. Um exemplo de arquitetura de serviço
Neste diagrama, três consumidores chamam serviços enviando mensagens para um barramento de serviço corporativo, que transforma e roteia as mensagens para uma implementação de serviço apropriada . Um mecanismo de regras de negócios incorpora regras de negócios em um serviço ou entre serviços. Uma camada de gerenciamento de serviço gerencia atividades como auditoria, cobrança e registro.
Os componentes nesta arquitetura são fracamente acoplados, de modo que podem ser trocados ou atualizados com impacto relativamente mínimo no aplicativo como um todo. Isso dá à empresa flexibilidade para adicionar ou atualizar processos de negócios conforme necessário. Para a maior parte, as alterações em serviços individuais não devem afetar muito outros serviços.
Serviços da web baseados em SOAP
Os serviços da web implementados usando SOAP ainda são mais rígidos do que a implementação de serviços da web RESTful ou microsserviços, mas muito mais flexíveis do que os primeiros dias de SOA. Aqui, veremos apenas os protocolos de alto nível necessários para serviços da web baseados em SOAP.
SOAP, WSDL e XSD
SOAP, WSDL e XSD são a infraestrutura fundamental de uma implementação de serviço da Web baseada em SOAP. WSDL é usado para descrever o serviço, e SOAP é a camada de transporte para o envio de mensagens entre consumidores e provedores de serviço. Os serviços se comunicam com mensagens formalmente definidas usando o esquema XML (XSD). Você pode pensar em WSDL como a interface do serviço (vagamente análoga a uma interface Java). A implementação é feita em classes Java e a comunicação na rede ocorre via SOAP. Funcionalmente, um consumidor procuraria um serviço, obteria o WSDL para esse serviço e, em seguida, chamaria o serviço usando SOAP.
Segurança de serviço da Web
O WS -I A especificação do Basic Profile 2.0 trata da segurança da mensagem. Esta especificação se concentra na troca de credenciais, integridade da mensagem e confidencialidade da mensagem.
Descoberta de serviço da web
Uma vez que a pedra angular da descoberta de serviço da web, UDDI (Descrição, Definição e Integração Universal) desapareceu na história. Hoje é comum expor um serviço da web baseado em SOAP da maneira que você faria com qualquer outro serviço, por meio de um URL de endpoint. Como exemplo, você poderia usar a interface de endpoint de serviço JAX-WS e sua @WebService e @WebMethod anotações.
Construindo e implantando serviços da web
Os desenvolvedores Java têm várias opções para construir e implantar com base em SOAP serviços da Web, incluindo Apache Axis2 e Spring-WS; no entanto, o padrão Java é JAX-WS, a API Java para XML Web Services. A ideia central por trás do JAX-WS é criar classes Java e anotá-las para criar os artefatos necessários. Nos bastidores, JAX-WS usa vários pacotes Java, incluindo JAXB, uma biblioteca de propósito geral para vincular classes Java a XML.
JAX-WS oculta a complexidade subjacente e os protocolos do desenvolvedor, agilizando assim o processo de definir e implantar serviços SOAP baseados em Java. IDEs Java modernos como Eclipse incluem suporte completo para o desenvolvimento de serviços da Web JAX-WS. O JAX- A especificação WS também foi selecionada para desenvolvimento contínuo em Jakarta EE.
Conclusão
A arquitetura orientada a serviços implementada com serviços da web baseados em SOAP requer mais rígida e definições de serviço formais do que serviços da Web RESTful ou microsserviços. No entanto, algumas organizações maiores continuam a favorecer o estilo mais formal imposto pelo SOAP. Muitos sistemas legados de grande escala também são construídos em SOAP, e alguns sistemas B2B e internos escolhem serviços da web baseados em SOAP para seus contratos de API definidos mais formalmente. Esteja você desenvolvendo ou mantendo um sistema corporativo em grande escala, entender o padrão SOA e ser capaz de avaliar suas opções para implementá-lo será útil em sua carreira de programação.