SOA_WEB_SERVICE

Prévia do material em texto

SOA WEB SERVICE 1
SOA WEB SERVICE
SOA - Service Oriented Architecture
SOA consistem em uma coleção de componentes distribuídos que fornecem e 
ou consomem serviços.
A sua implementação impacta de forma significativa no processo de 
desenvolvimento de sistemas distribuídos nas organizações.
A Arquitetura Orientada a Serviço (SOA) está sendo utilizada por uma grande 
quantidade de empresas e organizações nos mais distintos cenários.
Conceitos
A arquitetura orientada a serviços estabelece um modelo arquitetônico que visa 
aprimorar a eficiência, agilidade e a produtividade de uma empresa, 
posicionando os serviços como os principais meios para que a solução lógica 
seja representada no suporte à realização dos objetivos estratégicos associados 
à computação orientada a serviços (ERL, 2009).
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.
O objetivo do SOA é estruturar grandes sistemas distribuídos com base nas 
abstrações de regras e funções de negócio
Serviços
A arquitetura orientada a serviço objetiva abstrair a realidade, concentra-se nos 
aspectos do negócio
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.
Interoperabilidade
SOA WEB SERVICE 2
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
Esse é 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
O que é um serviço
É uma função do sistema computacional construído de tal forma que possa ser 
facilmente vinculado a outros componentes de software
Encapsula uma função do negócio reutilizável
Serviços são independentes da implementação
Serviços são fracamente interligados
Caracteristicas
Não existem herança ou dependência entre os serviços;
Separação clara entre fornecedor (provider) e consumidor (consumer);
Foco na definição dos contratos.
Acoplamento e coesão
Acoplamento: é a medida de interdependência entre os módulos
Coesão: é a medida de intensidade de associação funcional dos elementos.
SOA WEB SERVICE 3
Objetivos
Foco na melhoria e agilidade de negócios
Reutilização de componentes em forma de serviços
Cria aplicações com base numa fundação de componentes
Beneficios do SOA
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
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 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
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.
Desafios 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.
SOA WEB SERVICE 4
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.
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
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.
SOA é um estilo arquitetural e para implementá-lo podem ser 
usadas diversas tecnologias tais como: 
•RMI (Remote Method Invocation); 
•CORBA (Common Object Request Broker Architecture), 
•DCOM (Distributed Component Object Model) 
•Web Services e Web Services RESTFul.
Web Services 
Um serviço Web pode ser descrito como o serviço que fornece uma interface de 
serviço que permite aos clientes interagirem com servidores de uma maneira 
mais geral do que acontece com os navegadores Web
Os clientes acessam operações de um serviço Web por meio de requisições e 
respostas formatadas em Extensible Markup Language (XML) e, normalmente, 
SOA WEB SERVICE 5
transmitidas por HTTP.
Caracteristicas
Web services podem ser publicados, localizados e invocados através da 
Internet
Independência: 
- de linguagem de programação 
- de sistema operacional
Padrões
Principais padrões utilizados na implementação de Web Services:
1. Soap
2. Rest
3. GraphQL
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)
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.
SOA WEB SERVICE 6
Ele define um esquema para uso da XML para representar o conteúdo de 
mensagens de requisiçãoresposta, 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
Um documento WSDL descreve: 
1. Interface
2. Ponto de acesso
3. Protocolo de comunicação
4. Documento XML que contem informações necessaria para o cliente utilizar WS
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
O UDDI provê um método padronizado para a publicação e descoberta de 
informações, permitindoque as empresas tanto publiquem como encontrem 
Web Services.
Representational State Transfer - REST
Conceito
SOA WEB SERVICE 7
A arquitetura Representational State Transfer (REST), foi proposta por Roy 
Fielding em 2000 em 
sua tese de doutorado e pode ser descrita como um conjunto de princípios 
arquiteturais que podem ser utilizados para o desenvolvimento de serviços web 
e que utilizam o protocolo HTTP para realizar as trocas de mensagens
Web Services RESTful
Para dizermos que um serviço Web segue os princípios arquiteturais que 
permeiam REST, o serviço tem que estar em conformidade com um conjunto de 
restrições. Se atender essas restrições ele é um serviço Web RESTful
Restrições
Cliente-Servidor: 
Essa restrição está associada a separação deinteresses, 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. A resposta a uma requisição do servidor pode ser:
cacheable (sujeito à utilização do cachê): Se uma resposta for marcada 
como cacheable, então ela será reutilizada como resposta em futuras 
requisições equivalentes, permitindo que o servidor fique mais livre, e 
SOA WEB SERVICE 8
portanto, mais escalável, haja vista que algumas interações poderão ser 
eliminadas por completo o que melhora a eficiência e performance de 
acesso a recursos percebido pelo usuário.
noncacheable (não sujeito a utilização do cache)
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
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. 
Com o objetivo de obter uma interface uniforme, REST define quatro requisitos 
de interface: 
1. Identificação dos recursos: Na arquitetura REST, cada recurso deve possuir 
um identificador universal denominado Uniform Resource Identifier (URI). Que é 
definido como uma sequência de caracteres que identificam um recurso físico 
ou abstrato [RFC 3986]. E são utilizados para descoberta de recursos e serviços
2. Representação de recursos: Os recursos devem ser manipulados a partir de 
suas representações, uma vez que elas podem estar representadas em 
formatos diferentes formatos, tais como: JSON, XML,PDF, texto puro, etc. É 
importante frisar que uma aplicação REST não transmite o recurso 
efetivamente, mas sim a sua uma representação, em um formato pré-
acordado entre o cliente e o servidor;
3. Mensagem auto descritivas: Os recursos são dissociados da sua 
representação, haja vista que o seu conteúdo pode que ser acessado em 
em formatos diferentes.
4. Utilização de hipermídia para estado da aplicação: Neste caso, as 
representações de recursos obtidas em uma aplicação REST devem 
possuir hiperlinks que permitam a navegação do cliente pelos recursos. 
Uma vez que o servidor não pode armazenamento de qualquer tipo de 
estado.
SOA WEB SERVICE 9
Serviços Web RESTful e o protocolo HTTP
O protocolo HTTP é o padrão utilizado na arquitetura REST para promover a 
comunicação entre o cliente e o servidor
Isso se dá pela manipulação dos recursos utilizando os métodos HTTP: GET, 
POST, PUT, DELETE e adicionalmente os métodos HEADER e OPTIONS. 
Esses métodos são descritos a seguir:
Interação por métodos 
Para interagir com as URL’s, os métodos HTTP são utilizados. 
A regra de ouro para esta interação e que URL’s são substantivos, e métodos 
HTTP são verbos. Isto quer dizer que os métodos HTTP são os responsáveis 
por provocar alterações nos recursos identificados pelas URI’s. 
Estas modificações são padronizadas, de maneira que: 
• GET - recupera os dados identificados pela URL; 
• POST - cria um novo recurso; 
• PUT - atualiza um recurso; 
• DELETE - apaga um recurso
REST
REST segue padrões W3C/IETF3 bem conhecidos tais como (HTTP, XML, URI, 
MIME).
Uma vantagem na utilização de Web RESTful é a possibilidade de otimização 
de desempenho de web services, uma vez que podem utilizar formatos de 
mensagem mais leves, como por exemplo, o JavaSript Objetc Notation(JSON)
JSON
 JSON e 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.
