Aula 23: Web Services (I)

Transcrição

1 Aula 23: Web Services (I) Diego Passos Universidade Federal Fluminense Técnicas de Projeto e Implementação de Sistemas II Diego Passos (UFF) Web Services (I) TEPIS II 1 / 30

2 Web Services: Introdução Serviços oferecidos via web. Arquitetura cliente-servidor. Cliente requisita serviços. Servidor envia respostas. Utilizam protocolo HTTP para comunicação. Embora outros protocolos, como SMTP, também possam ser usados. Permitem a interação entre sistemas heterogêneos. Em termos de linguagem, plataforma, frameworks. Diego Passos (UFF) Web Services (I) TEPIS II 2 / 30

3 Web Services: Introdução (II) O uso de protocolos de comunicação simples como o HTTP permite grande portabilidade aos Web Services. Protocolos de fácil implementação. Implementações prontas em várias plataformas. Diversas linguagens. Além do protocolo de comunicação, Web Services empregam também uma linguagem para as requisições e respostas. Idealmente, esta linguagem deve ser portável, universal. Características similares às do protocolo de comunicação. Em geral, opta-se por XML. Mas há alternativas, como o JSON. Diego Passos (UFF) Web Services (I) TEPIS II 3 / 30

4 Web Services: Introdução (III) Os Web Services são uma forma de computação distribuída. Podem, a princípio, ser usados para distribuir trabalho entre várias unidades computacionais. Uso mais comum, no entanto, é na integração de sistemas já existentes. Sistemas simples fornecem serviços pequenos de domínios específicos. Sistemas mais complexos são construídos com base nestes serviços básicos. Requisitam computações ou informações de forma distribuída. Complementam estas informações com computações próprias. Diego Passos (UFF) Web Services (I) TEPIS II 4 / 30

5 Web Services: Introdução (IV) Pode-se pensar em um Web Service como uma API. Disponibiliza várias funções/métodos computacionais. Determina o conjunto e tipo dos parâmetros a serem especificados. Determina o tipo de retorno. Cliente segue as especificações para obter respostas. Mas os Web Services agregam mais que uma simples API. Eles oferecem uma infraestrutura computacional para executar a tarefa. Em geral, eles têm acesso a bases de dados necessárias para a computação requisitada. Diego Passos (UFF) Web Services (I) TEPIS II 5 / 30

6 Web Services: Introdução (V) Exemplo de Web Service: QPX. Web Service para busca de opções de voo. Fornece uma API bastante simples: um único método, para busca. Parâmetros para o método são especificados através de uma linguagem padronizada (JSON). Resposta também é formatada na mesma linguagem. Comunicação entre cliente e servidor é encapsulada no protocolo HTTP. Mais que a API, no entanto, o QPX é também a implementação e a infraestrutura. Computação em si é feita nos servidores da Google. Estes servidores (e não o cliente) têm acesso a bases de dados necessárias à computação. Informações sobre os voos. Diego Passos (UFF) Web Services (I) TEPIS II 6 / 30

7 Web Services: Arquitetura Protocolo de Comunicação Requisição (Linguagem Padronizada) Cliente Servidor Protocolo de Comunicação Resposta (Linguagem Padronizada) Diego Passos (UFF) Web Services (I) TEPIS II 7 / 30

8 Web Services: Arquitetura (II) Note que o conceito dos Web Services é muito simples. E sua arquitetura, como consequência, também. A questão, portanto, passa a ser a escolha de: Protocolo de comunicação. Linguagem de representação dos dados. Requisição e resposta. É uma questão importante já que idealmente os Web Services deveriam prover interoperabilidade e portabilidade. Diego Passos (UFF) Web Services (I) TEPIS II 8 / 30

9 JDBC: Arquitetura (III) Embora haja raras exceções, os Web Services são tipicamente baseados em HTTP. Os detalhes podem variar, no entanto. Qual método (GET, POST,... ) usar. Cabeçalhos específicos. HTTPS vs. HTTP. O maior problema está na especificação da linguagem para representação dos dados. Embora haja um padrão: SOAP. Diego Passos (UFF) Web Services (I) TEPIS II 9 / 30

