2ª edição. Daniel Adorno Gomes. Novatec

Transcrição

1 2ª edição Daniel Adorno Gomes Novatec

2 Copyright 2010, 2014 da Novatec Editora Ltda. Todos os direitos reservados e protegidos pela Lei de 19/02/1998. É proibida a reprodução desta obra, mesmo parcial, por qualquer processo, sem prévia autorização, por escrito, do autor e da Editora. Editor: Rubens Prates Editoração eletrônica: Carolina Kuwabata Capa: Victor Bittow Revisão gramatical: Marta Almeida de Sá ISBN: MP Histórico de impressões: Outubro/2014 Segunda edição Junho/2013 Segunda reimpressão Março/2011 Primeira reimpressão Janeiro/2010 Primeira edição (ISBN: ) Novatec Editora Ltda. Rua Luís Antônio dos Santos São Paulo, SP Brasil Tel.: novatec@novatec.com.br Site: Twitter: twitter.com/novateceditora Facebook: facebook.com/novatec LinkedIn: linkedin.com/in/novatec

3 capítulo 1 Introdução aos web services Passados quase cinco anos do lançamento da primeira edição deste livro, os web services continuam sendo uma tecnologia em evidência, pois ainda é o principal meio de integração entre sistemas, independentemente da plataforma de hardware e software utilizados, e também pelo contexto da mobilidade que vivemos atualmente. Em geral, a troca de informações entre aplicativos móveis, desenvolvidos para smartphones e tablets, e servidores, é realizada com a utilização de web services. Neste capítulo, veremos as principais características dessa tecnologia, de forma que, posteriormente, essa introdução possa servir de alicerce para os demais capítulos, em que trabalharemos somente a prática. Comecemos, então, por sua definição. 1.1 Afinal, o que são web services? Os web services surgiram como uma evolução dos modelos de computação distribuída, muito utilizados na segunda metade da década de 90. Entre essas tecnologias podemos citar o RMI, o DCOM e o CORBA. No entanto essas tecnologias tiveram sucesso na integração de softwares em ambientes de redes locais e homogêneos. Quando a Internet avançou para o mercado corporativo, surgiu também a necessidade de integrar aplicações além das redes locais e, por consequência, em ambientes heterogêneos. É nesse contexto que surge a tecnologia que chamamos de web services, proveniente de um consórcio formado por grandes empresas como IBM, Microsoft e BEA, entre outras pertencentes ao W3C. Unindo as tecnologias para o desenvolvimento de aplicações web disponíveis na época, como JSP, ASP e PHP ao XML, elas criaram o padrão para o desenvolvimento de web services denominado SOAP (Simple Object Access Protocol). 13

4 14 Web Services SOAP em Java De forma bastante genérica, podemos dizer que os web services são uma tecnologia de integração de sistemas empregada principalmente em ambientes heterogêneos. Traduzindo: utilizando essa tecnologia, podemos desenvolver softwares ou componentes de software capazes de interagir, seja enviando ou recebendo informações, com outros softwares, não importando a linguagem de programação em que estes foram desenvolvidos, o sistema operacional em que rodam e o hardware que é utilizado. A única premissa é que, para se comunicar com os web services SOAP, a troca de dados tem de ser feita no formato XML. Colocando a explicação anterior em termos práticos, imagine que você está desenvolvendo uma aplicação web que corresponde a uma loja virtual. Uma das exigências de seu cliente é que a aplicação seja desenvolvida em Java, e outra é que os compradores possam consultar quanto terão de pagar de frete mesmo antes de fecharem suas compras. Desenvolver a aplicação em Java não será problema, mas como podemos calcular o frete? Sabendo que todos os produtos vendidos por seu cliente são entregues via Sedex, sabemos que essa informação deverá ser fornecida pelos Correios. Nesse caso, não teremos problemas também, e sabe por quê? Os Correios disponibilizam um web service para o cálculo do valor de serviço de entrega. Basta que os desenvolvedores façam uma chamada ao web service, fornecendo alguns parâmetros como CEP de origem, CEP de destino, tipo de serviço (Sedex) e peso do produto. Essas informações devem ser passadas ao web service em formato XML, e ele nos enviará a resposta, contendo o prazo de entrega e o preço do frete, também no formato XML. Viu como é fácil? Então um web service é uma espécie de método? Recebe valores na forma de parâmetros, executa um determinado processamento com eles e devolve um resultado? Basicamente, sim. Simplificando, essa é a maneira como trabalharemos com os web services. Mais adiante, ainda neste capítulo, nos aprofundaremos nessa explicação. Agora, pensemos em outra questão prática. Imagine que outro cliente solicite que você desenvolva uma aplicação desktop, utilizando Microsoft.NET, que seja capaz de calcular o frete de entregas realizadas via Sedex. O que você faria nesse caso? A mesma coisa que fez no problema anterior: utilizaria o web service disponibilizado pelos Correios, fornecendo as informações necessárias no formato XML e recebendo a resposta também no mesmo formato.

