Service Oriented Architecture

Service Oriented Architecture

1. Conceitos

   • SOA pode ser caracterizada como uma arquitetura corporativa onde serviços podem ser criados, reutilizados e facilmente compartilhados entre aplicações. Neste caso as funcionalidades de um sistema são decompostas em serviços interoperáveis o que permite a integração efetiva entre aplicações.
   • Serviços
     • A arquitetura orientada a serviço objetiva abstrair a realidade, concentra- se nos aspectos do negócio (JOSUTTIS, 2007). Isso possibilita que sistemas possam ser construídos em plataformas diferentes sem que existam problemas, pois elas poderão se integrar de forma flexível por meio dos serviços disponibilizados na arquitetura.
     • Encapsula uma função do negócio reutilizável; Serviços são independentes da implementação; Serviços são fracamente interligados;
     • Separação clara entre fornecedor (provider) e consumidor (consumer).
   • Interoperabilidade
     • Atualmente uma empresa pode ter uma grande heterogeneidade de sistemas, a integração entre esses sistemas dar-se o nome de interoperabilidade e representa um objetivo fundamental da orientação a serviços, que estabelece uma base para a realização de outros objetivos e benefícios estratégicos.
   • Baixo acoplamento
     • É um conceito vital para o funcionamento de um sistema distribuído. Haja vista que ele determina que diferentes partes e funcionalidades de um sistema sejam independentes umas das outras, dessa maneira, alterações ou problemas em certas partes do sistema não trarão grandes consequências para o resto do sistema, trazendo grandes benefícios como escalabilidade, flexibilidade e tolerância a falhas.

2. Vantagens

   • • Baixo acoplamento entre aplicações; • Alta interoperabilidade entre plataformas tecnológicas; • Alta reutilização de regras de negócio; • Resposta mais rápida nos processos de negócio; • Facilidade em executar testes nos serviços.

3. Objetivos

   • • Foco na melhoria e agilidade de negócios; • Reutilização de componentes em forma de serviços; • Alinhar o TI as estratégias de negócio; • Cria aplicações com base numa fundação de componentes; • Integrar aplicações.

4. Princípios de Design

   • Acoplamento de Serviços: Acoplamento é um termo bastante difundido na área de TI - é sinônimo de dependência. Esse acoplamento pode ser alto (forte) ou baixo (fraco).
   • Abstração de Serviço: Abstração significa não deixar pública quaisquer informações sobre um serviço que não sejam absolutamente necessárias para quem efetivamente usar esse serviço. A abstração é fundamental para garantir o reuso.
   • Capacidade de Reuso de Serviço: Este é um dos princípios que talvez mais esteja associada a SOA. Quanto mais genérico o Serviço maior a probabilidade de reutilização. A Reutilização é fortemente enfatizada na orientação a serviços, tanto assim, que se torna uma parte essencial da análise típica de serviços e processos de design, e também é a base para os modelos de serviços essenciais.
   • Contrato de Serviços: são o foco do design de serviço, porque regem praticamente tudo que é feito pelos serviços. Sendo assim, todo serviço deve possuir um contrato entre o requisitante e o provedor deste serviço.
   • Autonomia de Serviço: A autonomia representa a capacidade de se autogovernar, em outras palavras e a capacidade que um serviço tem de funcionar independentemente. Logo quanto maior for a autonomia de um serviço, mais fácil será sua manutenção e evolução.
   • Independência de Estado de Serviço O princípio da independência de estado do serviço enfatiza a necessidade de reduzir ou eliminar o consumo de recursos do sistema, em razão de processamento desnecessário do gerenciamento de estado.
   • Visibilidade do Serviço: Este principio refere-se a capacidade que um serviço tem de ser descoberto e estar visível. Um contrato formal padronizado evita que novos requerimentos resultem em Serviços redundantes. Uma arquitetura orientada a serviços deve possuir formas de facilitar o descobrimento dos Serviços ofertados por meio de Diretórios e Registros.
   • Composição de Serviços: O princípio de composição de serviços está intimamente associado à capacidade de reuso de serviços, uma vez que a composição pode ser vista como uma forma de reuso.

