DSD 24 WEB SERVICE CONCEITOS (1)

Prévia do material em texto

Professor Hildeberto Melo
SISTEMAS DISTRIBUÍDOS
WEB SERVICE
Apresentação
Técnico em Desenvolvimento de Sistemas - Ibratec, Recife-PE
Bacharel em Sistemas de Informação – FIR, Recife-PE
Especialista em Docência no Ensino Superior – Faculdade Maurício de Nassau, Recife-PE
Mestre em Ciência da Computação – UFPE/CIN, Recife-PE
Currículo Lattes http://lattes.cnpq.br/0759508594425296)
Homepage https://sites.google.com/site/hildebertomelo/
Disciplinas Lecionadas
Desenvolvimento de Aplicações Desktop
Programação Orientada a Objetos
Estrutura de Dados
Tecnologia da Informação & Sociedade
Sistemas Operacionais
Sistemas Distribuídos
Introdução a Informática
Lógica de Programação
Informática Aplicada a Saúde
Banco de Dados
Projeto de Banco de Dados
Análise de Projetos Orientado a Objetos
Programação Cliente Servidor
Linguagens de Programação: C, C#, Pascal, PHP, ASP, Delphi, Java, JavaScript
Programação WEB
Serviços
O conceito de serviços em uma aplicação existe faz algum tempo. Serviços, assim como componentes, são considerados blocos de construção independentes, os quais coletivamente representam um ambiente de aplicação. No entanto, diferente de componentes tradicionais, serviços têm algumas características únicas que lhes permitem participar como parte de uma arquitetura orientada a serviços.
Serviços
Uma destas características é a completa autonomia em relação a outros serviços. Isto significa que cada serviço é responsável por seu próprio domínio, o que tipicamente significa limitar seu alcance para uma função de negócio específica (ou um grupo de funções relacionadas).
Serviços
Este enfoque de projeto resulta na criação de unidades isoladas de funcionalidades de negócio ligadas fracamente entre si. Isto é possível por causa da definição de uma estrutura padrão de comunicação. Devido à independência que esses serviços desfrutam dentro desta estrutura, a lógica de programação que encapsulam não tem necessidade de obedecer a nenhuma outra plataforma ou conjunto de tecnologias.
SOA - Arquitetura Orientada a Serviços
SOA significa Service-Oriented Architecture, ou Arquitetura Orientada a Serviços, numa tradução livre.
SOA
O conceito foi proposto pela primeira vez em 1996, no artigo “Service Oriented Architectures” (abril de 1996), escrito pelos pesquisadores Roy Schulte e Yefim Natis do Gartner Group. Eles o apresentaram à partir da análise de experiências de diversos clientes que, na época, utilizavam a tecnologia cliente-servidor (em forte adoção naqueles anos), e que ganhou novamente atenção em virtude das novas possibilidades tecnológicas baseadas em padrões, da demanda crescente por soluções de integração e de relativo insucesso de outras alternativas.
SOA - Definições
SOA é uma abordagem arquitetural corporativa que permite a criação de serviços de negócio interoperáveis que podem facilmente ser reutilizados e compartilhados entre aplicações e empresas.
SOA
Um paradigma para organizar e utilizar capacidades distribuídas que podem estar sob o controla de diferentes domínios de propriedade.
Provê uma maneira uniforme de oferecer, descobrir, interagir e utilizar capacidades para produzir efeitos desejados consistentes com pré-condições e expectativas mensurpáveis. 
SOA
“SOA é uma filosofia de TI que visa facilitar a integração entre sistemas, orientando a criação e a disponibilização de soluções modulares e fracamente acopladas baseadas no conceito de serviços”
Princípios Básicos de SOA
Segue abaixo uma lista com os 8 princípios básicos da Arquitetura Orientada a Serviços.
Serviços são reutilizáveis;
Serviços compartilham um contrato formal;
Serviços possuem baixo acoplamento;
Serviços abstraem a lógica;
Serviços são capazes de se compor;
Serviços são autônomos;
Serviços evitam alocação de recursos por longos períodos;
Serviços devem possuir a capacidade de serem descobertos.
SOA
À partir dessas definições podemos chegar a algumas conclusões à respeito de SOA.
SOA não é uma tecnologia. Há tanto de negócio quanto de tecnologia em SOA. As tecnologias (padrões) que dão suporte a SOA são o que a viabiliza, mas SOA não é uma tecnologia por si só.
SOA não é uma metodologia. Há várias metodologias (processos, ferramentas, métodos de trabalho) que podem ser usados para implantar SOA com sucesso. SOA não é e nem define alguma metodologia.
SOA pode ser considerada uma filosofia arquitetural. SOA é uma linha de pensamento que permeia a implementação de necessidades de negócio, refletida em diretrizes, políticas e metodologias corporativas, não necessariamente restritas à área de TI.
SOA não é algo que se possa comprar ou instalar.
SOA não é um webservice.
SOA não cria nada. Ela apenas sugere, propõe, define.
SOA baseia-se no conceito do uso de serviços atômicos, independentes e com baixo acoplamento.
SOA - Benefícios
São esperados diversos benefícios no uso do SOA. Alguns deles relacionamos abaixo:
Facilidade de Manutenção: mudanças na lógica de negócios (implementação) não afetam aplicações existentes;
Reuso: novas aplicações e processos (consumidores de serviços) podem reaproveitar mais facilmente as funcionalidades existentes;
Flexibilidade: sistemas de back-end e infraestrutura podem ser substituídos com menor impacto;
Resultado: agilidade e redução de custos;
Qualidade: garantia de homogeneidade de processos;
Menor tempo: agilidade na análise de impacto e no desenvolvimento evolutivo de seus sistemas;
Menor custo: redução do custo de manutenção das aplicações;
Controle: conhecimento dos ativos existentes.
SOAP
O protocolo SOAP, abreviação para Simple Object Access Protocol, é uma especificação para a troca de informação entre sistemas, ou seja, uma especificação de formato de dados para envio de estruturas de dados entre serviços, com um padrão para permitir a interoperabilidade entre eles.
SOAP
Seu design parte do princípio da utilização de XMLs para a transferência de objetos entre aplicações, e a utilização, como transporte, do protocolo de rede HTTP.
Os XMLs especificados pelo SOAP seguem um padrão definido dentro do protocolo. Esse padrão serve para que, a partir de um objeto, seja possível serializar o mesmo para XML e, também, deserializá-lo de volta para o formato original.
SOAP
Além do formato dos objetos, nesse protocolo também são definidos os padrões que os serviços SOAP devem seguir, ou seja, a especificação dos endpoints que as implementações de SOAP devem ter.
A serialização de objetos, que acabamos de descrever, tem como objetivo formar uma mensagem SOAP, composta pelo objeto denominado envelope SOAP, ou SOAP-ENV.
Dentro desse envelope existem mais dois componentes: o header SOAP, que possui informações de atributos de metadados da requisição como, por exemplo, IP de origem e autenticação; e o SOAP body, que possui as informações referentes à requisição, como o nome dos métodos que deseja se invocar e o objeto serializado que será enviado como payload da requisição.
SOAP
Envelope: Toda mensagem SOAP deve contê- lo. É o elemento raiz do documento XML. O Envelope pode conter declarações de namespaces e também atributos adicionais como o que define o estilo de codificação (encoding style).Um "encoding style" define como os dados são representados no documento XML.
Header: É um cabeçalho opcional. Ele carrega informações adicionais, como por exemplo, se a mensagem deve ser processada por um determinado nó intermediário (É importante lembrar que, ao trafegar pela rede, a mensagem normalmente passa por diversos pontos intermediários, até alcançar o destino final). Quando utilizado, o Header deve ser o primeiro elemento do Envelope.
Body: Este elemento é obrigatório e contém o payload, ou a informação a ser transportada para o seu destino final. O elemento Body pode conter um elemento opcional Fault, usado para carregar mensagens de status e erros retornadas pelos "nós" ao processarem a mensagem.
LINGUAEGM XML
Para entendermos como funcionam os Web Services primeiramente devemos entender oque é e como funciona o XML, pois ela é utilizada como base tanto para a descrição dos serviços Web quanto para a troca de dados entre eles.
O Xml permite que os usuários ou programadores definam as marcas (etiquetas) que serão utilizadas para descrever os documentos, agregando semântica e estrutura ao seu conteúdo. Os documentos podem então ser utilizados para descrever (estruturas de) dados e informações de maneira simples. Por exemplo, abaixo vamos representar os dados de uma pessoa em XML
XLM
XML
XML descreve, por tanto, a estrutura de um documento (ou estrutura de dados) e seus atributos, utilizando uma abordagem independente de plataforma, compreensível tanto pelo homem quanto pelo computador. Por ser independente de plataforma ele é adotado na web e, portanto, por Web Services para troca de dados. Para manter essa independência e para que os programas não carreguem consigo de maneira estática informações sobre os tipos de dados de um documento criou-se um mecanismo para que essas informações fossem especificadas. Para isso temos um DTD (Document Type Definition) que nos permite definir as marcas que são utilizadas por um documento e quais são os seus tipos e restrições, seguindo, também, uma linguagem independente de plataforma.
WSDL (Web Services Description Language)
WSDL (em português significa Linguagem de Descrição de Serviços Web) é uma linguagem de descrição de serviços Web. A descrição envolve informações críticas como:
O endpoint do serviço
Operações
Tipos de dados necessários a tais operações.
WSDL
Essa descrição é feita em uma linguagem específica que é chamada de WSDL. WSDL é como se fosse um contrato entre o serviço (Web Services) e o seus consumidores. Ele é completamente baseado em XML, sendo assim legível e textual. As etiquetas (ou tags) do WSDL são utilizadas para descrever um serviço. Assim, todo cliente que acessa o WSDL de um Web Service pode conhecer onde ele está localizado e quais são as operações que ele oferece. Portanto, sabemos o que um serviço web precisa receber para funcionar e o que ele devolver após a execução.
WEB SERVICE
Um Web service é um conjunto de métodos acedidos e invocados por outros programas utilizando tecnologias Web.
Segundo, a tradução. Um Web service é utilizado para transferir dados através de protocolos de comunicação para diferentes plataformas, independentemente das linguagens de programação utilizadas nessas plataformas.
Os Web services funcionam com qualquer sistema operativo, plataforma de hardware ou linguagem de programação de suporte Web. Estes transmitem apenas informação, ou seja, não são aplicações Web que suportam páginas que podem ser acedidas por utilizadores através de navegadores Web.
Os Web services permitem reutilizar sistemas já existentes numa organização e acrescentar-lhes novas funcionalidades sem que seja necessário criar um sistema a partir do zero. Assim, é possível melhorar os sistemas já existentes, integrando mais informação e novas funcionalidades de forma simples e rápida.
Como Funciona?
Tendo em conta as operações disponíveis no Web service, a aplicação solicita uma dessas operações. O Web service efetua o processamento e envia os dados para a aplicação que requereu a operação. 
A aplicação recebe os dados e faz a sua interpretação, convertendo-os para a sua linguagem própria.
Se são linguagens diferentes, como conseguem comunicar?
É necessário uma linguagem intermédia que garanta a comunicação entre a linguagem do Web service e o sistema que faz o pedido ao Web service. Para tal, existem protocolos de comunicação como o SOAP (Simple Object Access Protocol) e o REST (Representational State Transfer).
Se são linguagens diferentes, como conseguem comunicar?
O protocolo SOAP utiliza XML para enviar mensagens e, geralmente, serve-se do protocolo HTTP para transportar os dados. Associado ao protocolo SOAP está o documento WSDL (Web Service Definition Language) que descreve a localização do Web service e as operações que dispõe. Além disso, fornece a informação necessária para que a comunicação entre sistemas seja possível.
O REST é um protocolo de comunicação mais recente que surgiu com o objetivo de simplificar o acesso aos Web services. Este baseia-se no protocolo HTTP e permite utilizar vários formatos para representação de dados, como JSON (um dos mais utilizados), XML, RSS, entre outros.
Assim, uma das grandes vantagens do REST é a sua flexibilidade, já que não limita os formatos de representação de dados. O protocolo REST é também utilizado quando a performance é importante, uma vez que é um protocolo ágil e com a capacidade de transmitir dados diretamente via protocolo HTTP.
Quais os benefícios dos Web services?
Integração de informação e sistemas: uma vez que o funcionamento do Web service necessita apenas de tecnologia XML/JSON e protocolos HTTP, a comunicação entre sistemas e aplicações é bastante simplificada. Com um Web service é possível trocar informação entre dois sistemas, sem necessidade de recolher informação detalhada sobre o funcionamento de cada sistema. Os Web services permitem ligar qualquer tipo de sistema, independentemente das plataformas (Windows, Linux, entre outras) e linguagens de programação (Java, Perl, Python, etc.) utilizadas.
Quais os benefícios dos Web services?
Reutilização de código: um Web service pode ser utilizado por várias plataformas com diferentes objetivos de negócio. O código do Web service é feito uma vez e pode ser utilizado vezes sem conta por diferentes aplicações.
Quais os benefícios dos Web services?
Redução do tempo de desenvolvimento: é mais rápido desenvolver com Web services, porque os sistemas não são totalmente construídos a partir do zero e facilmente são incluídas novas funcionalidades. O tempo de implementação de sistemas com a utilização de Web services é mais reduzido, sendo uma boa opção no desenvolvimento de software à medida.
Quais os benefícios dos Web services?
Maior segurança: o Web service evita que se comunique diretamente com a base de dados. Assim, a segurança do sistema que fornece os dados está salvaguardada.
Redução de custos: Com a utilização de Web services não é necessário criar aplicações à medida para a integração de dados, algo que pode ser bastante caro. Os web services tiram partido de protocolos e da infraestrutura Web já existente na organização, requerendo por isso pouco investimento.
Web service: uma solução prática
Numa organização coexistem várias aplicações que organizam e trocam dados, muitas vezes, de formas distintas. Assim, nem sempre garantem a comunicação entre sistemas. Por outro lado, é cada vez mais comum a necessidade de trocar dados entre diferentes sistemas, seja dentro de uma organização ou entre organizações.
Uma solução prática e de baixo custo para solucionar a incompatibilidade de sistemas e garantir a sua comunicação são os Web services. Estes permitem ligar diferentes aplicações que integram um sistema, ultrapassando barreiras como o tipo de plataforma ou linguagens de programação utilizadas.
Papéis Web Service
Serviços podem assumir diferentes papéis quando envolvidos em diversos cenários de interação. Dependendo do contexto pelo qual é visualizado, assim como o estado da tarefa rodando no momento, o mesmo web service pode trocar de papéis ou ser designado para múltiplos papéis simultâneos:
Provedor de serviços
Solicitante de serviços
Intermediário
Remetente inicial
Receptor Final
Provedor de Serviços
Agindo como um provedor de serviços, um web service expõe uma interface pública através da qual pode ser chamado por solicitantes do serviço. Um provedor de serviços disponibiliza esta interface publicando uma descrição do serviço. Num modelo cliente-servidor, o provedor de serviço pode ser comparado ao servidor.
O termo “provedor de serviço” pode também ser usado para descrever a organização ou ambiente que hospeda (provê) o web service.
Um provedor de serviço pode também agir como um solicitante de serviço.Por exemplo, um web service pode atuar como um provedor de serviço quando um solicitante de serviço lhe pede para executar uma função. Pode então atuar como um solicitante de serviço quando mais tarde contata o solicitante de serviço original (agora agindo como um provedor de serviço) para solicitar informação de status
Solicitante de Serviço
Um solicitante de serviço é o remetente de uma mensagem web service ou o programa de software solicitando um web service específico. O solicitante de serviço é comparável ao cliente dentro de um modelo cliente-servidor padrão. Solicitantes de serviços são às vezes chamados de consumidores de serviços.
Um solicitante de serviço pode também ser um provedor de serviço. Por exemplo, num modelo de solicitação e resposta, o web service iniciador primeiro age como um solicitante de serviço ao requerer informações do provedor de serviço. O mesmo web service então, faz o papel de um provedor de serviço ao responder à solicitação original.
Intermediário
O papel de intermediário é assumido pelo web service quando ele recebe a mensagem de um solicitante de serviço e a passa adiante para o provedor de serviço. Neste caso, ele pode também agir como um provedor de serviço (recebendo a mensagem) e como um solicitante de serviço (passando adiante a mensagem).
Intermediários podem existir em muitas formas diferentes. Alguns são passivos e simplesmente re-transmitem ou roteam as mensagens, enquanto outros processam ativamente uma mensagem antes de repassá-la. Tipicamente, aos intermediários só é permitido o processamento e modificação do cabeçalho da mensagem. Para preservar a integridade da mensagem, seus dados não devem ser alterados.
Remetente inicial
Como o web service responsável por iniciar a transmissão da mensagem, remetentes iniciais também podem ser considerados solicitantes de serviço. Este termo existe para ajudar a diferenciar o primeiro web service que envia uma mensagem, dos intermediários também qualificados como solicitantes de serviço.
Receptor final
O último Web service a receber uma mensagem é o receptor final. Estes serviços representam o destino final de uma mensagem e também podem ser considerados provedores de serviço.
Interação Web Service
Quando mensagens são passadas entre dois ou mais web services, uma variedade de cenários de interação pode acontecer. A seguir, termos comuns utilizados para identificar e etiquetar estes cenários serão apresentados.
Caminho da mensagem
A rota pela qual a mensagem viaja é o caminho da mensagem. Deve consistir de um remetente inicial e um receptor final e pode conter nenhum, um, ou mais de um intermediários. 
O caminho de transmissão atual percorrido por uma mensagem pode ser dinamicamente determinado por roteadores intermediários. A lógica de roteamento pode ser ativada em resposta à carga de requisitos de balanceamento, ou pode ser baseada nas características da mensagem e outras variáveis lidas e processadas pelo intermediário em tempo de execução. A Figura 6 descreve como uma mensagem é enviada via um ou dois caminhos de mensagem possíveis, tal como é determinado pelo roteador intermediário.
Caminho da mensagem
Caminho da mensagem
Padrão de Troca de Mensagens
Serviços que interagem em um ambiente orientado a serviços tipicamente se enquadram em determinados padrões de troca de mensagens. Padrões típicos incluem:
solicite e responda (request and response);
publique e subscreva (publish and subscribe);
fire and forget - um para um;
fire and forget - um para muitos ou difusão;
O padrão pedido e resposta é o mais comum quando se está simulando intercâmbio de dados síncronizados. Os demais padrões são usados principalmente para facilitar transferência de dados assíncrona.
Perguntas
Referências
https://www.devmedia.com.br/web-services/2873 (acesso em outubro/2019)
https://www.devmedia.com.br/entendendo-os-padroes-de-descricao-de-web-services/28678
https://www.ibm.com/support/knowledgecenter/pt/SS4JE2_7.5.5/org.eclipse.jst.ws.consumption.ui.doc.user/concepts/cwsdlud.html
https://docplayer.com.br/2155912-Conceitos-soap-wsdl-uddi-exemplos-programacao-com-objetos-distribuidos-c-geyer-web-services-1.html
http://blog.iprocess.com.br/2012/10/soa-arquitetura-orientada-a-servicos/