SOA WEB SERVICE 10
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
GraphQL
GraphQL é uma linguagem de consulta de código aberto, utilizada para a 
manipulação de dados em APIs — Application Programming Interface — e 
contém um serviço de runtime, que é utilizado para processar as consultas 
efetuadas.
O GraphQL foi desenvolvido para tornar as APIs mais rápidas, flexíveis e 
intuitivas para os desenvolvedores. Ainda é possível implantá-lo em um 
ambiente de desenvolvimento integrado (IDE) conhecido como GraphiQL.
Vantagens
Declarative Data Fetching 
O GraphQL abraça um conceito chamado de declarative data fetching em 
suas consultas, o cliente que irá fazer a requisição tem o poder de 
selecionar qual a resposta que quer receber como as entidades, campos e 
relacionamentos utilizando apenas uma consulta.
Sem Over-fetching com GraphQL 
Não existe over-fetching, “retorno de dados não desejados”, com o 
GraphQL, com ele um cliente mobile tem o poder de escolher quais campos 
quer receber de acordo com a tela que vai ser apresentada.
Fonte Única de Verdade (Single Source of Truth) 
O schema do GraphQL funciona como uma fonte única de verdade para 
aplicações que o utilizam, ele provê de maneira central um lugar onde todas 
as informações disponíveis são 
apresentadas
Linguagem Fortemente Tipada 
O GraphQL é uma linguagem de consulta fortemente tipada e suas 
consultas são escritas utilizando o GraphQL Schema Definition Language 
SOA WEB SERVICE 11
(SDL). 
Isso faz com que as consultas do GraphQL sejam menos propensas a 
erros, podendo ser validadas por IDEs com suporte a auto complementar e 
validações.
Desvantagens
Curva de Aprendizagem 
Desenvolvedores acostumados com as APIs REST terão que enfrentar uma 
certa curva de aprendizado com o GraphQL. 
 
O GraphQL direciona muito do trabalho de consulta de dados para o 
servidor, o que aumenta a complexidade para os desenvolvedores. 
Dependendo de como for implementado, o GraphQL talvez exija estratégias 
para o gerenciamento da API diferentes das aplicadas às APIs REST, 
principalmente em relação aos limites de taxas e preços.
O armazenamento em cache é mais complexo do que na arquitetura REST.
Os profissionais responsáveis pela manutenção da API terão a tarefa extra 
de escrever um esquema do GraphQL que possa ser submetido à 
manutenção