10 Web Services: Tipos Atualmente, os Web Services podem ser classificados em dois grandes grupos: Big Web Services (também conhecidos como Arbitrary Web Services). RESTfull Web Services. Os Big Web Services seguem uma especificação padronizada pelo W3C. Especificação complexa que exige a criação e gerência de vários artefatos. Os RESTfull Web Services seguem apenas uma filosofia comum. Não há um padrão formal que os defina. Embora a industria pareça estar convergindo para algumas práticas comuns. De toda forma, são considerados bem mais simples que os Big Web Services. Diego Passos (UFF) Web Services (I) TEPIS II 10 / 30

11 Web Services: Tipos (II) Ambos os tipos de Web Services são hoje contemplados nas APIs disponíveis no J2EE. JAX-WS e JAX-RS. As APIs permitem que, de forma relativamente fácil, criemos Web Services. Tanto do tipo RESTfull, quanto do tipo Big. No caso dos Big Web Services, a API também dá suporte a clientes. Não ocorre na API do tipo RESTfull. Falta de padronização não permite. Diego Passos (UFF) Web Services (I) TEPIS II 11 / 30

12 Web Services: Objetivo da Disciplina Nesta disciplina, teremos foco no uso das APIs JAX-WS e JAX-RS para criação e disponibilização de Web Services. Veremos também exemplos de clientes. Discutiremos também o funcionamento interno dos Big Web Services. Protocolo SOAP. Padrão WSDL. Diego Passos (UFF) Web Services (I) TEPIS II 12 / 30

13 Big Web Services: Visão Geral Os Big Web Services são o padrão oficial para os Web Services. Padrão definido pelo W3C. Segundo o W3C: Web Services são sistemas de software projetados para suportar interação entre máquinas de forma interoperável através de uma rede. Possuem uma interface descrita em um formato que é processável por computadores (WSDL). Outros sistemas interagem da forma descrita através de mensagens SOAP. Tipicamente, mensagens SOAP são encapsuladas no protocolo HTTP. O SOAP formata suas mensagens com base na linguagem XML. Diego Passos (UFF) Web Services (I) TEPIS II 13 / 30

14 Big Web Services: Visão Geral (II) Note que há muitos componentes envolvidos no funcionamento dos Big Web Services. WSDL, SOAP, XML, HTTP. De forma simplificada, para implementar um Big Web Service, são necessários os seguintes elementos: O software que roda no servidor e realiza o serviço desejado (agnóstico a linguagem ou tecnologia). A interface do serviço (linguagem WSDL). Servidor HTTP capaz de extrair mensagens SOAP e redirecioná-las para o serviço necessário. E realizar a operação inversa para as respostas. Implementação do protocolo SOAP para extrair parâmetros da requisição e chamar o método correspondente. E realizar a operação inversa para as respostas. Diego Passos (UFF) Web Services (I) TEPIS II 14 / 30

15 Big Web Services: WSDL Acrônimo para Web Services Description Language. Formato baseado em XML para descrição de um Web Service. Descreve um Web Service em termos de: Como o serviço pode ser chamado. Quais parâmetros espera (e em qual formato). Qual o tipo de retorno (e em qual formato). Onde o serviço está localizado. O formato tem o objetivo de ser machine-readable. Pode ser interpretado automaticamente por computadores. Diego Passos (UFF) Web Services (I) TEPIS II 15 / 30

16 Big Web Services: WSDL (II) De forma abstrata, o WSDL pode ser entendido como o equivalente das assinaturas de métodos em uma linguagem. Exemplo (em C): Arquivo de cabeçalho (.h) inclui conjunto de assinaturas de funções. Nome, tipo de retorno, lista de parâmetros. Em um arquivo fonte (.c), referenciamos o cabeçalho e usamos as funções. A partir das assinaturas, compilador pode checar chamadas. A função chamada existe? O número de parâmetros está correto? Os tipos são compatíveis? Como organizá-los na pilha? O tipo de retorno é compatível? Arquivo WSDL serve ao mesmo propósito, mas as chamadas são feitas para serviços remotos via web. Diego Passos (UFF) Web Services (I) TEPIS II 16 / 30

17 Big Web Services: Componentes do WSDL Especificação mudou ligeiramente na versão 2.0. Usaremos a versão 2.0 neste curso. Arquivo dividido entre seções abstrata e concreta. Seção abstrata define tipos, interfaces, operações, parâmetros, tipos de retorno,... Seção concreta define bindings, serviços, endpoints,... (Fonte: Wikipedia) Diego Passos (UFF) Web Services (I) TEPIS II 17 / 30