5. Benefícios de Adoção

   • Aumento do retorno sobre o investimento (ROI) - Os serviços são prestados e vistos como ativos de TI e espera-se que com a adoção da arquitetura o retorno seja maior que o valor gasto na sua implementação.
   • Menor tempo de resposta frente às mudanças: Novos e mudanças nos requisitos de negócios podem ser preenchidas mais rapidamente através da criação de um ambiente em que as soluções possam ser criadas e ou ampliadas com esforço menor, por meio da reusabilidade e interoperabilidade nativa dos serviços existentes.
   • Aumento do alinhamento entre Negócios e Tecnologia: Alguns serviços são projetados com um contexto funcional voltada para o negócio, o que lhes permitem evoluir conjuntamente.
   • Flexibilidade: Um ambiente orientado a serviços tem que ser baseado em um modelo arquitetônico que permita a organização evoluir em conjunto com o negócio sem ser seja limitado devido a problemas tecnológicos de ferramentas proprietárias.
   • Aumento da Interoperabilidade: Serviços são projetados para serem naturalmente compatíveis de forma que possam ser efetivamente montados e reconfigurados quando ocorrerem mudanças nos requisitos de negócios.
   • Redução da carga na área de TI: Ao se adotar SOA a empresa como um todo é simplificada o que permite que ela possa oferecer serviço a um custo menor, isso ocorre, pois os serviços podem ser reusáveis e reaproveitados em inúmeras circunstâncias.
   • Desafios
     • Disponibilidade: A disponibilidade é um desafio para qualquer aplicação distribuída, não é diferente para as Arquiteturas Orientadas a Serviço. Ao se adotar SOA devemos sempre dimensionar quais e quantos serão os usuários que consumirão os serviços, verificando principalmente como a oferta de serviços implicará no desempenho da arquitetura.
     • Custo: o custo para o desenvolvimento de uma Arquitetura Orientada a serviços é relativamente alto. Isso ocorre, pois o processo de reengenharia das arquiteturas existentes é usualmente um processo demorado, que consome recursos humanos e financeiros. Logo, é necesário que seja realizada uma análise do custo e do benefício antes da adoção de SOA.
     • Segurança: a segurança é um desafio em SOA da mesma forma que é para qualquer sistema distribuído. Isso ocorre devido a grande interoperabilidade que arquitetura proporciona.
     • Falta de conhecimento na implementação SOA: o conceito de SOA tem sido constantemete lembrado por muitas instituições. Porém sua implantação não é uma tarefa trivial, muito pelo contrário, pode ser bem complexa e requer pessoal especializado.

6. Web Service

   • XML: XML é uma linguagem de marcação recomendada pela W3C para a criação de documentos sendo amplamente utilizada em Serviços Web. Ela é composta por tags que podem ser determinados livremente pelo usuário em seu documento XML, o que não ocorre na HTML (HyperText Markup Language) que também possui tags predefinidas.
   • Simple Object Accesss Protocol: SOAP é um protocolo de transporte que é responsável pela troca de mensagens entre aplicações em ambientes distribuídos e descentralizados, ele é projetado para permitir tanto interação cliente-servidor como interações assíncronas pela Internet. Ele define um esquema para uso da XML para representar o conteúdo de mensagens de requisição-resposta, assim como um esquema para a comunicação de documentos
   • WSDL: O Web Services Description Language (WSDL) é uma linguagem para descrição de serviços escrita em XML o que permite que as informações possam ser melhor entendidas em qualquer lado da comunicação.
   • UDDI: UDDI é um componente importante da arquitetura de Web Services, sendo formado por um serviço de diretório que armazena descrições de serviço. Esse serviço obedece ao padrão integração, descoberta e descrição universal. Além disso, ele prescreve o layout de um banco de dados que contém descrições de serviços que permitirão a clientes de serviços web procurar serviços relevantes

7. REST

   • Serviços Web RESTfull
     • Restrições
       • •Cliente-Servidor: Essa restrição está associada a separação de interesses, que é o princípio por trás das restrições da arquitetura cliente-servidor. Nela procura-se separar as preocupações relacionadas à interface do usuário das preocupações de armazenamento de dados. Isso permite que os componentes possam evoluir de forma independente melhorando a portabilidade e a escalabilidade das aplicações.
       • •Stateless: Diz respeito à interação entre cliente e servidor. Nesse caso, a comunicação deve ser realizada sem que haja o armazenamento de qualquer tipo de estado no servidor. Sendo assim, toda informação de estado deve ser conhecida somente pelo cliente.
       • •Cache: A utilização do cachê, tem a finalidade de diminuir o impacto da desvantagem ocasionada pela redução de performance.
       • Sistema em camadas: Essa restrição caracteriza-se pela divisão do sistema em camadas hierárquicas, restringindo a visualização dos componentes participantes de forma que cada componente só possa ver a camada com a qual esteja interagindo diretamente. Ao restringir a visibilidade de um sistema a uma única camada, torna-se possível delimitar a complexidade do sistema e promover a independência de cada uma das camadas. Essa separação permite que o sistema seja mais robusto e resistente a erros.
       • Code-On-Demand: Dentre o conjunto restrições propostas pelo estilo REST, esta é aquela que permite a opção de baixar e executar diretamente códigos no lado cliente, sendo opcional. Com isso, busca-se obter extensibilidade e simplificar o cliente. No entanto, isso também reduz a visibilidade.
       • Interface Uniforme: A principal característica que diferencia o estilo arquitetural REST de outros utilizados em rede é a ênfase quanto ao uso de uma interface uniforme entre os componentes. Aplicando o princípio de generalização de engenharia de software à interface dos componentes, a arquitetura é simplificada e a visibilidade da interações é melhorada. Contudo, esta generalização pode diminuir a eficiência do sistema, devido à aplicação não poder transmitir a informação num formato especifico de acordo com a sua necessidade.
   • JSON
     • JSON é uma sigla para JavaScript Object Notation. É uma linguagem de marcação criada por Douglas Crockford e descrito na RFC 4627, e serve como uma contrapartida a XML. Vantagem em relação o XML, tamanho reduzido e acaba tendo uso mais propício em cenários onde largura de banda (ou seja, quantidade de dados que pode ser transmitida em um determinado intervalo de tempo) e um recurso critico.