Uma arquitetura orientada a serviços (SOA) é um padrão arquitetônico no design de software de computador no qual os componentes do aplicativo fornecem serviços a outros componentes por meio de um protocolo de comunicação, normalmente em uma rede. Os princípios da orientação a serviços são independentes de qualquer produto, fornecedor ou tecnologia.
SOA apenas torna mais fácil para os componentes de software em várias redes trabalharem uns com os outros.
Os serviços da Web que são construídos de acordo com a arquitetura SOA tendem a tornar os serviços da Web mais independentes. Os próprios serviços da web podem trocar dados entre si e, devido aos princípios subjacentes nos quais são criados, eles não precisam de nenhum tipo de interação humana e também não precisam de nenhuma modificação de código. Ele garante que os serviços da web em uma rede possam interagir uns com os outros perfeitamente.
SOA é baseado em alguns princípios-chave que são mencionados abaixo
- Contrato de serviço padronizado - os serviços obedecem a uma descrição de serviço. Um serviço deve ter algum tipo de descrição que descreva do que se trata. Isso torna mais fácil para os aplicativos clientes entenderem o que o serviço faz.
- Loose Coupling - Menos dependência um do outro. Esta é uma das principais características dos serviços web que apenas afirma que deve haver a menor dependência possível entre os serviços web e o cliente que invoca o serviço web. Portanto, se a funcionalidade do serviço for alterada a qualquer momento, ela não deve interromper o aplicativo cliente ou impedi-lo de funcionar.
- Abstração de serviço - os serviços ocultam a lógica que encapsulam do mundo externo. O serviço não deve expor como executa sua funcionalidade; ele deve apenas informar ao aplicativo cliente o que ele faz e não como o faz.
- Reutilização de serviços - a lógica é dividida em serviços com o objetivo de maximizar a reutilização. Em qualquer empresa de desenvolvimento, a reutilização é um grande tópico porque obviamente não se quer perder tempo e esforço construindo o mesmo código repetidas vezes em vários aplicativos que os exigem. Portanto, uma vez que o código para um serviço da web é escrito, ele deve ter a capacidade de trabalhar com vários tipos de aplicativos.
- Autonomia de serviço - os serviços devem ter controle sobre a lógica que encapsulam. O serviço sabe tudo sobre as funcionalidades que oferece e, portanto, também deve ter controle total sobre o código que contém.
- Apatridia de serviço - idealmente, os serviços devem ser sem estado. Isso significa que os serviços não devem reter informações de um estado para o outro. Isso precisaria ser feito a partir do aplicativo cliente. Um exemplo pode ser um pedido feito em um site de compras. Agora você pode ter um serviço da web que fornece o preço de um determinado item. Mas se os itens forem adicionados a um carrinho de compras e a página da web navegar até a página onde você faz o pagamento, a responsabilidade do preço do item a ser transferido para a página de pagamento não deve ser feita pelo serviço web. Em vez disso, isso precisa ser feito pelo aplicativo da web.
- Detecção de serviço - os serviços podem ser descobertos (geralmente em um registro de serviço). Já vimos isso no conceito de UDDI, que realiza um registro que pode conter informações sobre o serviço da web.
- Composibilidade de serviço - os serviços dividem grandes problemas em pequenos problemas. Nunca se deve incorporar todas as funcionalidades de um aplicativo em um único serviço, mas, em vez disso, dividir o serviço em módulos, cada um com uma funcionalidade de negócios separada.
- Interoperabilidade do serviço - os serviços devem usar padrões que permitam que diversos assinantes usem o serviço. Em serviços da web, padrões como XML e comunicação sobre HTTP são usados para garantir a conformidade com este princípio.