18 Big Web Services: Componentes do WSDL (II) Os tipos são a declaração mais básica do WSDL. Estabelecem a estrutura dos dados trocados na interação com o Web Service. Tanto na passagem de parâmetros, quanto na recepção de resultados. Utilizam o XML Schema. As interfaces são análogas às interfaces das linguagens de programação. Descrevem as operações disponibilizadas pelo Web Service. Conjunto de uma ou mais operações. As operações são listadas dentro das interfaces e contém: Nome. Parâmetros de entrada (referenciam os tipos definidos anteriormente). Saídas (referenciam os tipos definidos anteriormente). Diego Passos (UFF) Web Services (I) TEPIS II 18 / 30

19 Big Web Services: Componentes do WSDL (III) Os bindings ligam interfaces a protocolos. Determinam que uma determinada interface está disponível para acesso via um determinado protocolo. Embora o SOAP seja o padrão, WSDL suporta outros. Também determina características específicas do protocolo (e.g., RPC ou Document). Bindings também devem especificar quais operações da interface estão disponíveis. Um binding pode escolher não disponibilizar todas as operações de uma interface. Finalmente, os serviços fazem a ligação entre bindings e endpoints. Os endpoints são os endereços que dizem como o serviço pode ser acessado. Tipicamente URLs. Um serviço é composto por um ou mais endpoints. Cada endpoint em um serviço está associado a um binding. Diego Passos (UFF) Web Services (I) TEPIS II 19 / 30

20 Big Web Services: Exemplo de Arquivo WSDL <?xml version="1.0" encoding="utf-8"?> <description xmlns=" xmlns:tns=" xmlns:whttp=" xmlns:wsoap=" targetnamespace=" <types> <xs:schema xmlns:xs=" xmlns=" targetnamespace=" <xs:element name="request">... </xs:element> <xs:element name="response">... </xs:element> </xs:schema> </types> <interface name="interface1"> <fault name="error1" element="tns:response"/> <operation name="get" pattern=" <input messagelabel="in" element="tns:request"/> <output messagelabel="out" element="tns:response"/> </operation> </interface> <binding name="soapbinding" interface="tns:interface1" type=" wsoap:protocol=" wsoap:mepdefault=" <operation ref="tns:get" /> </binding> <service name="service1" interface="tns:interface1"> <endpoint name="soapendpoint" binding="tns:soapbinding" address=" </service> </description> Diego Passos (UFF) Web Services (I) TEPIS II 20 / 30

21 Big Web Services: Arquivo WSDL É responsabilidade do Web Service prover o arquivo WSDL. Mas não é necessário criá-lo manualmente. Há ferramentas capazes de fazer isso a partir dos fontes que implementam o serviço. Na JAX-WS, a partir de um WSDL, o cliente pode pedir que a API crie uma camada de software que irá intermediar o Web Service. Tornará a utilização deste quase transparente ao cliente. Depois de algumas configurações iniciais, o cliente poderá acessar o Web Service como um objeto local. A JAX-WS também permite o uso de um Big Web Service sem um WSDL. Neste caso, o cliente precisa, programaticamente, especificar as configurações do serviço. Exemplos: endereço do Web Service, nome do método, tipos dos parâmetros e de retorno, etc. Diego Passos (UFF) Web Services (I) TEPIS II 21 / 30

22 Big Web Services: Arquivo WSDL (II) Uma vez criado, como o cliente obtém o arquivo WSDL de um Web Service? O padrão especificado pela W3C prevê a existência de um UDDI. Universal Description, Discovery and Integration. Terceira parte conhecida pelo cliente. Armazena um repositório de WSDL descrevendo Web Services. Cliente contacta o UDDI e requisita um determinado tipo de serviço. UDDI responde com o WSDL de um Web Service adequado. Nesta disciplina, no entanto, abstrairemos esta arquitetura. Supomos que o WSDL está disponível de alguma forma para o cliente. Em certos casos, supomos que o cliente não tem o WSDL, mas conhece as especificidades do serviço. Diego Passos (UFF) Web Services (I) TEPIS II 22 / 30

