O que é SOA? Orientado a serviço ArchiPrincípios de arquitetura

What is SOA (Service Oriented Architecture)?

A Service Oriented Architecture (SOA) é um architectural pattern in computer software design in which application components provide services to other components via a communications protocol, typically over a network. The principles of service-orientation are independent of any product, vendor or technology.

SOA apenas facilita o trabalho entre componentes de software em várias redes.

Web services which are built as per the SOA architecture tend to make web service more independent. The web services themselves can exchange data with each other and because of the underlying principles on which they are created, they don’t need any sort of human interaction and also don’t need any code modifications. It ensures that the web services on a network can interact with each other seamlessly.

Orientado a serviço Architecture (SOA) Principles

Existem 9 tipos de princípios de design SOA mencionados abaixo

1. Contrato de serviço padronizado

Os serviços seguem uma descrição de serviço. Um serviço deve ter algum tipo de descrição que descreva do que se trata o serviço. Isso torna mais fácil para os aplicativos clientes entenderem o que o serviço faz.

2. Acoplamento solto

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 mudar a qualquer momento, isso não deverá interromper o funcionamento do aplicativo cliente ou impedi-lo de funcionar.

3. Abstração de serviço

Os serviços escondem a lógica que encapsulam do mundo exterior. 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.

4. Reutilização do serviço

A lógica é dividida em serviços com o intuito de maximizar o reaproveitamento. Em qualquer empresa de desenvolvimento, a reutilização é um grande tópico porque, obviamente, ninguém gostaria de gastar tempo e esforço construindo o mesmo código repetidamente em vários aplicativos que o exigem. Portanto, uma vez escrito o código de um serviço da Web, ele deverá ter a capacidade de trabalhar com vários tipos de aplicativos.

5. Autonomia de Atendimento

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.

6. Apatridia de serviço

Idealmente, os serviços deveriam ser apátridas. Isto significa que os serviços não devem reter informações de um estado para outro. Isso precisaria ser feito no aplicativo cliente. Um exemplo pode ser um pedido feito em um site de compras. Agora você pode ter um serviço 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 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 deverá ser feita pelo serviço web. Em vez disso, isso precisa ser feito pelo aplicativo da web.

7. Descoberta do serviço

Os serviços podem ser descobertos (geralmente em um registro de serviços). Já vimos isso no conceito do UDDI, que realiza um registro que pode conter informações sobre o serviço web.

8. Composição de serviços

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 sim dividir o serviço em módulos, cada um com uma funcionalidade de negócios separada.

9. Interoperabilidade de serviços

Os serviços devem utilizar padrões que permitam que diversos assinantes utilizem o serviço. Em serviços web, padrões como XML e a comunicação por HTTP é usada para garantir que esteja em conformidade com este princípio.