5 Capítulo 1 Introdução aos web services 15 É importante observar uma questão. Nos exemplos anteriores, os Correios é que desenvolveram o web service. E nós seríamos responsáveis pelo desenvolvimento do software cliente, o qual iria utilizar ou fazer chamadas ao web service dos Correios. Nos exemplos do livro, seremos responsáveis pelo desenvolvimento de ambas as partes, tanto dos web services quanto dos clientes que irão utilizá-los. 1.2 Padrões para o desenvolvimento de web services Atualmente, existem dois padrões para o desenvolvimento de web services. O padrão SOAP, citado no início do capítulo, e o padrão REST ou RESTfull. O livro abordará somente o desenvolvimento de web services com a utilização do padrão SOAP. 1.3 Web services SOAP A figura 1.1 mostra os componentes envolvidos e a sequência em que ocorre uma chamada a um web service SOAP. Veja: Figura 1.1 Arquitetura para web services SOAP criada pelo W3C.

6 16 Web Services SOAP em Java Inicialmente, vejamos os componentes exibidos no esquema anterior: SOAP (Simple Object Access Protocol): é o protocolo-padrão para transmissão de dados dentro da arquitetura de web services proposta pelo W3C. O SOAP é um protocolo baseado no XML e segue o modelo REQUEST-RESPONSE do HTTP. WSDL (Web Services Description Language): é um arquivo do tipo XML, cuja finalidade é descrever detalhadamente um web service. Essa descrição especifica as operações que compõem o web service e define de forma clara como deve ser o formato de entrada e saída de cada operação. Veja na figura 1.1 que o WSDL pode ficar armazenado tanto no Provedor de web services quanto no UDDI. Listagem 1.1 Trecho de um arquivo WSDL <message name="adicionarprodutoresponse"> <part name="parameters" element="tns:adicionarprodutoresponse"/> <message name="excluirproduto"> <part name="parameters" element="tns:excluirproduto"/> <message name="excluirprodutoresponse"> <part name="parameters" element="tns:excluirprodutoresponse"/> <message name="atualizarproduto"> <part name="parameters" element="tns:atualizarproduto"/> <message name="atualizarprodutoresponse"> <part name="parameters" element="tns:atualizarprodutoresponse"/> <message name="listarprodutos"> <part name="parameters" element="tns:listarprodutos"/> <message name="listarprodutosresponse"> <part name="parameters" element="tns:listarprodutosresponse"/> <message name="localizarproduto"> <part name="parameters" element="tns:localizarproduto"/> <message name="localizarprodutoresponse">

7 Capítulo 1 Introdução aos web services 17 <part name="parameters" element="tns:localizarprodutoresponse"/> <porttype name="cadastrarprodws"> <operation name="adicionarproduto"> <input message="tns:adicionarproduto"/> <output message="tns:adicionarprodutoresponse"/> </operation> <operation name="excluirproduto"> <input message="tns:excluirproduto"/> <output message="tns:excluirprodutoresponse"/> </operation> <operation name="atualizarproduto"> <input message="tns:atualizarproduto"/> <output message="tns:atualizarprodutoresponse"/> </operation> <operation name="listarprodutos"> <input message="tns:listarprodutos"/> <output message="tns:listarprodutosresponse"/> </operation> <operation name="localizarproduto"> <input message="tns:localizarproduto"/> <output message="tns:localizarprodutoresponse"/> </operation> </porttype> UDDI (Universal Description, Discovery and Integration): o UDDI é um mecanismo que visa atender tanto o cliente de web services quanto o provedor. Ele tem de fornecer ao provedor de web services meios para que os web services sejam registrados e publicados. Isso permitirá que os web services sejam pesquisados e localizados pelos clientes. Outra finalidade do UDDI é o armazenamento de arquivos WSDL. Cliente: é um software que consumirá web services, ou seja, utilizará as operações disponibilizadas por determinado web service. No entanto é importante que se deixe claro que, na figura 1.1, o cliente está sendo representado em várias etapas de seu ciclo de vida. Ali, vemos desde sua preexistência, quando um determinado desenvolvedor obtém o arquivo WSDL, até o momento em que o software já está em operação, fazendo solicitações e recebendo os resultados dos web services, ambos no formato XML.