23 Big Web Services: SOAP Acrônimo para Simple Object Access Protocol. Protocolo para transferência de dados estruturados via rede. Padroniza a representação de estruturas de dados potencialmente complexas. Independente de linguagem de programação ou tecnologia. Utiliza um formato de mensagem baseado em XML. Precisa ser encapsulado em um protocolo de transporte. Aqui, transporte não se refere à camada de transporte na pilha TCP/IP. Mas sim a um protocolo (geralmente na camada de aplicação) como HTTP ou SMTP. Este protocolo é responsável por tarefas como endereçamento e a transmissão em si das mensagens. Base dos Big Web Services. Diego Passos (UFF) Web Services (I) TEPIS II 23 / 30

24 Big Web Services: SOAP (II) O padrão SOAP é composto por três partes: A definição de um envelope, contendo metadados que especificam como a mensagem é estruturada. Regras de codificação que determinam como representar tipos de dado das aplicações. Convenção para representar chamadas de funções e seus retornos. Idealmente, deseja-se que o SOAP apresente as seguintes características: Extensibilidade. Neutralidade (em relação ao protocolo de transporte). Independência (em relação ao modelo de programação). Diego Passos (UFF) Web Services (I) TEPIS II 24 / 30

25 Big Web Services: Uma Mensagem SOAP É formatada como um documento XML composto pelos seguintes elementos: Envelope: identifica o documento XML como uma mensagem SOAP. Header: contém cabeçalhos com metadados relevantes (opcional). Body: contém os dados de chamada de métodos ou valores de retorno. Fault: contém informações sobre possíveis erros durante o processamento da mensagem (opcional). A opção por utilizar documentos XML tem vantagens e desvantagens: Evita problemas de interoperabilidade (e.g., problemas com o endianness). Facilita a depuração das mensagens geradas. Tende a ser mais lento que formatos binários especializados. Tende a adicionar muito mais overhead. Diego Passos (UFF) Web Services (I) TEPIS II 25 / 30

26 Big Web Services: Uma Mensagem SOAP (II) Exemplo: POST /InStock HTTP/1.1 Host: Content-Type: application/soap+xml; charset=utf-8 Content-Length: 299 SOAPAction: " <?xml version="1.0"?> <soap:envelope xmlns:soap=" <soap:header> </soap:header> <soap:body> <m:getstockprice xmlns:m=" <m:stockname>ibm</m:stockname> </m:getstockprice> </soap:body> </soap:envelope> Diego Passos (UFF) Web Services (I) TEPIS II 26 / 30

27 Big Web Services: SOAP e JAX-WS Na prática, como desenvolvedores de clientes de Web Services raramente precisamos nos preocupar com o SOAP. Aplicações cliente raramente constroem diretamente as mensagens SOAP. Há bibliotecas e frameworks que intermediam este processo. Cliente simplesmente utiliza primitivas da linguagem de programação ou da biblioteca. Biblioteca se encarrega de traduzir isso para mensagens SOAP. A JAX-WS é um exemplo deste tipo de biblioteca. A partir de algumas configurações iniciais, ela tornará as mensagens SOAP transparentes. Cliente fará chamadas a métodos em objetos locais. Estes serão traduzidos para mensagens SOAP bem formatadas. Diego Passos (UFF) Web Services (I) TEPIS II 27 / 30

28 Big Web Services: Por Que? Superficialmente, os Web Services parecem muito complexos. Em especial, os Big Web Services. Muitas tecnologias envolvidas. Muitos artefatos a serem gerados. Além disso, existem outras tecnologias para este tipo de computação distribuída. Em Java, por exemplo: EJB, RMI,... Por que, então, utilizar os Web Services? Algumas potenciais vantagens: Independência de tecnologia/linguagem. Uso de protocolos de transporte comuns (comumente tolerados por firewalls). Diego Passos (UFF) Web Services (I) TEPIS II 28 / 30

29 Próxima Aula A API JAX-WS. Como escrever Big Web Services. Montagem e disponibilizaçao. Geração dos artefatos. Como escrever um cliente. Mapeamento de tipos de dados. Diego Passos (UFF) Web Services (I) TEPIS II 29 / 30

30 Referências Conteúdo e exemplos baseados em: Tutorial da Oracle sobre Web Services. Jim Farley e William Crawford. Java Enterprise in a Nutshell: A Practical Guide. Terceira edição. Capítulo 12. Diego Passos (UFF) Web Services (I) TEPIS II 30 / 30