8 18 Web Services SOAP em Java Provedor de web services: esse componente corresponde a um servidor de aplicações ou um web container, conforme o caso, em que o web service ficará armazenado. Ele pode armazenar também os arquivos WSDL, como mostra a figura 1.1. Antes de avançarmos na explicação, é importante reforçar que toda essa arquitetura tem como base a linguagem XML. Portanto todas as informações que são trocadas entre qualquer uma das partes são enviadas e recebidas por meio de mensagens no formato XML. Continuando, vejamos agora como os componentes exibidos na figura 1.1 se integram. Os números referenciados na figura serão utilizados para descrever a sequência das operações: 1. Registra e publica o web service: os web services ficam armazenados junto de seus descritores, os arquivos WSDL, em provedores de web services. Quando criamos um web service, o disponibilizamos para uso em um provedor de web services. No entanto, para que esse web service seja utilizado por algum cliente, ele e seu WSDL precisam ser localizados, ou seja, o cliente precisa obter o endereço do web service ou seu URI (Uniform Resource Identifier), que é um endereço semelhante ao já conhecido URL (Uniform Resource Locator). Assim, depois de criarmos e armazenarmos um web service em um provedor, devemos registrá-lo e publicá-lo em um diretório de registro de web services, também conhecido como UDDI. 2. Obtém informações sobre o web service: quando um desenvolvedor de software precisar utilizar um web service, inicialmente ele pesquisará em diretórios de registro de web services (UDDI) pelo tipo de web service que deseja. Por exemplo, um web service que efetue validação de CPF ou um que retorne a cotação do dólar. A arquitetura do W3C inclui recursos de pesquisa e de localização de web services, visando à possibilidade de diversos web services, de diversos fornecedores de software dispobilizarem a mesma operação. Dessa forma, o desenvolvedor necessita primeiro obter a informação que dirá onde está o web service desejado e seu respectivo arquivo WSDL. Em outras palavras, o UDDI fornecerá ao desenvolvedor o endereço (URI) do web service e de seu WSDL.

9 Capítulo 1 Introdução aos web services Efetua download do WSDL: assim que o desenvolvedor obtém os URIs do web service e de seu descritor (WSDL), ele pode efetuar o download do arquivo WSDL e, em seguida, efetivamente utilizar o web service desejado. É importante lembrarmos que o arquivo WSDL pode estar disponível para download tanto no UDDI quanto no provedor de web services. Obtidos o arquivo WSDL e o URI do web service, o desenvolvedor poderá criar um software cliente que fará uma chamada ao web service e obterá uma resposta, conforme o serviço solicitado. 4. Envia solicitação XML: o software cliente fará chamadas ao web service, por meio de seu URI, enviando ao web service solicitações no formato XML. 5. Recebe resposta XML: o web service receberá a solicitação anterior, efetuará um determinado tipo de processamento e produzirá um resultado. O web service pode ou não enviar o resultado do processamento ao software solicitante, como uma resposta, no formato XML. A explicação dada anteriormente se baseia na especificação criada pelo W3C. No entanto o funcionamento dos web services na prática não ocorre exatamente como foi especificado, apesar de ser extremamente plausível. Normalmente, a figura do UDDI não existe. Isso faz com que a comunicação entre o cliente e o provedor de web services ocorra sem intermediações. Veja: Figura 1.2 Funcionamento prático dos web services SOAP. Outra questão prática que não pode ser esquecida refere-se ao protocolo sobre o qual as mensagens SOAP trafegam. A arquitetura projetada pelo W3C especifica que as solicitações e respostas XML possam trafegar por meio de qualquer protocolo como HTTP, FTP, SMTP, TCP puro etc. Mas o que vemos na prática é a utilização do XML trafegando somente sobre HTTP. Isso se deve ao fato de o HTTP ser um protocolo dominante na web

10 20 Web Services SOAP em Java já há muito tempo. É suportado por praticamente todo tipo de plataforma de software/hardware maduro, confiável e sem problemas com restrições por firewalls. Existem duas formas de envio de mensagens para que um cliente possa efetuar solicitações a um web service: One-Way Messaging: essa é uma forma de envio de mensagens unilateral. Nela o cliente envia a solicitação sem se preocupar com a resposta. O web service executará o processamento solicitado e não enviará resposta ao cliente. Figura 1.3 One-Way Messaging. Request-Response Messaging: nessa forma, o envio de mensagens é bilateral. O cliente faz uma solicitação ao web service, que executa um processamento qualquer, ao final do qual envia o resultado ao cliente. Nesse caso, podemos trabalhar tanto de forma síncrona como assíncrona. Figura 1.4 Resquest-Response Messaging. Ok! Chegamos ao fim do primeiro capítulo do livro. Agora, vamos colocar a mão na massa e transformar os conceitos apresentados aqui em software. Espero que você goste do que veremos adiante.